Trustwave SpiderLabs Uncovers Ov3r_Stealer Malware Spread via Phishing and Facebook Advertising. Learn More

Trustwave SpiderLabs Uncovers Ov3r_Stealer Malware Spread via Phishing and Facebook Advertising. Learn More

Services
Capture
Managed Detection & Response

Eliminate active threats with 24/7 threat detection, investigation, and response.

twi-managed-portal-color
Co-Managed SOC (SIEM)

Maximize your SIEM investment, stop alert fatigue, and enhance your team with hybrid security operations support.

twi-briefcase-color-svg
Advisory & Diagnostics

Advance your cybersecurity program and get expert guidance where you need it most.

tw-laptop-data
Penetration Testing

Test your physical locations and IT infrastructure to shore up weaknesses before exploitation.

twi-database-color-svg
Database Security

Prevent unauthorized access and exceed compliance requirements.

twi-email-color-svg
Email Security

Stop email threats others miss and secure your organization against the #1 ransomware attack vector.

tw-officer
Digital Forensics & Incident Response

Prepare for the inevitable with 24/7 global breach response in-region and available on-site.

tw-network
Firewall & Technology Management

Mitigate risk of a cyberattack with 24/7 incident and health monitoring and the latest threat intelligence.

Solutions
BY TOPIC
Microsoft Exchange Server Attacks
Stay protected against emerging threats
Rapidly Secure New Environments
Security for rapid response situations
Securing the Cloud
Safely navigate and stay protected
Securing the IoT Landscape
Test, monitor and secure network objects
Why Trustwave
About Us
Awards and Accolades
Trustwave SpiderLabs Team
Trustwave Fusion Security Operations Platform
Trustwave Security Colony
Partners
Technology Alliance Partners
Key alliances who align and support our ecosystem of security offerings
Trustwave PartnerOne Program
Join forces with Trustwave to protect against the most advance cybersecurity threats
SpiderLabs Blog

Introducing Burplay, A Burp Extension for Detecting Privilege Escalations

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

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

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:

  • http://app/documents/list?companyId=A, or
  • http://app/documents?docId=NNN, where NNN is an ID of a document belonging to Company A?

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

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

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:

  • Cookies
  • Request headers
  • GET parameters
  • POST parameters

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:

  1. Log in to the application as a high-privileged user in a browser proxied by Burp and browse through all URLs which should be covered by the test.

9840_6e6da25c-ef43-4816-a5b2-3e0fa06b893a

  1. In Burp Proxy's History or Target Site Map, choose all interesting requests and "Send to Replay"

9257_5069c79b-d8af-4b38-9f19-0576603fdc66

They will then show up in the "Replay" tab:

8346_23ef4b2a-5487-46c7-9bbf-8d6b7279ef3d

  1. Log into the application as a low-privileged user

8725_36ccbd40-cd39-49ef-9414-210f4a4bebe3

  1. Define a Burplay session based on the cookie issued by the application for the low-privileged user

The session can be defined by selecting a cookie name and value in any request or response view within Burp:

10417_88260e21-624b-4c88-b9a1-b200ffd9c83a11450_b9ad63d1-ff1e-467a-8ca3-4cccbad5d131

5. "Apply" the newly defined session as a modification in the Replay tab:

10638_92d07e38-6b02-4b90-89fc-cfa406d008d2

  1. Start the test by clicking the "REPLAY!" button.

12658_f30a2dba-cb01-4df6-9ffb-7de56b51eb2b

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.

Conclusions

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

References

Latest SpiderLabs Blogs

Ukrainian Intelligence Claims Successful Compromise of the Russian Ministry of Defense

On March 4, 2024, the Telegram channel of the Main Directorate of Intelligence of the Ministry of Defense of Ukraine (GUR) was updated with assertions that they executed a successful cyberattack...

Read More

Cost Management Tips for Cyber Admins

As anyone who has filled out an expense report can tell you, cost management is everyone's responsibility. Organizations must apply a careful balance of budget planning and expenditures that are in...

Read More

Resurgence of BlackCat Ransomware

Updated March 8: Based on our experience, we believe that BlackCat's claim of shutting down due to law enforcement pressure is a hoax. We anticipate their return under a new guise or brand after...

Read More