BToD Comparer tool & Basic Detection of BSQLi

This morning's Burp Suite Tip of the Day (BToD) will be about the use of the tool 'Comparer'. In this instance we are analyzing responses to our SQL Syntax (via SQLi). We are detecting SQL Injection but this technique can be used to modify your SQL Syntax to perform the attack correctly as well.

Today's tip is not completely about Comparer since we are also utilizing repeater as well which I've covered in the post Using Repeater.

So I've found my targets administrative login page. Maybe I've used "google" via "site:example.com filetype:asp inurl:/admin" search or simply had the directory listing up front. Either way, we have a target.

Overview:
We've sent the Login submission page to the 'Repeater' tool already and are going to begin testing the individual parameters for SQLi. The most basic test we are going to run is one tick/two tick i.e. Login_username=' and Login_username=''. We are interested in variances in the response based on this input. As a baseline, we've entered known incorrect credentials to the application (Login_username=Bugs+Bunny)and reviewed the response. This application uses the HTTP '302' Method (redirection) to throw users back to the main page in the case of invalid credentials.

This is important because if we were detecting Blind SQLi (which is what folks usually use the One tick/Two tick method for) we'd most likely be submitting the value 'null' when submitting Login_username=''. If SQLi is present, the null input should throw us back to the main page based on what we know of the application's behavior regarding invalid credentials.

To summarize, what I am showing you is not in any way shape or form a subtle difference in the application's response based on SQL Syntax. This is obviously not Blind SQLi. However, using 'Comparer' you most certainly would be able detect ANY difference(s) in the application's response.

Lets demonstrate this whole process and get familiar with the 'Comparer' tool.

We send the request to the application and await the response. This shows the single tick mark request/response.

Next we take the response to this request and send to comparer by 'right-clicking' on the response and choosing 'send to comparer' like so:

Repeat this previous steps only this time submitting the two "tick" marks.

(Sending to the 'Comparer' tool)

Navigate to Burp > Comparer. Screen would look like this:

Above you will notice I've highlighted #5 and #6. These are the numbers assigned to each piece of data you've sent to 'Comparer'. This is simply a nice feature for keeping track.

Okay, so now we want to analyze the differences in these responses. Now, obviously, we can see that a huge difference between these responses exist. One response is 514 bytes and  the other 16607. However, IF this was the case of an error handling page that was different from the normal response but only very slightly (Blind SQLi) we'd be in luck.

Anyway, for sake of providing an example, you'd click on 'compare.....' (bottom right) > words/bytes and the "word compare" screen will pop-up:

Three areas have been highlighted (well by me anyways). You can analyze words or hex so those options exist individually on either side. However, when both responses require scrolling and you'd like to compare side-by-side.........check the 'sync views' box. This is of great help. Also, when this box is checked you will notice that you only have to click text/hex on one side of the word compare tool and the other side will match up automatically. Also a great feature.

Happy Hacking!

BToD Ajax & 'Find References' (Pro version only)

Apologies in advance, this post is only helpful if you have the professional version of Burp Suite which can be purchased Here.

This post (specifically) is meant to help folks who test sites utilizing AJAX but the 'find references' function of Burp Suite Pro can be utilized for other reasons as well (of course right?).

When testing an application in which you've found a vulnerable AJAX function, it is beneficial to the customer and your report to note everywhere this function is used within the application.

To use this function it is quite simple. Once you have COMPLETELY finished testing (or at least this is how I do it) and its reporting time, you locate the vulnerable function in your target listing, right click, and click 'find references'. It looks like this..........

Then a results table will pop up with everywhere this function was referenced (my shows none because this was not a real test).

Ensure you check the responses section of where this function was referenced. This is where JS is laid out so it makes sense this is where you will find the function.

Okay, so that is it. Not much to it but something certainly, IMO, worth noting.

Happy Hacking!

BToD / Client SSL Certificate & CAC

Today's Burp Suite tip is a bit different and is based on some personal headaches I've had and what I've learned this week.

Burp comes with the ability to load PKCS12 Client SSL Certificate. This is a great feature. It is located under Burp > Options (recent versions of Professional) or Burp > Comms (Free version/outdated) and looks like this:

This relates to my situation. I must test a web application using a Common Access Card. I want Burp to establish this SSL relationship with the web application in the same way my browser would. So some things I learned about PKCS12 this week and how to work with Burp.

