Get with the program – mitigating attacks SQL databases

26 November 2014

‘Script kiddies’ are hackers who can’t necessarily code but are bent on digital mischief, and their favoured targets are poorly configured servers. Leo Waldock explains how a badly set up SQL database is an open invitation.

Structured query language (SQL, often spoken as 'sequel') is a special-purpose programming language designed for managing data held in a relational database management system. It's been around since the 1970s and the robustness of its underlying model is demonstrated by the fact that even today it is the industry standard in storing and managing data, especially on web servers.

That also means the language is very well understood by hackers, and SQL databases are a very tempting target. It's why the leading threat to online businesses is something called a SQL injection attack.

It is incredibly simple to execute. The attacker simply pastes a predefined string of computer code into the entry field on your website - the username box of a log-in page, say. The SQL database reads that string as code to be executed and starts to reveal all.

SQL injection is, according to the Open Web Application Security Project rankings, the number one website vulnerability. Technology website TechCrunch recently reported that Neira Jones, former head of payment security for Barclaycard, had claimed that 97% of data breaches worldwide are, somewhere along the line, still due to SQL injection.

Blockbuster SQL

It seems incredible that anyone can gain access to a database of usernames and passwords, especially after so many high-profile breaches, but the problem is that a company's website works in almost exactly the opposite way to an ATM. When you insert your bank card into an ATM, your options are limited: you can only access the account that is linked to your physical card; you have to use the keypad on the ATM to respond to a preset question (your personal identification number); and there is a daily limit to the amount of cash you can withdraw.

But you have no control over the hardware that connects to your website, which means your systems need to be relatively open and flexible. People aren't limited to a keypad to enter information - they can use their keyboard to mess around with any web forms that request a username and password or they can simply start modifying the URL in the address bar. For instance, they might add a single quotation mark at the end of the address, or add a condition such as 1=1 (which is obviously true) and see whether the web page ignores this comment. An attacker is hoping for a sniff of an opening where the database returns a message such as: "Error in your SQL syntax." That message is a way of saying: "This website has flaws; the door is potentially open."

"It’s better to pay a couple of thousand euros to someone friendly to find a security weakness than spend hundreds of thousands trying to repair the damage."

At this stage, the attacker might roll up their sleeves and spend hours attempting to wiggle open any faults they can find. But they probably won't bother. They're more likely to simply unleash a hacking tool with an exotic name such as Absinthe, Havij, Safe3 SQL Injector, SQLMap, SQL Ninja, SQL Poizon or The Mole.

And that's the really scary thing. A brief web search will reveal not only how to download and use these tools - which can reveal information such as IDs and passwords of users - it's also easy to find websites that will help decode encrypted passwords in seconds.

It's all business

Closing any SQL loophole, then, is vital. "SQL injection attacks are very much the easy pickings of the so-called 'script kiddies' and don't require a high level of sophistication on the part of the attackers," says security analyst Graham Cluley. "But they're easily defeated if people who are building websites have taken security seriously and have built their site from the ground up with that in mind. For instance, it's not hard to ensure that risky commands cannot be sent to web servers, and are filtered out before they can do any harm."

This isn't just a techie issue, either - C-level executives need to be aware of the risks too.

"It's one of the four red flags that came out of our Audit Insights consultations with the big six accounting firms," says Richard Anning, head of the IT Faculty at the Institute of Chartered Accountants in England and Wales (ICAEW). "Cybersecurity affects everything; it's not a discrete IT problem. You have to think of this as a business risk."

Low-hanging fruit

According to Anning, the others flags are: the need to assume that your systems will, at some point, be compromised; the resultant requirement to identify your "crown jewels" data that deserves heightened protection; and the need to get basic system set-up right, which could protect against up to 80% of attacks. That means asking simple questions of your IT team about testing against attacks such as SQL injection, and perhaps even hiring penetration testers to investigate whether any embarrassing security holes have been left open.

"It's better to pay a couple of thousand euros to someone friendly to find a security weakness than spend hundreds of thousands trying to repair the damage to your brand after a breach becomes front page news," says Cluley.

Best of all, closing an easy-to-fix SQL loophole in your website makes somebody else's site a more interesting target. And that's particularly important now that so many SQL attacks are entirely automated across millions of sites. Script kiddies are really only interested in the low-hanging fruit - the easy-to-access sites. Even basic protection means they'll probably pass over your database and move on to a less well-protected one.

The good news

Even if your database defences are breached, there are ways to prevent an embarrassing compromise of your users' data. If the stolen database table is properly encrypted, it is virtually useless to thieves. But it's more likely the data will be 'hashed', which means that it has been mixed up using a simple algorithm to scramble the characters.

A more thorough measure is to 'salt and hash', where you scramble the data and add extra data to further confuse the issue. Password cracking software generally tries to use brute force, testing word lists against hashed passwords, but if the encrypted version isn't the same length as the actual password, those brute attacks will fail.

"If the stolen database table is properly encrypted, it is virtually useless to thieves."

If your database table contains names, addresses and credit card numbers, then it has an obvious commercial value on the black market. But even if the table has no credit card information, it is still useful. The user name (especially if it's an email address) and password that one person uses to log on to Netflix or their online supermarket could be the same as the details for Amazon or Gmail. If you have a database of millions of users, you can be confident that a large percentage of the information will not be unique.

In other words, while you can't guard against lax security protocols on the part of your users - and simple hacks such as SQL injection are becoming more common - there are simple ways to protect against these attacks and to ensure even a breach isn't a disaster.

Now hack like a script kiddie

Even 'black hat' hackers, the malicious, system intruder type of hacker, look down upon script kiddies for their use of off-the-shelf tools that require very little skill. However, while a script kiddie armed with SQLMap might be an idiot, they can still be very dangerous.

Smarter Company magazine witnessed a security consultant, or a 'white hat' hacker (the term 'hacker' itself actually refers to anyone who can hack code), demonstrate the script kiddie's approach. First, he used a freely available list of sites with SQL databases (found after a brief web search) to select a target group of organisations - including companies, charities and even a playgroup. He then copied and pasted a tiny snippet of code (also found after a simple web search) and applied it to the end of each web address on that list. The third site returned a message indicating its SQL database was vulnerable.

Another line of code was pasted into the username field of this site and then, incredibly, it returned a list of other usernames and 'hashed' passwords. He copied the revealed passwords (still nominally secure with their basic encryption) and pasted them into a free password cracker on the web that used brute force to return unhashed passwords. The entire process took around five minutes. Ironically, it wouldn't have taken a programmer much longer to protect that organisation's site from SQL injection attack.

Guard against SQL injection

  • Use a web application firewall that filters web traffic. It should remove a significant number of threats before they hit your system.
  • Update and patch your application software based upon the advice of your suppliers.
  • Reduce the functionality of your database to the lowest practical level and use a limited-access account wherever possible.
  • Configure error messages so that verbose messages are only displayed on local machines inside your network. Remote machines should receive nothing more helpful than an 'unhandled error' message.
  • Avoid dynamic SQL unless it is absolutely necessary - and stick to prepared statements and stored procedures.
  • Filter user input from remote machines and separate data from commands.
  • The fundamental point is to assume there are script kiddies and hackers mixed in with your customers. Trust no one. And get 'white hat' hackers at reputable security organisations to test your websites.