Inside the Mind of a Hacker: Attacking Databases With SQL Injection
Many developers don’t realize that by introducing security issues in their code they may be making a hacker rich. There is a bustling market for software flaws such as buffer overflow or SQL injection.
Case in point: The French company Vupen notoriously develops and acquires zero-day vulnerabilities and does not disclose them to vendors. At a Pwn2Own contest in 2012, the hackers from Vupen refused to share the details of a flaw in Chrome despite the fact that Google was offering a $60,000 reward. Instead, they decided to keep the information for their well-paying customers, Forbes reported.
The Types of Hackers
The world of hackers is split into three main categories:
- White-hat hackers are the ones who abide by the rules of responsible disclosure, notifying companies about vulnerabilities before making them public. Often they don’t require any other reward than recognition for identifying the issue. You may also hear them referred to as ethical hackers.
- Gray-hat hackers operate at the boundary of the law. They may be selling zero-day vulnerabilities to the bad guys or governments, although they would not break the law themselves.
- Black-hat hackers are the cybercriminals. They use zero-days to break into systems and steal data.
I am proud to say that I count myself and the entire IBM X-Force group as part of the white-hat category. In fact, I want to push the boundary further. Instead of finding the vulnerabilities before the bad guys do, I want to prevent them from being introduced in the first place.
I want to help developers put on their imaginary hacker hats and see their code through a hacker’s eyes. This type of exercise is called threat modeling, although it may have other names such as defensive programming. One of the best places to start is the most infamous software weakness of all: SQL injection.
A Notorious Example of an SQL Injection Attack
At some point in 2012, according to X-Force research, SQL injection attacks were responsible for more than half of all data breaches where the attack type had been disclosed. While that number has decreased in 2015, it is still one of the main attack vectors being used.
In 2008, cybercriminals made off with information from as many as 100 million debit and credit cards in the Heartland Payment Systems data breach. At the time, it was the largest data breach ever, and SQL injection was the culprit.
No wonder that SQL injection figures at the very top of the two most recognized lists of software weaknesses: OWASP Top 10 and SANS Top 25.
What Is the Programming Flaw?
SQL injection gets introduced when a developer concatenates user input into a database query. Let’s look at an example:
The code selects from the users table any record that matches the specified username and password. Leaving aside the fact that the password is stored in cleartext, the query can be manipulated and transformed by the user, which is never good.
Let’s say the user enters the following text as the username: admin’–.
The query changes as follows:
As a result, the user will login as the administrator.
The attacker will likely not stop here. As in the case of Heartland Payment Systems, the cybercriminal will take the attack to the next level and try to execute commands on the database server.
One way to do that is via the xp_cmdshell function in the case of MS SQL servers:
How to Prevent SQL Injection
A specific SQL injection software defense is the use of parameterized statements. The following example in Java uses a PreparedStatement class rather than concatenating the user-provided strings in a query.
This effectively prevents the injection portion of the attack in the Java code.
Word to the wise: Be careful with stored procedures. The Java code may be safe, but if the SQL code allows injection, there’s still a problem. This situation occurs when the SQL code uses the EXEC statement to execute commands constructed from the user input.
A more secure type of defense is input validation. Having an input validation framework is an excellent way to prevent all kinds of zero-day exploits — not just SQL injection. For example, why would you need to have single quotes or semicolons in a credit card number or numeric user ID? Many user-provided parameters only need to be alphanumeric, and that should be the default rule.
The best way of handling user input is with a white-listing approach. Use the most restrictive rule by default and allow special characters only by exception. This will greatly reduce the attack surface for many vectors.
Conclusion
The information above should hopefully help developers cause headaches for the gray- and black-hat hackers. Every time you use a prepared statement and enforce input validation, you are taking money away from attackers and saving your company lots of it.
The average cost of a data breach in the U.S. is $3.8 million. One zero-day vulnerability is enough to cause a data breach — even the biggest breach of the century.
You can also watch a video demo of SQL injection attacks to learn more about this threat.
Source | SecurityIntelligence