1) If you can export the certificate then go ahead and passphrase protect it. Burp will ask for your passhphrase accordingly.

2) If and ONLY if the certificate AND private key are marked as exportable will your middleware allow this to happen.

3) Your middleware (my case ActivClient) does not allow the software that exports the cert + private key such as IE, Outlook, etc. to do so when the "not exportable" flag is set. If this flag is set you will notice an attempt to export in IE will look like so:

BTW, to get to this point in IE you would go ahead and navigate to tools > internet options > content > certificates > and choose your certificate and export.

4) If this "Yes, export private key" option is greyed out you will only be able to export in the DER encoded binary x.509, Base-64 encoded x.509 and PKCS#7 format.

5) Again, we need PKCS#12. If your "yes, export private key" is NOT greyed out you are luckier than I. Enjoy and continue on.

6) If not, then you need to ask the Issuing Authority for a copy of your cert + private key with the "not exportable" flag turned off. This can be in either .p12 or .pfx since .pfx (windows version of .p12) can be renamed and work fine or so at least I am told.

Okay, hopefully anyone who has to test sites with CAC/PKI enabled will find some use.

Happy Hacking!

BToD Using Repeater

Today's tip is regarding the use of repeater. Essentially, I've seen folks modify intercepted requests in their Burp proxy and then submit them to the application and view the response in the web-browser when this is certainly not needed. I've certainly neeeever done this :0, mmm okay okay we are all human. This technique is certainly beneficial in some instances but other times it is very much wasted energy. One good example is waiting for time delays.

If you are probing for Blind SQL Injection and are using time delays......the need to request and subsequently view the response in browser seems unnecessary. So, just a quick intro to repeater and hopefully some time can be saved. Lets get started shall we?

Throw your request into repeater by intercepting the request in your proxy or using proxy history. To do so, right click on the request of interest and select 'send to repeater' like so:

Navigate to the repeater tab and modify your request. In this example I show every tick mark and space URL encoded because I want the point to get across that your repeater content must be modified in comparison to the web browser that performs any encoding for you. So we are ready to fire:

At this point simply click 'go' in the upper left hand corner. You can modify the time accordingly and increment however you may choose. Just make sure to have a stop watch to time the responses for variances in the response.

Three other repeater features to note.

1) If you are testing for forceful browsing OR in our case we know using SSL encrypts and bypasses IDS/IPS detection signatures and we would like to send this request in SSL you can check the 'use ssl' highlighted here:

2) If you notice that you are annoyed by the amount of Repeater tabs you have open you can always choose to delete a tab like so:

3) It may be necessary to follow a '302' redirect sequence all the way to (hopefully) a '200' response. To do so, you can choose this option here:

Happy Hacking!

Obfuscating your IP using a Burp/Tor/Prixoy combination.

Approximately a year or so ago @jack_mannino and I were banging our heads against the desk trying to figure out a good way to obfuscate the source of our web traffic while maintaining the use of our intercepting proxy.

When we figured out a viable solution, we had some beer & pizza, talked for a bit and realized we should share this with somebody. Jack wrote a blog post about it Here. Then Mubix suggested we should make a video. I didn't have much time to go about editing the video so Mubix did that for me. Thanks again Mubix.

Burp through Privoxy and Tor from mubix on Vimeo.

I hope somebody gets some use out of it.

Happy Hacking!

BToD > Intruder & Dates

Tonight's Burp Suite tip is super basic. You have a parameter that is clearly a date. So you want to re-submit the same request iterating thru various dates ONLY.

For example, lets say a company is going to offer a special (kind of like that pizza company a few months back) but haven't released it yet. Well you may want to submit various dates, FUTURE dates, to see if a response with a coupon pops-up.

In the example below, I found a date parameter which did not fit into Burp Suite's preset list of date formats. In this case, its very easy to create your own custom date format.

Firstly, send the request containing the date parameter to fuzz over to the Intruder tab. Catch the request in the proxy (or use the proxy history), right click, and 'send to intruder'.

You now need to select your target or where your payload is to be set. Navigate to Intruder >  Positions and select your target. Add the variable symbol on either side of the target (the date) by clicking the 'add' button. Should look like this:

At the Intruder > Payloads tab you will notice the 'payload set'. Use the drop down menu that says "preset list" by default and select 'dates'.

