07 Feb, 2014

Challenges of Mobile API Signature Forgery with Burp Intruder

by Patrick Cooley

Recently while working on a project, I came across the need to test a mobile API for enumeration. The tool of choice for this project was Burp Intruder.

The first challenge I came across was automating the signing of each request. Many web APIs use a signature parameter to verify that the request was sent by the mobile application. Typically this signature works by hashing each parameter, the current epoch time, a nonce and a shared secret. This signature is then sent with the parameters to the API server. The server then performs the same hashing function, with the parameters and the shared secret, to determine if the parameters have been changed. By reversing the mobile application, I was able to view the code that did this. Next I took a look at Burp Intruder and its extender API to determine how to write a plugin to make use of my signature forging function. To make things simple most of my parameters would be generated by Burp Intruder.

It didn’t take long for the next challenge to come up. As I was setting up Burp, I quickly noticed Intruder’s “copy other payload” type did not include an option to use more than one payload as its base. Since I needed to create a hash with multiple payloads, I had to seek another option. The Burp Extender didn’t give very much insight on how to accomplish this task. I reached out to Portswigger through their forums to seek additional insight. Although their team was quick to respond to my request, I was informed that unfortunately, Intruder payloads currently couldn’t handle this task. However they did point me in an interesting direction, using a IHTTPListener.

Their suggestion was to use the IHttpListener interface to intercept http request messages sent out by Intruder and capture the payload parameters needed to generate my signature.

Let’s take a look at the code.

Within the IHttPListener interface we need to override the default processHttpMessage function. This function is responsible for listening to all HTTP requests and responses going through Burp. This function will also handle the bulk of our work.

Let’s breakdown the code a bit.

In line 9 , we are setting a variable of type byte equal to the request message. Next in line 10 , we are creating a variable called sig_param equal to the value of the signature parameter. This line will serve two purposes for us, first by setting it to the value of signature in the message request, a null value will tell us that there is not a signature parameter in the request. We can use this to help filter through the messages to determine if its interesting to us. Secondly, we will use the sig_param to hold the value of our final signature.

Above, in line 1 , we are filtering out messages that are not what we are looking for. We are verifying that the toolFlag is set to 32(Intruder), that the message is a request, and also that there is a signature parameter present in the request.The next few lines (3-5) we are pulling the parameters from the message request. To do this we are using helper function that lets us pass in the message byte (request_byte) and the name of the parameter we want.

Here we are taking our three parameters from the request and putting them into a custom signature generating function, calcsig. Since the way signatures are generated will be tailored to the specific API you are working on, specifics of this function are not in scope of this article.

Line 1 is where we use another helper function to create a new parameter for our signature string, and set it to the sig_param variable. In line 2 we are updating the request_bye variable with the new signature parameter. Lastly, in line 3 we replace the request with the updated request_byte, and send it off.

This is where I ran into my final challenge. Going back into Intruder, I noticed that when comparing the request and responses from my attack session, the requests did not have the proper signature parameter shown in the results table. Since the HTTP requests were updated after they were sent out by Intruder, it had no idea that the signature changed in the request before going out. Luckily looking through sample code on the Portswigger Extension site I found a quick solution. Portswigger has a sample plugin that adds a logger tab to the Burp GUI. With a few quick edits to this plugin I expect to be able to display the positive results including both the final request and response in a new tab. More about this in a later post.

For more details about the logger extension please visit Portswigger’s site: http://blog.portswigger.net/2012/12/sample-burp-suite-extension-custom.html