The More complex Intruder attack is performed using the Burp Suite

Recently I did a penetration test where there was not much of an attack surface, but a firewall device and a browser-based SSL VPN service. With not much to do other than a few username gleaned from LinkedIn, this seemed like a worthwhile entry point. I want to be able to crack these accounts using Password Spray, and I also want some local users that might already be defined on the device, like root, fwAdmin, admin, etc. I wasn’t too worried about the accounts being locked, so I ended up trying to brute force them.

But there was a problem, as is always the case. Even with TLS encryption, the device does not submit a password in the HTTP request. Some sort of digest algorithm is used here, which looks like MD5:

In addition, the destination URL is different from its source form. Looking at the login process, I concluded that I first needed to request the form, collect multiple values, and finally do some sort of summary calculation using the password I provided. The following is from the login page:

I looked at “processButn()” and determined that I needed at least param1, ID, and sessId to build the response. My first instinct was to use Burp’s macros and parameter extraction capabilities to solve this problem. This took me further, but I ran into some difficulties. Specifically, I can’t implement how JavaScript handles payloads or recursive grep operations.

So, what is JavaScript doing?

It sets several cookies and calculates a CHAP response. Looking at the chapDigest() function, I see that the param1 and ID values in the form are converted from ASCII hexadecimal to bytes, concatenated with the password, and finally generated an MD5 and converted back to ASCII hexadecimal. This isn’t terribly complicated, but across two requests, the sessId has also moved from form fields to cookies, and I don’t want to get too deep into Burp internals.

Fortunately, I wrote an extension earlier that I often use to help solve these problems. You can download it here: github.com/GeoffWalton… .

Basically, it allows me to process or generate the Fuse payload using external commands. So first I need to make sure I can calculate the summary correctly. I don’t have the equipment to actually test a valid login, so I just use the browser to make the request, test the parameters in the local script, and validate the digest that matches the one generated by my browser.

I could have copied the script behavior, but it was easier to get JavaScript from the device. I found what I needed, then copied and pasted it into a local js[c] file:

Everything except the last line is taken directly from the device! I just need to take out the parameters and print out the summary results.

Now I need a way to get the value! I used “copy-as curl” in Burp and combined the results into a very small shell script. This script will be the actual command I call from the extension, which will then call JSC to run the JavaScript code inside. Finally, it will merge the output and the final result is easy to use for the Fuse payload:

If the page structure is complex, a Ruby or Python script containing some XPATH queries might be a more straightforward approach, but in that case it would be faster to put them into bash.

This script returns a single string without newlines, including most of the arguments I need to authenticate (by providing a password on standard input). It’s worth pointing out that Curl uses Burp as a proxy. This means Burp keeps track of these requests, so I keep a full request history if the customer needs it. Now I just need to set the Fuse attack.

Step 1: Send an actual authentication request to Intruder:

Next, I did some rearranging and editing to fit my script output. Notice that I include the cookie name as part of the replacement value. I also replaced the argument to my script output with the insertion point “x” :

Next, I skip to my extension’s tag and configure it to call my script:

Finally, I disallow requests that contain unmodified payloads and configure the payloads as shown below. Remember that they run from top to bottom and from left to right, so I need to fill in the cookie value by referencing Payload set 3 in Payload set 1:

Payload Set 2 = Payload Set 2

Finally, I set my password list on Payload Set 3 and use my custom Payload handler “Command” :

This is ideal for a Password Spray attack (not shown) that uses Sniper (an attack type within the Fuse tag), whereas for a Cluster bomb (another attack type within the Fuse tag), Burp only runs the payload processor once for each group. I don’t know if sessId can be used to repeat multiple logins on this device, so this could be a problem with this brute force approach, although I haven’t seen any output to indicate this. I’ve only done some Repeater experiments that show that the session expires after a few seconds.

Still, Burp is a great tool. You may ask, “Couldn’t you write the request with another curl command, Ruby, Python, etc?” Of course, I’ve already created most of the script logic. Burp still offers me a lot of value:

  • It keeps a complete request/attack history;

  • I have no idea what a successful login looks like, so I’m happy to be able to easily sort by the length of the response, and possibly use grep to match/extract later;

  • I can easily switch between Password Spray and brute force without having to rework my script;

  • I can visually check requests to make sure they look correct; Again, it is important that I have no valid login or device to refer to for testing.