Okay, here is where we want to do some customization. So to keep it short, I will only fuzz 3 different days. You can get the gist from the picture but the portion I want to touch on is 'format'. Click the radio button format where it does NOT have a drop down. This is where you can enter your date. So our parameter was 2009_9_7 which we can safely assume is year, month and date. So I will enter yyyy_M_d. If I was to enter yyyy_M_dd then the day would switch to 07 vice 7 which would be incorrect according to the format. So all in all it should look like this:

 

You are done! Now go to the very top, choose the drop down for Intruder and click start. 

Note: This is very customizable so ensure you play around a bit modifying the 'step' field from 1 day to 1 month, etc etc. A lot of functionality to toy with here so try it out.

Happy Hacking!

Burp Suite Tip of the Day (BToD) Sequencer & Entropy Analysis

Back with another tip. As pointed out by @rybolov's comment on twitter, Burp Suite may be somewhat difficult for folks new to the Suite of tools. One thing that I find interesting is how folks that use the tool (like myself) can learn something new everyday. Sequencer is one of the tools included in Burp Suite that I think requies a bit of an introduction. Once understood, this tool along with Intruder can be a powerful session attack combination.

You will notice I define Burp Suite as a suite of tools and this is for good reason. It is truly my belief that this tool is fast becoming a one-stop shop for dynamic analysis of an application. The free version of the suite is excellent but for those who test professionally, tools such sequencer and intruder must be threaded otherwise valuable functionality might be lost. I say this because when breaking a session token sequence to hijack a session....... timing is critical. With that in mind, show @portswigger and yourself some love by purchasing the product at portswigger.net.

On with the tutorial. In our example, we have registered for access to the site. We have also identified a login submission form. After successful authentication with a limited access user account we are provided a cookie 'set-cookie'. The idea is here is since we can log into the site and are provided only one session value (the cookie) we might be able to submit another user's cookie value and access the site with their account. In other words, session hijacking!

For example, I'm given session value abcd1112 and using sequencer I've noticed that only the last four digits change. The response would be abcd1113 abcd1114 up to abcd1212. So I've evaluated this session value and noticed it has extremely weak entropy.

My next step would be to request a resource just beyond the login form such as welcome.php and do this in a threaded fashion manipulating my cookie value using Intruder. The responses might vary in byte length. For instance I've noticed a large byte return in one instance indicating more functionality returned so this might be an administrative account.

So the first thing we would do is send the request that triggered a cookie value to be set to sequencer like so:

At the Sequencer > live capture tab we want to select the cookie to evaluate which would be the value immediately following 'set-cookie: badentropy='.  The selection drop down is highlighted in red.

.

After we've clicked 'start capture' in the lower right hand corner in the Intruder > live capture tab we've a screen will pop-up like so:

By default, 100 session values will be evaulated and only after this is completed can you analyse the entropy. Burp Suite analyzes this for you btw ;-). So after the 100 session token values have been generated we've clicked the 'analyse now' button at this screen and determined that the site only increments the last four digits by 1 and sequentially by viewing the summary tab in this screen. So this is extremely weak entropy. Lets try to exploit it!

Send the request for http://www.example.com/welcome.php to intruder like so:

Now because the last value provided at the sequencer BY the application was badentropy=abcd1212 we will start at abcd1213 when positioning our payload.

I've already provided a tutorial on my blog how to use Intruder > numbers so the rest of this can be referenced at intruder/numbers paylod.

The thing to remember here is that you are looking for items of interest like varying byte length and response code. Obviously if you are given a 302 response when incorrect credentials are given and you've observed this in some of the responses and not others this might be a sign that the cookie submitted is not a valid. If the 200 response received in the other cookie values are all approximately the same size in byte length except for one or two those might indicate privileged accounts.

Hope this tutorial helps someone and as always, happy hacking.

Burp Suite Tip of the Day (BToD) Proxy > HTML Modifications/Match and Replace

Today's tip is just purely based on some experiences I've had during testing. The gist is that some developers choose to render the application in such a way where obfuscation IS the security. So I will explain the scenario and then how to modify proxy options to uncover the obfuscated data.

It is true that you will eventually, when performing manual dynamic analysis, review the source code of every response. However, in my case, directly after building my site map I simply take a look and annotate the interesting finds and input that I may want to test.

To keep track of these annotations I prefer Dradis 2.3 and if you have any questions on using this tool might I suggest one of three routes. The first is to join the community Here. The second is to contact etd, the creator, on irc at irc.freenode.net on the #dradis channel. Lastly, etd is on twitter twitter.com/etdsoft and I highly suggest following him anyways!

