IT Security Lab The Playground for IT Security Specialists and Pentesters

Pentesting privilege escalation in web applications

Quick tip from my pentesting practice about how you can make your life easier when testing for privilege escalation in web applications.

Background of the problem

Let's imagine that we have a web application to test, so have (at least) two sets of credentials: for a high-privileged user and low-privilege one. When we log-in as high-privileged user (e.g.: admin) - we obviously have access to much more information (more menu items, more functionality, etc.). Now what we want to know - if those items may be accessed directly by low-privileged user. It is clear that if you just would click "here and there" manually (or even copy some URLs) as low-privileged user - you still may omit something important very easily. So the question is: how we may be sure that all combination are checked?

Proposed solution

The whole idea is quite simple:

1. We have to spider the application from the perspective of high-privileged user. You may use any tools you like (e.g.: Burp Suite, DirBuster, Paros, etc.). Important is to have the whole list of visited URLs written in simple text file.
2. We have to log-in as a low-privileged user and get a copy of sample GET request with appropriate cookie (e.g.: Burp, Paros or Fiddler may be used for it).
3. We may use Burp's "Intruder" module and re-issue the captured header (with cookie appropriate for low-privileged user) and automatically replace URL with ones from our list.
4. We should carefully examine results and look for all discrepancies (e.g.: when unexpectedly status is "200 OK" when it should be an error or redirection).

Illustration

Assume you have the following URL to test: http://vulnerableapp.com This is the sample list of URLs you may get from your spidering tools being authenticated as high-privileged user:

...
/admin/edit_my_details.asp
/admin/my_folders.asp
/admin/list_suggestions.asp
/admin/list_asset.asp
/admin/my_assets.asp
/admin/usage_category.asp
/admin/upload_file.asp
/admin/list_category.asp
/admin/bulk_copy.asp
/admin/list_users.asp
/admin/list_subcategory.asp
/admin/list_logged_in_users.asp
/admin/list_company.asp
/admin/manage_project.asp
/admin/manage_intro.asp
/admin/manage_contacts.asp
/admin/manage_event_types.asp
...

So it does mean you were able successfully navigate there from the perspective of high-privileged user. Let's check how far the low-privileged user may go. :-)

Log-in to the system as low-privileged user and copy sample GET request to "Intruder".

In Intruder we must set up the "fuzzing point":

Now use our saved list of URLs as the payload:

Finally, run Intruder and see what happened:

Now all points where low-privileged user have access are clearly visible. The next step would be only to open those URLs in a web browser and check if this user really should be able to access it.

Oh yes, you can also repeat the same trick without cookie at all, so then you may easily check what functionality may be accessed for unauthenticated user.