My Pentest Log -7- (Horizontal/Vertical Privilege Escalation)
Greetings to all from Sergius and Bacchus,
In this article, I would like to inform you about the web-based privilege escalation vulnerability I encountered.
The address I tested throughout the article will be specified as private.com.
1. I received the necessary information from our project manager that I should be able to conduct security tests on private.com.
2. As always, I reviewed the scope form, which is the first step to be done, and after checking the necessary access controls, I started the pentest phases.
3. After completing the fuzzing processes on the application, I made high-level vulnerabilities detection as a result of trying various vectors.
4. However, what motivated me the most was that I identified the “Horizontal/Vertical privilege escalation vulnerability” weakness.
5. So what happened?
6. On the target I tested, users were able to become members, share, delete/edit what they shared.
7. In such structures, I first question whether cross-checks are applied correctly because access controls must be applied correctly in applications with more than one user, but every application (web/mobile/api) I test has at least 1 access control vulnerability.
8. Anyway, I created 2 users on Target, User A and User B.
9. I shared a post on user A and commented on the post I shared as user A.
10. Then I viewed the post shared by user A (with user B). There are many attack vectors that can be made in this section, but since my target point is an escalation vulnerability, I want to somehow edit or delete the comment of user A through user B.
11. For this:
First of all, I needed to determine the right parameters, and to find the right parameters, it would be enough to comment on any post with user B, so that I could learn which parameters are used while commenting.
While commenting on any post via user B, I stopped the request with my proxy tool and examined the parameters in the request. As in most applications, there were values such as “message, user_id, post_id, comment_id”.
I was lucky that the request was not signed. (I will talk about this later).
After determining the necessary parameters, I wrote them down in my notebook.
From this point of view, we understand that we need “user_id,comment_id” and “post_id” values to edit or delete any user’s comment.
As many of you know, user profiles can be viewed in applications with user interactions, even if profiles cannot be viewed, profile photos can be viewed…
So what is the importance of this for us?
Tip : Because it provides the necessary move for us to learn the user id of the other party.
There are many ways to learn the user_id of the other party, but in applications like this, when we view the user profile, there are many points where we can learn the ID of the other party in the URI or in the HTTP head or body.
From this point of view, when I examined the request I made to view the profile of user A, I noticed that the user_id value was kept in the URI, exactly as I expected. (One point for us :) )
Example: https://private.com/profile/user/55/
Now we have the “user_id”. By the way, I may have forgotten to mention that the “user_id” value was in an easily predictable format etc: 4566212
“You may say in your mind: if they were predictable, why didn’t you choose one of your own, why did you try so hard”, unfortunately, this is not the right approach, deleting any data belonging to someone else may cause serious inter-institutional problems. It will always be more ethical not to go out of your test accounts.
In summary, we learned the necessary parameters for adding and deleting comments, and we learned the user ID, now we can move on to the attack phase.
12. I switch to edit mode by pressing the “edit” button of the comment I created (User B).Then, when I update the comment and send the request, I intervene with the proxy,I continue the request by deleting the values of user B and entering the values of “user_id,post_id” and “comment_id” belonging to user A.
13. And we reach our goal :) Since the authorization checks are not well structured, we were able to change the comment of user A even though we do not have any authority :)
14. After providing the necessary final checks, we note the screenshots and HTTP requests and process them in our report.
In summary:
Try to understand the working logic of an application through both your experience and the way the application works, so you can find various business logic vulnerabilities.
During the tests, carefully examine the HTTP requests as much as possible, you can take the application down by discovering some important parameters.
