Tooling, Tips & Considerations

[n0x00]

I thought we should have a place for us to learn from each-other and optimize best practices.

play nice and try not to be mean

[n0x00]

I’ll start…

Overcoming two stage authentication with burpsuite

A common scenario that can be slightly annoying if you don’t have this little tip under your belt

The authentication flow:

• You have a Username & Password
• You have a Passphrase / word that only 'random characters are required from each login - such as the 3rd,5th and 8th letter

In Burpsuite under Proxy > Options > Match and Replace you can spend a little bit of time entering some html from the page requesting the characters and modifying the value=’’ fields this will populate the right characters for a successful (automated) authentication

let’s forget the username and password that’s just a post request, let’s say we have entered that, and we are met with a page that tells us it needs the 1st,2nd and 4th character of my passphrase ‘hello’

lets assume the html looks a little like this:

... Letter 1:<input name="letter1" type="password" value="">

we know letter one is ‘@’ so we simply add the above line to the ‘match’ and then in the replace input we add the correct value to the number

Match: ... Letter 1:<input name="letter1" type="password" value="">
Replace with: ... Letter 1:<input name="letter1" type="password" value="h">

We want it to automatically work out the full phrase based on the HTML 'Letter 1,2,3,4 or 5 (and so on) so we preprogram all the letters to the whole phrase (reguardless of how log it is letter 1 will always be ‘h’ letter two will always be ‘n’ if that HTML code isn’t called in the page then the match and replace has nothing to action, nothing bad happens.

... Letter 1:<input name="letter1" type="password" value="">
 ... Letter 1:<input name="letter1" type="password" value="h">
 ... Letter 2:<input name="letter2" type="password" value="">
... Letter 2:<input name="letter2" type="password" value="e">
... Letter 3:<input name="letter3" type="password" value="">
... Letter 3:<input name="letter3" type="password" value="l">
... Letter 4:<input name="letter4" type="password" value="">
... Letter 4:<input name="letter4" type="password" value="l">
... Letter 5:<input name="letter5" type="password" value="">
... Letter 5:<input name="letter5" type="password" value="o">

Don’t forget to add comments - just in-case you forget or someone has to pick up your work

This is also useful for assisting automated tools through the same journey, My old work place we use IBM Appscan and it cannot work round this, it only does username password for web authentication, but it is proxy aware so you can push it through burp and let burp take care of the tricky stuff.

[n0x00]

URL’s From a threat perspective
A good interview question, and a fun one to think about…

http://secure.caseysleathermasks.au/shop/cart.php?i=13&cost=10.00&isadm=no&echo='you+just+purchased+the+choke+mask+<b>2000</b>!'

let’stalk about the possibilities here, look at the whole schema

---

( POST when we have exhausted this one)

[mazen160]

I can see the following possibilities:

• Reflected XSS in the “echo” parameter
• CSRF on purchasing products
• Privilege Escalation to the administrator session, by changing the value of “isadm” parameter to “yes”
• Logical issue where a use can buy the product with $0 to $1.
• And of course, “HTTP” + “secure” can’t be together

I guess that’s all obvious issues to think about from the first look.