Three best practices for reducing the risk of SQL injection attacks

This column is available in a weekly newsletter called IT Best Practices. Click here to subscribe.

SQL injection attacks have been around for more than 10 years. Database security experts know they are a serious problem. Now a recently unsealed Second Superseding Indictment against a notorious group of Russian and Ukrainian hackers shows just how damaging this type of attack can be.

The indictment provides a long list of companies that have suffered costly data breaches where the root cause has proven to be a SQL injection. According to the indictment:

Beginning on or around Dec. 26, 2007, Heartland Payment Systems was the victim of a SQL injection attack that resulted in malware being placed on its payment processing system and the theft of more than 130 million card numbers and losses of approximately $200 million.
In or about early November 2007, a related company of Hannaford Brothers Co. was the victim of a SQL injection attack that resulted in the later placement of malware on Hannaford’s network, the theft of approximately 4.2 million card numbers.
Between January 2011 and March 2012, Global Payment Systems was the victim of SQL injection attacks that resulted in malware being placed on its payment processing system, the theft of more than 950,000 card numbers, and losses of approximately $92.7 million.
In or around May 2007,NASDAQ was the victim of a SQL injection attack that resulted in the placement of malware on its network and the theft of login credentials.

I think you are beginning to see the pattern here. Other companies cited in this indictment as victims of attacks include 7-Eleven, JC Penney, Carrefour S.A., Wet Seal, Commidea, Dexia Bank Belgium, JetBlue Airways, Dow Jones, Euronet, Visa Jordan Card Services, Diners Club International, lngenicard US and an unnamed bank.
MORE ON NETWORK WORLD: Free security tools you should try

The indictment goes on to say that “conservatively, the defendants and their co-conspirators unlawfully acquired over 160 million card numbers through their hacking activities. As a result of this conduct, financial institutions, credit card companies, and consumers suffered hundreds of millions in losses, including losses in excess of $300 million by just three of the corporate victims, and immeasurable losses to the identity theft victims due to the costs associated with stolen identities and fraudulent charges.”

These particular breaches occurred in 2007. Think how many additional breaches, large and small, have occurred since then.

I think it will come to light that the recent Target, Neiman Marcus and Michaels breaches also might stem from SQL injection attacks of some sort. Though it hasn’t been made public, security experts are already saying that the Target breach used SQL injection to install malware on the point-of-sale systems where the attackers were then able to collect the card numbers out of memory. Many people don’t realize that SQL can be bidirectional. It can be used to drain the database but it also can be used to modify and upload to a database. An attacker can use SQL injection to upload the malware into the database system and then have that system send out the malware to all the POS endpoints.

Structured Query Language is flawed because of the way it was architected. It can be fooled into trying to interpret data as an instruction. On the other hand, there’s a lot of capability in SQL that makes it attractive to developers, especially for web applications.

Since the consequences of SQL injection attacks can be so damaging, I asked Michael Sabo of DB Networks about best practices that companies can follow in order to reduce their risk of this threat. Sabo says there’s no silver bullet, but he does have some advice.

“Often you will hear, ‘if you just do this, or just do that, the problem will go away’,” says Sabo. “But it’s not that simple. Any individual countermeasure can go a long way but it is not going to close the threat. It doesn’t work that way.”

He says that one popular countermeasure that is promoted by the Open Web Application Security Project (OWASP) is to write perfect code. “Even if I write perfect application code, I can still be vulnerable because the vulnerabilities come in through third-party software that I had nothing to do with,” says Sabo. “Look at Ruby on Rails. Who knew that the underlying framework was vulnerable? It affected 250,000 websites with a SQL injection vulnerability because those developers built their websites on top of the vulnerable framework.”

Sabo says there are instances in which they have found vulnerabilities in the relational database management system itself. “Oracle has had SQL injection vulnerabilities in the RDMS itself, so regardless of how good I write my application code, I can still be vulnerable,” he says.

Short of having perfect code, there are three critical things companies can do to reduce the risk of experiencing a SQL injection attack.

The first is to conduct an inventory of what you have as far as databases go, and understand their connections to applications. “Many companies are completely unaware of some of the databases in their environment,” says Sabo. “And even if they know about all their databases, often what happens is the database is being exposed on network segments that it’s not supposed to be exposed on. This is not a database problem per se, but a networking problem.”

For example, Sabo says a company might bring up a database in a test environment and then forget to close it down at the end of testing. Often that database might have default passwords, and sometimes it has real data. Developers do this sort of thing because they want to stress test the application and they use real rather than fake data because they think no one will ever see it.

Then there is the mapping issue. What applications are mapped to the database, and are they the correct ones? “Maybe for a test, a production database was connected up to a test database for a short while and then the connection was left by accident. Or a production database is mapped to an application that was retired, or that no one knows about. These things happen,” says Sabo. “So our first best practice is to provide visibility and an inventory into what databases you have and what they are mapped to.”

The next step is to continuously monitor what is going on between your application and the database. This is actually a recommendation from NIST. You will want to know if there is any rogue traffic going on there. This is where you look for SQL injections because you see the real SQL going across. There are tools that continuously monitor this traffic and detect if there is an unauthorized attempt at modifying data or getting data out.

And finally, the last best practice is to protect the database network with data loss prevention tools. “If you start to see credit card information coming out over the network and you know it shouldn’t be coming out that way, you know there is a problem,” says Sabo.

If your organization has some serious data to protect, and you know how common SQL injection attacks are, then it may benefit you to put these recommendations into practice.

---

Best Microsoft MCTS Certification, Microsoft MCITP Training at certkingdom.com