Thursday, October 8, 2015

Using HEAD to optimize Time Based SQL Injection

Was conducted a application pentest on a client site and found that the website is vulnerable to SQL Injection. The DBMS is MS SQL Server.

The problem:

  1. There's a some sort of WAF or keyword filter looking for common SQLi payload such as 1 or 1=1 etc.
  2. Only successful test was via Time Based, but the page doesn't load with a consistent time pattern which  affects the result. 
  3. Automated tools doesn't help.
  4. Burpsuite able to exfiltrate the IP address via DNS request but I have no external domain to test it manually. (eventually after found a way to exfiltrate via DNS, the result obtained seems different from Burpsuite)
  • My friend suggesting me to use HEAD then to ignore the content as it is the reason why the page doesn't have a consistent time response.
  • Doing a some read on it and it works!
Change the method into HEAD at Burpsuite

Response now have a consistent pattern
  • Time to run SQLMap then. So, is there an option to use HEAD in SQLMap? Yes it is. --null-connection
  • However, SQLMap seems can't recognize it and the scan went failed. Probably I used a wrong options.
  • Now, how we can we obtained the result faster and reliable without performing it manually. Burpsuite have the answer :) 
  • We can use the Burpsuite to dump the information via Time Based SQLi technique. 
  •  What we need to do just :
  1. Change our Burpsuite's Timeout response to a value before our payload's value end. Example we want to delay the request for 10 seconds, so the value inside our Burpsuite should be 9 seconds.

  2. Set our intruder and make sure the request still via HEAD.
  3. Payload will be similar like 1;1'+if+((substring((@@version),§1§,1)))='§a§')+waitfor+delay+'0:0:10'—
  4. Use Cluster Bomb for the Attack type in our intruder so we can have two different attack payloads in Burpsuite.
  5. 1st payload type will be configured to use Number while the 2nd payload type should be alphanumerics and depends on you either to include special characters or not.
  6. Run the intruder :)
  7. We will have few results that have no status and length. That's actually the characters we are looking for. It became like that because the page will responded to TRUE and delay for 10 seconds. As we already configured to let our Burpsuite to have a timeout at 9 seconds, thus there'll be no result on it.
  8. Organized the result from our intruder and we can see our desire output :)


References :

Tuesday, February 17, 2015

Whitelisting goes wrong


Its been a while. No recent bounty post as I'm already slowing down on that and focusing on new workplace. But still doing my favourite stuff, pentesting :)

Last December, I did testing on one of the client's web application. Going to share one of the findings that for me quite interesting.

This application used purposely for state mapping service. A user can view the updated geoportal on their state by browsing to this application.

There are two frames available, on the left side shows the updated map while on the right side contain the updated information regarding the place where it being controlled by another application. The right column in fact actually, only being iframed on this geoportal site.

Making this thing interesting is that, the source for iframe point was already being whitelisted only that can be used on this geoportal application. Any that that it'll be rejected. Other known special characters also were properly filtered to avoid XSS attack. However, this URL source point can be controlled by a user!

A little of testing discovered that, the AWL used was quite poor because all it will check was actually must be in the source URL. So let say, I change the source URL into it will be a valid URL and that application will process the request.

Knowing this issue, I just create a HTML file containing XSS payload and then host it on my external server. Of course the name of my file will be

Owh well. that's how it goes.

bye :)