Hello readers, in this blog, our Senior Consultant Vanshal Gaur, is going to explain access control and vulnerabilities arising from insecure access control such as Insecure Direct Object References (IDOR) with some interesting obscure examples.
IDOR is a type of access control vulnerability that arises when an application uses user-supplied input to access objects directly. It usually takes the form of an unique identifier and may appear in a URL.
In order to have a better understanding of IDOR, let us first understand what exactly is “Access control” and what are its types.
Access control allows applications (or admins) to define user roles as per capabilities that a user should have. Some users have more privileges than other users. In the context of web applications, access control is dependent on authentication and session management:
Access control can be better explained in the following types:
Now that we know “Access Control”, we can shift our focus back on IDOR. In IDOR, attackers can bypass authorization and access resources, for example, database records or files in the system directly. It does so by allowing attackers to directly modify the value of a parameter used to directly point to an object. This is caused by the fact that the application takes user-supplied input and uses it to retrieve an object without performing sufficient authorization checks.
The vulnerability is of such significant concern that for many years it was listed as one of the Open Web Application Security Project’s (OWASP) Top 10 vulnerabilities.
The impact of an IDOR vulnerability depends on the application’s functionality. Therefore, a clear list can not be generated. It depends on various factors. Generally speaking, an IDOR vulnerability can introduce a risk for CIA (confidentiality, integrity, availability) of data.
The following are some examples of IDOR impact:
In order to test IDOR, the tester first needs to map out all locations in the application where user input is used to reference objects directly. For example, locations where user input is used to access a file, a database row, application pages, etc. Next, the tester should modify the value of the parameter used to reference objects and assess whether it is possible to retrieve objects belonging to other users or otherwise bypass authorization.
Below mentioned are some Burp Suite plugins, which can make your life easier and help you automate the process of finding IDORs and Access Control issues:
Reference: https://www.youtube.com/watch?v=3K1-a7dnA60 (A great tutorial by @regala_), A must-watch!
Suppose there are two users: UserA and UserB.
UserA can access his bank account details by visiting the below URL:
example.com/bankdetails.aspx?id=UserA
And UserB can access his bank account details by visiting:
Essentially, both these users should not be able to access the bank details of any other user.
If you observe the URLs of both the users, the object that allows the bank application to differentiate between both the users is the “id” parameter.
Now if an IDOR vulnerability had to exist in this case, a malicious user (suppose UserA) will be able to modify the insecure object “id”. By changing the “id” to “UserC”, the malicious user (UserA) will be able to access the bank details for UserC.
During the reconnaissance of the application sometimes we may come across some sort of encoded ID, it might be possible to decode the encoded ID using common encoding schemes and change the inside value to exploit IDOR.
If the application is using a randomised/hashed ID, check if the ID value is predictable. Sometimes applications use algorithms/methods that produce insufficient entropy, and as such, the IDs can actually be predicted after a thorough analysis. In this case, try creating multiple accounts to analyse how these IDs are created. You might be able to find a pattern that will allow you to predict IDs belonging to other users.
Further, it might also be possible to leak hashed or random IDs via another API endpoint, on other public pages in the application (profile page of other users, etc), or in a URL.
For example, consider the below API endpoint which allows users to retrieve detailed direct messages through a hashed conversation ID.
GET /api_v1/messages?conversation_id=SOME_RANDOM_ID
This may seem completely okay at first since the conversation_id is a long, random, alphanumeric sequence. But, it was discovered that you could actually find a list of conversations for each user just by using their user ID! Note that user_id was publicly available on each user’s profile page.
The above request would return a list of conversation_ids belonging to that given user. Therefore, it’s possible to read any user’s messages by first obtaining their user_id on their profile page, then retrieving a list of conversation_ids belonging to that user, and finally loading the messages via the API endpoint /api_v1/messages!
In case the object reference IDs seem unpredictable, see if there is anything you can do to manipulate the creation or linking process of these object IDs. If no IDs are used in the application-generated requests, try adding it to the request. Try adding parameters like id, user_id, message_id or other object reference parameters and see if it makes a difference to the application’s behaviour.
Let’s take one example here, if the following request displays all your direct messages:
GET /api_v1/messages
Try adding “user_id” and observe whether the application behaves in a different way. Would it display another user’s messages?
Let’s advance towards understanding Blind and HTTP Parameter Pollution (HPP) IDORs, and how to look for such vulnerabilities.
Blind IDOR attacks are identical to Blind XSS or SQLi attacks. In that, the specific IDOR request is undetectable because the following response does not reveal the vulnerability.
For example, if you change the object’s information in the application, you will receive an email that includes that information, now if you try to change the same information for another user, and you can’t access anything in HTTP response but you can access the same information of object with an email, that would be called a “Blind IDOR”.
In some cases, you can test the HTTP Parameter Pollution vulnerability for IDOR by adding the same parameter twice in your request. ie: UserA could make the below URL calls in order to get access to UserB account details.:
example.com/?id=UserB&id=UserATo prevent vulnerabilities arising out of IDOR, applications should implement strict access control on every functionality, and check if a user is authorised to access and/or manipulate the requested object.
Never depend on untrusted data:
More information about IDOR prevention can be found in OWASP’s IDOR prevention cheat sheet
There are many occurrences of access control vulnerabilities where user-controlled parameter values are used to access resources or functions directly.
We have listed some interesting IDOR vulnerabilities, found over time by security researchers all over the world.
A security researcher found an IDOR vulnerability, where it was possible to access any YouTube channel’s private video by getting one video frame at a time.
David, who originally discovered this vulnerability mentioned that he tried to access other user’s private videos by changing the target video’s ID from YouTube requests but could not be successful, so he started to think differently. He started poking around with Google AdSense (a product that advertisers use to create ads across all Google services, including YouTube). The ads you get before YouTube videos are set up by advertisers on the Google Ads platform.
The researcher created a Google Ads account and created a new advertisement, which would play a video of his as a skippable ad for YouTube users.
While exploring AdSense features, he found a page called “Videos”, where it was possible to see the list of videos used by advertisements.
Clicking on a video opened up an Analytics section for that specific video, which had an interesting feature called “Moments”. It allowed advertisers to “mark” specific moments of the video.
Exploitation:
Whenever we “marked a moment” in the “Moments” section, a POST request to “/GetThumbnails” was sent, as shown below:
POST /aw_video/_/rpc/VideoMomentService/GetThumbnails HTTP/1.1
A Base64 encoded image, that is the thumbnail displayed by Ads was returned in the response to the above request. This request contained a “video-id”( in parameter _ar as “1”), by changing this ID to a private video’s ID, it was possible to fetch the thumbnail of that video.
As the post request took time in milliseconds (in parameter _ar as “2”), we could specify the time for which we wanted to fetch the thumbnail.
David wrote a python script to automate this whole process, which would get all the thumbnails of videos frame by frame, and generate a moving video.
Key takeaway: Even though you think you hit the dead-end, exploring the functionalities of the application and thinking deep is the key.
Here, the security researcher found IDOR by performing a code review of Kitsune (A Django-based application, created by Mozilla).
Django is a Python-based web framework, free and open-source, that follows the model–template–views architectural pattern.
While going through all the URL endpoints, the researcher found this interesting endpoint:
Going through the “views.reply” function, the researcher discovered that if you provide a “delete_images” Post parameter, it will delete any image with the “id” you provide in the “delete_image” parameter, without any checks, if the user deleting the image is the owner of the image.
Now that we know the vulnerable piece of code, we can exploit the vulnerability as follows:
In this instance, a security researcher exploited the vulnerability by adding a new parameter to the existing request. We can also use this technique to bruteforce the parameter names or guess it according to other application parameters. Such vulnerabilities can also be termed as Mass Assignment vulnerability.
Key Takeaway: Exploiting these types of vulnerabilities is difficult in black-box type of assessments, as guessing the exact parameter is hardly possible. Hence, the code reviews are as important as other methods.
Recently, a security researcher named Neeraj Sharma, found a vulnerability in Instagram where the attacker could change the reel thumbnail of any Instagram user by knowing “clips_media_id” (Media ID of reel) of that user.
While understanding the API structure and the request flow of Instagram application, the researcher came to the point where users can edit their reels cover photo (thumbnail). For testing, he changed his reel thumbnail and intercepted all the HTTP requests using Burp and after forwarding some requests he observed the following HTTP request:
POST /api/v1/media/configure_to_clips_cover_image/ HTTP/2
Here the important parameters are “clips_media_id” and “upload_id”.
Clip ID is the ID of a reel video and upload_id is the ID of an image that the user wants as a new reel thumbnail. Due to the IDOR vulnerability, which was present at the vulnerable endpoint, it was possible to change the “clips_media_id” to the victim’s reel ID and change the thumbnail of their video.
Though this vulnerability seems less severe, the impact is high. Within the CIA triad, Integrity was violated and the Accessibility of the victim was totally disregarded by the actions of the attacker. As the malicious actor was able to forge thumbnails in any profile without any authorization or victim interaction, the impact was loud, wide and around heterogeneous masses of Instagram users.
Key Takeaway: It’s always possible that simple bugs like these are lying around the web, it is good to be mindful of the basics of every application, no matter even if the application has been tested 1000s of times.
Dialogflow is a natural language understanding platform that makes it easy to design and integrate a conversational user interface into your mobile application, web application, device, and more. Using Dialogflow, you can provide new and engaging ways for users to interact with your product.
The security researcher in this case was testing Dialogflow and observed an option to delete the phone gateway, as shown in the below figure:
As mentioned in the above request for “delete phone gateway”, the researcher tried to brute-force the random string (which is an encoded phone number) but it didn’t work.
Moving on to find the other encoded numbers to see if it was possible to delete another user’s phone gateway using the same request, the researcher found another feature called “CX Phone Number”, where it was possible to create new numbers, and inside that was an option to select Area code.
On intercepting the Area code request, some random strings (Phone numbers) were found in response.
Replacing the random strings (Phone Numbers) in the “delete phone gateway” request, the researcher was successfully able to delete other users’ phone numbers.
Key Takeaway: If you’re lacking some sort of information in order to successfully exploit a vulnerability, it’s worth trying to find that information on other features of the application.
The application had an account update functionality where a user could update profile information, such as name and profile picture. There was no functionality to update the other details such as Email Address, Password and Role. Here, an attacker could chain the IDOR with Mass Assignment vulnerability to change other user details and ultimately leverage it to complete the account takeover of the victim.
The researcher intercepted the profile update request and observed the below request/response. By looking at the userID in the URL, we think of an IDOR, but the application was validating the request using the slug parameter.
Request:
PUT /api/users/15 HTTP/1.1
Host: target.com
Cookies: session=xxxxxxxx
…
{
“name”:”Test User”,
“image”:”IMG URL”,
“slug”:”dXNlcjE1″
}
Response:
HTTP/1.1 200 OK
Set-Cookie: session=xxxxxxxx; Secure; HttpOnly; SameSite=None
Connection: close
Content-Length: 0
{
“userid”:”15″,
“name”:”Test User”,
“Email”:”test@example.com”,
“Role”: “User”,
“image”: “https://target.com/media/images/avtar.png”
…DATA…
}
Further, it was observed that the “slug” parameter value was the base64 encoded string of “userID”, i.e., user15, as reflected in the request URL.
So, the researcher added the “email” parameter in the request and replaced the “ID” value with the victim’s userID (user18 – dXNlcjE4) along with the encoded “slug” value. As a result, the researcher was able to perform an account takeover by chaining IDOR with Mass Assignment vulnerability.
Request:
PUT /api/users/18 HTTP/1.1
Host: target.com
Cookies: session=xxxxxxxx
…
{
“name”:”Test User”,
“image”:”https://target.com/media/images/avtar.png”,
“Email”:”attackercontrolledaddress@example.com”,
“slug”:”dXNlcjE4″
}
Response:
HTTP/1.1 200 OK
Set-Cookie: session=xxxxxxxx; Secure; HttpOnly; SameSite=None
Connection: close
Content-Length: 0
{
“userid”:”18″,
“name”:”Test User”,
“Email”:”attackercontrolledaddress@example.com”,
“Role”: “User”
}
With such an issue, it is possible to further take advantage of forgot password functionality after changing the email of the victim and completely take over the account.
Key Takeaway: Eventhough it might seem like the application does not have certain functionality, it’s always worth adding additional parameters in the request and observe the corresponding response.