Category Archives: How do I test for …

Whilst using the Source Mapper extension in BurpSuite we noticed a few bugs and some opportunities for improvements. You can read more about the plugin in our earlier blog post. The improvements in this version include:

• More granular configuration
• Defaulting to injecting a SourceMap HTTP header instead of the SourceMap content comment in order to prevent conflicts with Sub-Resource Integrity (SRI) hashes
• It now also does CSS file source map injection

In principal this Burp Extension enables the workflow as it previously did, just now with fewer bugs and more configuration options.

You will find the source code here:

https://github.com/yg-ht/Burp-SourceMapper

It will also be integrated in the Burp Suite BApp store any day now.

And credit where it is due..! This version of the extension was led by Mia.

Using Burp to detect SQL Injection Vulnerabilities

I was working on a clients web-app the other day. I had to set off an automated scan using Burp across the site.  Burp is a great tool for providing coverage of web-apps and their vulnerabilities. It can be surprisingly good at detecting XSS and SQL Injection vulnerabilities.

For obvious reasons I can’t say which web app. But this particular one had JSON variables that were wrapped into a single “GET” parameter.  This something like this:

index.php?query={"name":"Felix","profession":"Geek"}

Burp had detected that it was getting some interesting output from one of the JSON variables when it inserted a single quote like this:

index.php?query={"name":"Felix","profession":"'"}

The output from the site was a fairly restrictive.

PHP error so didn’t immediately provide any particularly useful information. But was still reported in Burp as a potential SQL injection vulnerability.  Usually, if Burp picks up SQL injection, SQLMap sees it pretty much straight away.

So I fired it up and was hopeful… but nothing came up.

Having no result from SQLMap doesn’t mean there is nothing there.

So I decided to poke around manually to try and verify the findings. 

My aim was to reveal some useful information that I could relay back to the client to try so that I could positively confirm that there was SQL Injection.

When error messages produce no useful information you are at best looking at a Blind SQL Injection vulnerability.

Which means that it behaves correctly but doesn’t echo anything.  This makes data exfiltration very slow as essentially you have to play a “true” / “false” game with the SQL server. 

This particular error message was from a PHP function. It seemed to be complaining that it was receiving more data or at least data in a format other than that it was expecting.  What this means is that the error is only going to get produced when there is more data in the SQL return. Therefore the error message means my guess was “true”.  None of this is particularly relevant to my post though, just setting the scene.

I ran SQLMap again and this time I specified my Burp proxy server for it to use so that I could see the raw requests and responses.  Something like the following should do the trick:

--proxy http://127.0.0.1:8080

I could see in the Burp History tab that it wasn’t injecting in the right place, I had specified the right “GET” variable, but the reality was that it was only a small part of this variable that was vulnerable.  A little research later and I discovered that there was an option that would allow me to specify where I wanted SQLMap to play.  Along with your other options such as –level 3 etc. you need to do something like the following:

-u http://www.victim.com/index.php?query={"name":"Felix","profession":"*"}

Note the asterisk (*).  This goes where you want it to inject.  And voila!  This time it works.

Act before it is too late, contact us and learn how your organisation can prepare for cyber attacks

So assuming for a moment you have a list of hashes (getting them is another topic altogether) there are a number of ways of testing how weak passwords hashes are.  Ultimately, the strength of a password is the amount of time it takes to crack it, so that’s what you need to do. 

There are a number of ways of getting passwords including:

• Dictionary attacks
• Rule based attacks
• Brute forcing
• Rainbow table attacks

Basically the first three of these can be done with HashCat and the Rainbow Table cracking can be done with Rcracki.

First, you need to make sure that your input file is just the hashes themselves one per line.

How to perform a HashCat?

Then to perform a HashCat crack you have a few further options.  First one is to choose to run the crack on your CPU or your GPU.  Basically, your GPU is designed to deal with graphics calculations which also happen to be perfect for dealing with password cracking.  As a result, your GPU is MUCH MUCH faster than your CPU. 

Not everyone has a fancy graphics card though so here are the three options:

HashCat cracker (CPU):
./hashcat-cli64.bin -m[hash ID] [input file] [dict file] –rules rules/d3ad0ne.rule

HashCat cracker (nVidia GPU):
./cudaHashcat-plus64.bin -m[hash ID] [input file] [dict file] –rules rules/d3ad0ne.rule

HashCat cracker (ATI GPU):
./oclHashcat-plus64.bin -m[hash ID] [input file] [dict file] –rules rules/d3ad0ne.rule

(Swap the 64 for a 32 if your on a 32 bit environment…)

To get the hash ID, run the first part of the command followed by “–help” and you will get a list of all the codes.

If your up for cracking more you can also change the ruleset, create your own dictionaries (start with the rockyou list) by scouring the companies website and coming up with keywords, making word lists using HashCat’s mask processor and load the passwords already cracked back into HashCat and re-running.

To perform a Rainbow Table crack you need the following command:

./rcracki_mt -l [input file] [rainbow table directory]/*

And if you are lucky enough to have a nVidia graphics card, add the “-g” flag for the experimental, you won’t find this one in the manual as it is only in beta, there are some suggestions that this is not multi-threaded and that the gains are minimal. 

To get the usual help message don’t give it any command-line arguments.  There are extra options that you should use, like -t to select how many threads you want to use (hint. the number should be the number of cores your machine has).

YGHT can help you secure your technologies

Learn how by contacting us