Misconfigured WAFs: Bypassing Broken Access Controls Protection
In this article, I will look to build upon the previous article I wrote on finding zero-day vulnerabilities in Oracle e-business suite.
The link can be found here: "Zero Day vulnerabilities on Oracle E-Business Suite" https://goo.gl/crZgQ7
What should you learn next?
In the article mentioned above, I mentioned a technique to bypass WAF. This article will, therefore, go on to explain the misconfiguration commonly found in WAF solutions.
Taking a step back:
In the article mentioned above, I found 12 remotely exploitable vulnerabilities with a CVSS score ranging from 4.3 to 8.2. In the below paragraph I will go on to explain the inherent problem with the product design.
Oracle E-business suite is an ERP application which comes packaged with many default user accounts (also around 10,000 default JSPs and 4,000 default forms). One such user account is GUEST. This GUEST account is the privilege given to any anonymous user before authenticating to the application i.e. when the user accesses the login page. An anonymous user with GUEST privileges should be limited to accessing only the login page, forget password page and maybe a couple of help pages. What Oracle has not considered is limiting access to critical JSP's, HTML forms and other XML files to this GUEST account. An attacker who knows the exact URL of JSP's can have access to it which allow him unauthenticated access to servlets which may allow functionalities such as uploading files on the application (CVE-2015-2652), allow viewing administrator password hashes, add, delete, modify certain data and also various other malicious activities which could affect the integrity and confidentiality of Oracle EBS. This vulnerability comes in the OWASP top 10 vulnerability called Missing Functional Level Access Control or Broken Access Controls.
The WAF Bypass
Here is an example of a test carried out for a particular organization during an assessment that was using a Web Application Firewall (WAF) in front of the application.
Image 1 – Request blocked by WAF
Image 2 – Same request with no WAF in place
What I found was the WAF blocked direct access only to JSP pages. However, I not only found unauthenticated access to JSP pages but also on HTML, XML and other extensions.
So instead of accessing JSP pages which were blocked, I tried able to access HTML, XML, and other extensions and to my surprise it was possible to get unauthenticated access to the application forms (HTML), XML and DTD files; therefore bypassing the WAF due to the misconfiguration in the implementation of protection against broken access controls.
Image3 - Unauthenticated access to HTML form with a WAF in place
Hardening the configuration in WAFs
Here are a couple of techniques used by web application firewalls:
- Flow control and;
- Login enforcement
Flow control technology is used to block direct access to unauthenticated pages, and hence the zero-day vulnerabilities were successfully getting blocked. However, due to the misconfiguration, it was not protecting completely against broken access controls.
To understand how the request is getting blocked, we need first to understand what the "flow technology" of F5 ASM is.
"A flow defines the access path leading from one URL to another URL within a web application. For example, a primary web page may include a graphic and a hyperlink to a secondary page in a given application. From a configuration standpoint, the flow is a data structure model representing web application components, such as URLs and parameters, and the interaction between them. The flow contains all of the data necessary for evaluating the information in an HTTP transaction. Flow data includes the referrer object, HTTP method, schema, requested object, and any parameters that the administrator wishes to include. Flow control offers an extremely robust, granular level of security for a web application by enforcing a sequence of permitted transactions. You can configure protection for specific URLs and specific parameter/value pairs of objects within the application."
Login enforcement prevents forceful browsing attacks where attackers gain access to restricted parts of the web application by supplying a URL directly. You can use login enforcement to force users to pass through one URL (known as the login URL) before being allowed to display a different URL (known as the target URL) where they can access restricted pages and resources.
The impact could vary upon the exposed HTML forms and files, therefore, it is highly recommended that WAF administrators appropriately configure flow control and login enforcement and harden the configuration to protect even other file extensions with HTML forms and not only dynamic ones.
FREE role-guided training plans
Sources
[1] https://devcentral.f5.com/questions/how-to-understand-the-flow-at-asm-48991