The Havij SQL Injection Tool
Many of the recent high profile attacks follow a similar pattern. First, a web application is compromissed using SQL injection. Next, the attacker dumps the database using the SQL injection vulnerability.
Once the attacker has a hold of the database, the attacker will search it for passwords. In some cases, the password was not hashed, and in other cases, the hash was brute forced. The attacker then used the password to try and breach other accounts.
I will try to write up a few diaries discussing steps to defend against the basic weaknesses exploited by these attacks:
- SQL Injection
-
Unhashed or weak passwords
- Password reuse.
In this first pst, we will take a look at SQL injection.
The Tool: Havij
A few times before, I showed some of the attacks we see agains the ISC website. One notable change over the last couple years is an increase in SQL injection attacks. In the past, remote file inclusion attacks dominated. But now, SQL injection attacks have increased substantially, in particular attacks using the attack tool "Havij".
Havij is a simple Windows GUI tool to automate SQL injection attacks. Its capabilities are similar to tools like Absinthe and sqlmap. Personally, I think sqlmap is a more capable tool but it is not as easy to use as a click-kiddie friendly tool like Havij. Havij is distributed by itsecteam, an Iranian security company. The word "Havij" translates to "carrot" and indeed, Havij uses a carrot as icon. Havij works ok with simple GET requests. It does support POST but in my limited testing appears to be less reliable. In its default setting, Havij is easily identified by its user agent:
Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727) Havij
The attack method is pretty straight forward. Havij injects a "SELECT UNION" statement and keeps adding additional fields to the union query to work out how many columns are required. Each statement selects static "random" hex strings to make it easy to identify them in the response.
GET /diary.html?storyid=999999.9+UNION+ALL+SELECT+ 0x31303235343830303536%2C0x31303235343830303536--
Again a technique used by other tools as well.
Defense
Of course the best defense is to avoid SQL injection vulnerabilities in the first place. Did I mention yet that you should use prepared statements whenever possible? That and decent input validation will pretty much eliminate the problem.
Now I also know, that you probably got plenty of legacy applications and applications you didn't code. In these cases, you need a "quick fix". You could for example block the Havij user agent at your Intrustion Protection System or your web application firewall. A little mod_rewrite rule may work too. I find another decent string to detect the tool (and other SQL injection tools) is "%27+UNION+ALL+SELECT" . This string shouldn't have a huge false positive rate.
We covered SQL Injection a few times before:
http://isc.sans.org/tag.html?tag=SQL%20Injection
Update: Thanks to a reader for pointing out that Havij means carrot and that itsecteam is Iranian.
------
Johannes B. Ullrich, Ph.D.
SANS Technology Institute
Twitter
Application Security: Securing Web Apps, APIs, and Microservices | Washington | Dec 13th - Dec 18th 2024 |
Comments
Using Prepared Statements is sufficient to prevent SQL Injection attacks IF AND ONLY IF the library/driver/database you are using fully supports it. Some earlier versions of database servers did not support prepared statements on the server side, so if the library/driver supported the Prepared Statement syntax it had to build a string to send to the server. If the library/driver did not properly escape the bound variables, then you would still be vulnerable to SQL injection when using Prepared Statement on these databases. However if your database server and library/driver fully support Prepared Statements, then the SQL and bound variables are sent separately to the database server, so the server has no confusion what is data and what is code.
For the System Administrators:
Hajiv may have a simple plain text string you can search against in your IPS rules, but more stealthy approaches will use non-canonical UTF-8 and URL encoding to get past simple string matching. Be sure you canonical-ise all input before your match rules run.
Nathan Christiansen
Jun 7th 2011
1 decade ago
Steve
Jun 9th 2011
1 decade ago