Fuzzing + IDOR = Admin TakeOver

Hello everyone, this is my first post. I’ve been thinking about writing about my findings for a while, so here we go.

大家好,这是我的第一个帖子。我已经考虑写下我的发现有一段时间了,所以我们开始吧。

Please let me know if you notice any spelling errors.

如果你注意到任何拼写错误,请告诉我。

https://pixabay.com/es/photos/m%c3%a1quina-de-escribir-mec%c3%a1nica-retro-407695/

We will call the victim web “example.com”. This objective has 6 well defined user roles. The user with low privileges I call it “Low Privilege” and the one with higher privileges I call it “Super Admin”.

我们将受害者网站称为“榜样网”。这个目标有6个定义良好的用户角色。低权限的用户我称之为“低权限”,高权限的用户我称之为“超级管理员”。

Step 01

第一步

I love the fuzz, so first of all I started with fuzzing against the endpoint “/api/FUZZ” without login in the app, using the tool ffuf:

我喜欢模糊,所以首先我使用 ffuf 工具,在不登录的情况下对端点“/api/FUZZ”进行模糊化:

I found 4 endpoints, 2 of them are important here:

我发现了4个端点,其中2个在这里很重要:

  • user/users 用户/用户
  • user/updateuser 用户/更新用户

Step 02

步骤02

I make a request against the found endpoint and I can see that the server only accepts the POST method:

我对找到的端点发出请求,我可以看到服务器只接受 POST 方法:

Step 03

步骤03

I change the method to POST:

我将方法改为 POST:

And I can see that a message is displayed for lack of authorization to interact with the resource (endpoint):

我可以看到一条消息显示为缺乏授权与资源(端点)进行交互:

Step 04

步骤04

At this point, I need an authorization token. To obtain it, I log in to the application with my “Low Privilege” user account:

此时,我需要一个授权令牌。为了获得它,我用我的“ Low Privilege”用户帐户登录到这个应用程序:

I click on any request and intercept the valid request on the backend, which attaches the “Authorization” header with the JWT:

我点击任何请求并拦截后端上的有效请求,后端将“ Authorization”头附加到 JWT:

Step 05

步骤05

From the endpoint “/api/vehicle/getLoggedInUserBookings” I can see a header “Authorization: Bearer [token]”:

在端点“/api/vehicle/getloggetdinuserbookings”中,我可以看到一个头文件“ Authorization: Bearer [ token ]”:

Step 06

步骤06

I copy and paste this header in my request from Step 03. I add the “Authorization” header with the token that I captured previously and make the request. At this point I noticed a new error message returned by the application:

我复制并粘贴这个头在我的要求从步骤03。我添加了“ Authorization”头和我之前捕获的令牌,然后发出请求。这时我注意到应用程序返回了一个新的错误消息:

Step 07

步骤07

Now, the first thing I think about is “balancing” the request to get a clean response from the server. This got me thinking about changing some headers like “Content Type” and “Accept”. Also, I always add a random parameter (JSON format) in the request with a random value to determine how the server reacts:

现在,我考虑的第一件事是“平衡”从服务器获得干净响应的请求。这让我考虑修改一些头文件,比如“ Content Type”和“ Accept”。此外,我总是在请求中添加一个带有随机值的随机参数(JSON 格式) ,以确定服务器的反应:

Step 08

步骤08

My first thought when faced with a new API is to save every single parameter I come across along the way. Continuing with this thought, I use the parameters I found in the request from Step 05 to debug the responses and try to get an accurate HTTP 200 OK response:

当面对一个新的 API 时,我的第一个想法是保存一路上遇到的每一个参数。继续这个想法,我使用我在步骤05的请求中找到的参数来调试响应,并试图得到一个准确的 HTTP 200 OK 响应:

The message “User details fetch successfully” tells me that everything is fine!

“ User details fetch successfully”消息告诉我一切正常!

Step 09

步骤09

It is an important point in the exploitation, since I must look for one or more parameters that allow me to obtain more information.

这是开发过程中的一个重要环节,因为我必须寻找一个或多个参数,以便获得更多信息。

Okay, using fuzzing techniques again, I find a valid parameter. This parameter was found with the name of ‘“role: 1”’:

好的,再次使用 fuzzing 技术,我找到了一个有效的参数:

The correct syntax to get the correct result with ffuf is as follows:

使用 ffuf 获得正确结果的正确语法如下:

ffuf -w g0ld3n-api.txt -u https://vulnerable.com/api/endpoint -X POST --data '{"param1":value1,"param2":value2,"FUZZ":6}' -H 'Authorization: Bearer JWT'

Step 10

步骤10

Then I send the request with this new parameter (role) and the server returns me confidential information about all the users with the “role” equal to “6” corresponding to the Low Privilege role:

然后,我用这个新参数(角色)发送请求,服务器会返回所有“ role”等于“6”的用户的机密信息,这些“ role”对应于 Low Privilege 角色:

Step 11

第十一步

At this point I can detect that the API is vulnerable to IDOR in its functionality to view user information. Now, will it also be true for the “update user” endpoint found previously in Step 01?

此时,我可以检测到,该 API 在其查看用户信息的功能方面容易受到 IDOR 的攻击。现在,对于之前在步骤01中发现的“更新用户”端点也是这样吗?

I use the parameters found in Step 10 and start debugging to find a valid response from the server against the endpoint “/user/updateuser”. Once I achieve the “balance” to make the correct request, I change the value of the parameter ‘”role “: 6’ to ‘“role”: 1’:

我使用步骤10中找到的参数并开始调试,以从服务器上针对端点“/user/updateuser”找到有效的响应。一旦我实现了“ balance”以提出正确的请求,我将参数“”role“ : 6”的值更改为“ role: 1”:

  • Role 6 = Low Privilege 角色6 = 低特权
  • Role 1 = Super Admin 1 = 超级管理员

I log in again with my user and I see that I am now Super Admin:

我再次用我的用户登录,我看到我现在是超级管理员:

Thank you very much for reading and please let me know if you notice any errors or inconsistencies.

非常感谢您的阅读,如果您注意到任何错误或不一致,请让我知道。

I leave my git and twitter in case you want to take a look at it:

我留下了 git 和 twitter,如果你想看看的话:

Take care!

保重!