Automated security scanning has always been a challenge for applications that implement custom authentication mechanisms. Have you ever come across a scenario in which automated tools have failed to scan an application because of an authentication failure? Most automated scanners replay login requests to authenticate when a session expires during a scan.
We encountered such a scenario on a recent engagement. The application being assessed had implemented client-side encryption and hashing techniques to map the user’s credentials to a one-time string. The tool was unable to deal with this situation because it replayed login credentials to the server for authentication. This behavior may result in an unsuccessful post-authentication scan, and the results will not cover all critical areas of the application.
Further, the application can perform obfuscation at the client side using multiple techniques. The logic of converting the credentials can differ from application to application. Most financial and health-care applications implement such a strategy to defend against password compromises. In this post, we will provide an approach to scanning applications that employ such techniques.
To demonstrate, we created a sample application that creates a hash-based message authentication code (HMAC) of the user password to convert the client password into a one-time string. A unique HMAC is sent for every login request even if the same combination of username and password is used.
The server receives this HMAC from the client and calculates its own HMAC using server-side parameters to verify the value received by the client.
Sequence of steps
- The user requests the login page from the browser.
- The web server responds and sends the login page, which has a random key embedded in a hidden HTML field. (This random key is used to calculate the HMAC of the password.)
- The browser renders the login page.
- The user provides the password and submits the form. The client-side script calculates the HMAC using a random key and the password. The resulting HMAC and username is then sent to the web server in the form “HMAC(K,P1),” where K=random key and P1=password entered by user.
- The server verifies the HMAC shared by the client and creates the session if “HMAC(K,P1)==HMAC(K,P2),” where P2 = password stored at server side.
The HMAC sequence of operations.
The application is deployed locally on port 8080:
The login screen.
To analyze the application’s behavior, let’s use an intercepting proxy tool such as Burp. The browser is configured to pass all traffic through Burp. The login page (loginPage.jsp) contains the one-time key, which is used to generate the HMAC. When the user enters their username and password and submits, the client-side script uses sha256_HMAC to convert the user’s password to HMAC.
The “loginPage.jsp” HTML source with random key.
The sample application is designed so that the HTTP request for authentication is dependent on the random key, shown in the preceding image, along with the credentials. This prevents replaying the authentication request, as we discussed earlier.
The following screenshots depict two subsequent login requests using identical user credentials.
Login request 1:
The first login request in the Burp proxy.
- Original password: “admin”
- Random key: 278
- Converted password (one-time string): /9qxmu3SEWdypUPBZi7F0hXzW3TYsvy5OXUKO3a9BXc=
Login request 2:
The second login request in Burp.
- Original password: “admin”
- Random key: 70
- Converted password (one-time string): KyFY7vOslTcFhfkZCbLmw5j76Tj4bJXdFVnHiH/FQhw=
From the preceding screens we can see that the login requests have different values for the password parameter for the same user credentials. This poses a challenge to an automated scanning tool because it cannot the login sequence.
Burp provides the Burp Extender, in which we can add our own extension code. It can be handy to overcome this issue. We will use this feature from Burp and write sample extension code that will simulate the process of the client-side encryption and hashing techniques to obtain the mapped one-time string. (For a quick introduction to writing Burp extensions, refer to http://blog.opensecurityresearch.com/2014/03/extending-burp.html.)
The extender script can be triggered whenever the session becomes invalid. The logic for checking session validity and when the extension script has to trigger can be configured using Burp’s session handling rules.
The scope for this rule can be applied on any Burp tools—Intruder, Scanner, Repeater, Proxy, etc. If the proxy tool is selected in the scope section, any request from the proxy tool will be subjected to the configured session handling rule.
To define the scope of a session handling rule, navigate to Project options->Session Handling Rules->Add/Edit ->Scope:
The scope tab and the tools for which the session handling rule will be applicable.
The technique we have shown in this post can be used with any proxy-aware automated scanning tools. Creating the Burp extension allows you to scan the application using Burp as well as other third-party tools.
Proxying the automated tool via Burp Proxy can be useful for performing robust post-authentication scans. Burp ensures that there is a valid session throughout the scanning process. This technique can perform scans using Burp tools such as Scanner or Intruder as well as third-party tools such as sqlmap. In our next post, we will explain our step-by-step procedure with the sample Burp extension code.