Anyways, on with the tutorial. So, both @jack_mannino and I observed a situation, where a site loaded content from another site they managed via iFrame. Now the trick is directly calling the site being loaded in the iFrame to try and gain unauthenticated access to MAYBE an exposed default directory. We were in luck, there was in fact a default directory exposed. When requesting this resource however we received a 200 but with a redirection occuring in the browser? The page rendered fully in the response. WTF? Well what controls said redirection? Ahhh, JavaScript! So what happens if we strip javascript? Fully functionality! Sweet.....

Okay, so on with viewing the site with JavaScript disabled. Lets use burp to strip the JavaScript!
NOTE: Personally, I recommend always viewing a site with JavaScript disabled AND cookies disabled.

Navigate to Burp > Proxy > Options. Scroll down until you see 'html modifications' and check remove all JavaScript. Its really that simple.

 

 

The next scenario is where full administrative functionality was provided in the response BUT it was commented out. Again, wtf.....seriously? Obfuscation = fail. So if you want to just automatically remove the characters that control comments so that everything is rendered do the following. On the same page, navigate down to 'match and replace'. Choose 'response body in the drop down bar' like so:

Now in the 'match' field enter in the 'match' field this time and in the 'replace' field just leave this blank. When you are finished it should look like:

Happy hacking!

Burp Suite Tip of the Day (BToD) Intruder > Using recurvsive grep for SQLi

This post was inspired by both @portswigger book entitled "The Web Application Hacker's Handbook" and reminded and reiterated to me by @jack_mannino. Portswigger is obviously a legend in the community and Jack is a just a really really experienced Appsec/Pen-test/SE so I encourage you to add/follow both on twitter!

Anyways, accolades aside, lets begin shall we?

So it is pretty simple. You have SQL Injection. Its in the USER_ID field. This value is actually a string value which equates to a user name. So for instance, the value might be 'jdoe' (first initial, last name). Your SQLi looks like: ‘ or 1 in (select min(username) from users where user_id > ‘j’)-- and this returns

Microsoft OLE DB Provider for ODBC Drivers error ‘80040e07’
[Microsoft][ODBC SQL Server Driver][SQL Server]Syntax error converting
the varchar value 'jdoe’ to a column of data type int.

Okay, so we know we can do this alphabetically!

Essentially the next command you would inject would be

‘ or 1 in (select min(username) from users where user_id > ‘jdoe’)--

This returns

Microsoft OLE DB Provider for ODBC Drivers error ‘80040e07’
[Microsoft][ODBC SQL Server Driver][SQL Server]Syntax error converting
the varchar value ‘jdos’ to a column of data type int.

Alrighty, we don't want to continue this process manually do we? It is like. we want to extract all of the user names in a beautifully automated fashion right? Okay, here we go.

Capture the SQLi request in the intercepting proxy of burp. Right click on it and send to intruder.

Now the next part is important. We are actually using the server RESPONSES as input for the payload. Pretty awesome right? Navigate over to Intruder > Options tab. You need to select the portion of the response that gives you valuable information as the input. So in our case, anything after the varchar value ' is what we will use. This will be where the username is extracted. We want to end the string at ' as well because the string is returned between two single quotations. This is how it should look for your options:

Now you just need to choose the payload. Navigate to Intruder > payloads. Choose the payload 'recursive grep' from the drop down list. I've created my first payload at 'j'. It looks something like this.

At this point you are almost ready. Just choose your position. I've shown you how in this pic (clicked 'add' and placed j as the position to use the payload)

Now you are set. Go to the very top of Burp Suite, drop down from Intruder and click 'start'.

Comments and suggestions for the next post are welcome.

As always, enjoy and happy hacking!

Burp Suite Tip of the Day (BTod) > Intercepting responses

Today's post will be short. Long day, lots of work. Intercepting requests TO the server using the Intercepting proxy within Burp is just as important as intercepting server responses.

To intercept server responses, navigate to Burp Suite Proxy > Options and scroll down to 'Intercept Server Responses'. Ensure 'intercept if' is checked and choose 'add' and choose the following options.
AND - HTTP METHOD - DOES NOT MATCH - "insert a string you wont see here" (I chose a bunch of 6s).

 

Happy H4xx0r1ng