The seventh entry on the most recent OWASP Top 10 release (from 2013, due to the 2017 release candidate being rejected!) is "Missing Function Level Access Control", which is essentially what leads to Privilege Escalation issues. This common vulnerability related to the question: "Am I Vulnerable to Forced Access?" in the following way:
"The best way to find out if an application has failed to properly restrict function level access is to verify every application function […]".
The word "every" is indeed originally in bold and there is a good reason behind it. Very often, applications implement function-level access control for most, but not every, application function. This can be especially true of larger applications that might still rely on legacy code to perform certain functions. Testing all possible cases during a web application penetration test is often quite time-consuming, can easily become overwhelming and of course be subject to human error.
In this blog post I would like to introduce a tool, which I have discovered to be extremely helpful in identifying privilege escalation issues.
Let's start with the basics. If you are reading this blog post there is a good chance you already know about vertical and horizontal privilege escalation, which is effectively a lapse in user separation. However, for the sake of completeness, let me quickly explain what they are.
Vertical privilege escalation is a kind of flaw that allows a lower privileged user to access and/or modify data which should only be accessible to higher privileged users.
It often happens that the application UI presents different options to different user roles, but the application does not enforce authorisation at the server side on the application function level. For instance, a regular user does not see the UI element pointing to "http://app/admin/user_list" URL, however, when they type this URL directly into the browser's address bar or use other tools to send such a request, the application erroneously responds with unauthorised content.
Horizontal privilege escalation is a similar issue. Instead of two user roles there are two users with the same role and permissions. When this issue is present, users can cross-access private data of other users with the same level of permissions. Similar to vertical escalation, it may happen that "User1" (from "Company A") is presented with a list of documents, which should only be available to users of "Company A". That list is available at http://app/documents/list?companyId=A URL and each element on the list points to a URL of http://app/documents?docId=NNN.
Obviously, "User2" of "Company B" is presented with a different list of documents while navigating to the URL through the UI (http://app/documents/list?companyId=B). However, what happens when User2 (of "Company B") requests the following URLs directly:
If the application successfully responds with the requested content, there is an Insecure Direct Object Reference issue, which is a specific example of privilege escalation.
Testing for privilege escalation usually requires a manual approach as the vulnerability tends to be context dependant. It is difficult to program testing software to recognise what is expected to be available only to one user role or user, but not to the other.
One of Burp's tools is particularly useful when it comes to discovering horizontal escalation - Burp Intruder allows you to enumerate different resources with a great control over how that is done. When it comes to vertical privilege escalation, the number of requests which should be sent to the application is directly proportional to the number of tested URLs and user roles. More precisely, it is at least a multiplication of these numbers. Comprehensive testing should cover all these requests, as more often than not, the authorisation within the web application is properly implemented for almost all application functions, but not all of them.
Moreover, if all privileged application functions have been tested as some non-privileged role, it is still sensible to go through all of them again as other non-privileged roles. For instance, if there are 3 roles in the application: Admin, Editor, Viewer, and all of the Admin's application functions have been tested with the Viewer's session, it's still advisable to go through all of them as the Editor user. This kind of testing can easily become quite cumbersome when there is no specialised tool at hand. This is where Burplay comes in.
Burplay is a Burp extension, which allows for replaying any number of requests while applying different modifications to them.
Currently Burplay supports adding, modifying or deleting:
In addition, sessions can be defined, so you can easily replay requests as a particular user.
For instance, if the application uses a session cookie to track users' sessions, you can:
They will then show up in the "Replay" tab:
The session can be defined by selecting a cookie name and value in any request or response view within Burp:
5. "Apply" the newly defined session as a modification in the Replay tab:
On the right-hand side of Burplay's UI, there are tabs showing all replays and the original set of requests and responses. Currently, manual inspection of replay tabs is the only method of identifying an issue.
Privilege escalations are hard hitting issues that should be tested for comprehensively. Burplay helps in identifying all the vulnerable areas within an application, saving a great deal of time but also potential oversights due to manual testing efforts.
There are plans to introduce some automatic comparison of responses in future versions of Burplay, so stay tuned!
Get Burplay from:
https://github.com/SpiderLabs/burplay
