As any web application tester knows, the most essential tool to have in your testing toolbox is a good intercepting proxy. This allows the tester to capture and edit requests being sent from the browser to server. I haven'ver compared all the proxies out there, but the truth is I've never felt the need to look any further than Burp Proxy. I LOVE Burp, and I keep falling deeper in love with it all the time. I've restrained from listing all the reasons why, as if you use Burp every day like I do, you'll be aware of its brilliance. Instead, I thought I'd share some of the potentially lesser-known features, or ones that are just a bit fiddly to configure, so that it saves you time when you come to do it.
Brute-forcing Basic Authentication
1. Trap the request containing the 'Authorization: ' header, and send to Intruder e.g:
GET /readme.html HTTP/1.1
Host: www.procheckup.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:35.0) Gecko/20100101 Firefox/35.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-GB,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Authorization: Basic YWJjOjEyMw==
2. Configure the payload position to encapsulate the Authorization header value e.g.:
Authorization: Basic § YWJjOjEyMw==§
3. Select the Payloads tab, and in Payload Options load your dictionary file:imageIMAGE
Payload Processing -> choose Add
Choose 'Add Prefix' from dropdown
and add:
username:
For example:
Payload Processing again -> choose Add
Choose Encode, Base64-encode
4. Intruder -> Start attack
Putting Burp into invisible mode to test thick clients
1. Set the target hostname (i.e. the server that the thick client is communicating with) to resolve to your localhost in your hosts file e.g:
127.0.0.1 targethostname
So that all traffic being sent from thick client to targethostname gets directed to your proxy instead.
2. Set Burp to listen on the target port that your thick client would normally connect to e.g. port 80 if its http://targethostname
2.1 So Navigate to Proxy -> Options and choose to Add a new proxy listener
2.2 Set the following:
3. You need Burp to forward all traffic on to targethostname. So :
Click on the Request Handling tab next and input the following:
i.e. Redirect to host: targethostname's IP
Redirect to port: 80 (i.e. the target server's port)
Select 'support invisible proxying'.
** note: make sure other programs e.g. IIS, Skype and Spotify aren't listening on port 80 **
Have Burp intercepting, trap and change, send to repeater just as you'd normally do.
Pitchforking
I recently had a request containing a username parameter and another parameter which was a corresponding hash of the username (e.g. MD5 of Helen). As the server responded differently to valid usernames, and therefore allowed verification of valid usernames, I wanted to iterate through a long list of usernames to discover which were valid. It wasn't enough to just send the request to intruder and fire a load of username guesses - as each corresponding hash had to be sent too. This is where pitchforking came in handy…
To do:
1/ Send request to intruder and choose Attack Type: Pitchfork
2/ For Payload Set 1 choose:
Simple list
And load your list of usernames.
3/ For Payload Set 2 choose:
Simple list
And load your list of usernames.
But this time add a payload processing rule:
Add -> Hash.
Select type.
Intruder -> Start attack.
See comments
In the 'Target' tab, right click and select 'spider this host'. Afterwards, right click and select 'Engagement Tools' -> Find comments, as shown below:
Click 'Search':
See if there is anything juicy in there.
Categories