Intro
As cybersecurity professionals at Gray Tier Technologies, our continual goal is to share discoveries & flaws we keep finding on our commercial penetration testing efforts. These findings are not one-offs, they are habitual discoveries. Our effort in our sharing is to protect everyone’s data by helping to identify those secure weaknesses and flaws as part of our cyber threat protection plan. We believe that knowledge is power and shared knowledge is empowering. Websites are continually created hastily with deadlines and budget concerns. We find these flaws in many of our targeted business sectors like financial, healthcare, federal, and education. The IDOR and authorization flaw in Oracle APEX is an example of the hunting conducted by Gray Tier assessors.
APEX
APEX is a web application development platform that comes with all Oracle Database editions. The APEX platform is commonly used as a web application platform in government and enterprise environments.
This short demo will describe how the author discovered implementation bugs in a Production client system using OWASP Testing Guide methodology and the Burp Suite web proxy.
Fingerprinting the Web Application Framework (OTG-INFO-008) occurs during the Recon phase by referencing the developer’s documentation, previous pentest reports, and observation of clues from the app itself such as the url scheme:
http://my.app.com/pls/apex/f?p=4350:1:220883407765693447From these clues, we confirm that we’re dealing with an Oracle Apex application, and can then reference the APEX Documentation to understand the url scheme.
We also take a look at the site map in our web proxy which results from browsing the site manually and using the spidering capabilities of Burp Suite. We note that for this type of application, all pages are referenced by the same domain and path, with the only variation being the numeric sequence after the “?p=” parameter. We can simply manually manipulate the numbers in each stanza and determine that changing the second number takes us to other pages within the same application. We may also find that changing the number in the first stanza takes us to a different application altogether. It’s important here to remember your assessment scope and only include any newly discovered applications in your testing if they are part of your approved testing scope!
Again, looking at the APEX Documentation we can confirm our suspicions from our manual testing: the number in our first stanza (4350) represents the application ID, the second stanza holds our page ID, and the third stanza is a session identifier.
While manual testing may yield results, we can quickly determine ALL the page ID’s that the application allows us to access using Burp’s Intruder tool as follows:
1) As a low-privileged user, capture a request in the proxy and send it to the Intruder tool. Set your payload position on the pageID parameter
2) Under Payloads, choose the “Numbers” payload and set an appropriate range you’d like to test. Checking your site map should give you a good idea of the range of pageID’s in use by the app.
3) Run Intruder and make a list of any pageID’s that return a valid result.
Armed with this information, we now want to see if we can use this information to circumvent the security assumptions of the app developers. In particular, we want to see if we can manually change our pageID to access resources that should be accessible only to a user that holds a different role or privilege, access objects or functionality outside our authorization scope, or test for multi-step functionality that we can access out of order. These tests correspond to the following from the OWASP Testing Guide:
Testing for IDOR and Circumvention of workflows is similar to the above. Rather than looking for privileged pages, you instead want to look for pages that reference an object or functionality that was not intended to be accessed directly, or not intended to be accessed outside of a particular workflow.
One example that this tester found often in APEX applications was deprecated functionality that was unlinked from other pages but was not fully removed from the application. Likely the developers created new functionality (with a new pageID), unlinked the old page from the workflow, and replaced it with the new page. They probably fully intended to go back and delete the old functionality but in most fast-paced dev shops these kinds of tasks can easily be missed or forgotten about. By manually browsing the list of page IDs from Intruder, the tester was able to find deprecated file upload functionality, unlinked from any other page, that allowed a low-privileged user to modify system data. So this could be considered both an IDOR and authorization bypass. Old unlinked functionality is also often a good target to test for other vulnerabilities since the functionality may not have been updated or maintained to the same standard as the rest of the application. So make sure to give pages like this extra attention in your testing.
Circumvention of Business Logic workflows would occur in the case where access to a similar file upload page was allowed but only supposed to occur after some previous validation or formatting steps. Instead, the tester is able to access the functionality “out of order”. To find these vulnerabilities, simply note any multi-page workflows in the application, record all the pageID’s involved in the workflow, and attempt to access sensitive pages directly without going through the workflow steps. The goal here is not just to access pages out of order, but to attempt to misuse the application in a security-sensitive way by bypassing certain workflow steps.
As the previous examples show, enumerating and testing the different pages in an Oracle APEX application is fairly straightforward but can result in discovering some serious vulnerabilities if the app is not well maintained. Here are a few takeaways that this tester has found useful in testing APEX and other applications:
• If you have access to previous pentest reports or reports using the same software version be sure to examine them as part of your Recon phase. Often certain classes of vulnerabilities will tend to re-occur in the same software. Even if previous instances of the vulnerability have been patched, often only the particular vector of the previous vulnerability was patched, but other vectors to trigger the vulnerability may still exist. Also, note when previously discovered vulnerabilities have not yet been patched.
• Understand the URL scheme in use and enumerate all applications (if in scope) and all pages as both a regular user and admin user. Leverage Burp Intruder to automate this process. Note which pageID ranges are correlated with admin functionality. Also, note any unlinked or broken pages that haven’t been removed from the app.
• Once you’ve found a particular testing vector you’d like to explore in an application, reference the OWASP testing guide to ensure that you have good testing coverage appropriate to the vector involved.
Happy Hunting!
James Dasinger