Databases at war

A small UK startup claims to have a simple AI-based defence with which to counter the dreaded SQL injection attack. So why does it take a startup to point out the obvious?


Databases shouldn’t by rights have security holes in them at all, but years after they were first discovered to be a growing problem, they are still very much with us.

These holes open up in a number of ways, principally related to gaining privileges to execute or spoof (inject) scripts in the dominant query form SQL, or attempting to compromise or damage the operating system or other applications running on, or in conjunction with, the database.

If the security holes are out there, the world has had to rely on third-parties selling defence products to point this out - again and again.

This month’s Black Hat conference in Las Vegas was give a jolt by database witchfinder general David Litchfield of Next Generation Software. With the aid of researchers at his UK-based company, Litchfield has made it his business to hunt for issues before publicly embarrassing database companies on their myriad security failings.

Unusually, Litchfield has turned out to be a figure who refuses to back down, following up a concerted attack on the record of Oracle in remediating a long list of bugs two years ago with several more swipes at the company, and, more recently, harrying IBM about its Informix database family.

There are, as importantly, patchy but compelling statistics on the willingness of criminals to target all these vulnerabilities. According to a recent report from managed services company Secureworks, its customer databases are being hit with 100-200 SQL attacks per day in early 2006.

“Although we certainly see a higher volume with other types of attacks, what makes the SQL Injection exploits so worrisome is that they are often indicative of a targeted attack,” the company’s CTO John Ramsey was quoted as saying.

There is no easy-pie defence against such attacks, but a UK company, Secerno, launched in April this year at the InfoSecurity Europe show, claims it has a layer of useful defence against the popular SQL injection attack, in particular.

According to the company’s CTO Steve Moyle, the core of the problem is that companies don’t know they have a problem at all. The assumption is often that conventional security – which might or might not include a layer of application security – is adequate.

“Databases are hidden away and there is a sense that it is in the middle of the building and it is safe,” says Moyle. “The size of the problem hasn’t been grasped. It is difficult to see the level of exposure.”

He characterises this as being symptomatic of the “almost anything the application asks for, the database returns” outlook. Companies fail to control “feature creep” and “permission creep” both of which increase the level of security exposure.

“As more features are added, you need to be aware of what vulnerabilities are being opened up,” he says.

Secerno’s approach was to create an application, Secerno.SQL, that could analyse a database in terms of the SQL commands being sent to it, modelling this into a pattern of use. There is, therefore, no answer as to what a database should allow because each database is different. Put the system into protection mode, and it claims to be able to stop SQL injection attacks by allowing only those properly-formed queries that fit the pattern of pre-defined SQL.

Is this limiting? According to Moyle, databases invariably use only a small subject of valid commands from a seemingly infinite number of pssibilites, which makes the process of analysing and blocking unusual requests easier. Database administrators are given real-time information on such requests, and can make a decision as to whether they are valid.

One of the advantages of the system is that it does not distinguish between internal and external attacks. There is, after all, no inherent reason why attacks can’t come from inside the business that is being protected, although the assumption is often that this is unlikely.

Whether large corporates rush to add yet another security application to already selling rosters of such software, remains to be seen. Where Secerno might flourish, however, is in the one that large companies are not longer allowed much latitude, namely compliance.

“Compliance comes down to demonstrating that full understanding and control is being achieved in systems. Are the applications that were developed to some specification and tested in a pre-live environment, actually being used in the same manner as intended? Is this still true after numerous years of upgrades and patches?, “ asks Moyle.

“The only way to demonstrate this in a database environment is to understand precisely how your systems are interacting with the live databases.”

The company has published a white paper for anyone interested in the fine detail of protecting databases.

Secerno is small, very new, and despite the originality of its application protection will need word of mouth to have any chance of making a market impression. But it is on the company’s side that database protection is, incredibly, still in its infancy. Traditional approaches tend to involve encrypting traffic between databases and requesting clients, or analysing the databases and applications for known vulnerabilities, neither of which stop malformed SQL from running amok.

Moyle makes a number of recommendations, which can be summarised as a sort of database threat analysis.

Vendor vulnerabilities For example, buffer-overflow.

Solution: Patching the DBMS is necessary here, but this presumes that a patch exists (i.e. vulnerability is discovered AND the vendor produces a fix), and you have the ability to take your mission critical database offline long enough to apply the updates.

External attack The most common form of external attack is by subverting applications that connect to databases. Typically, this is done using targeted SQL Injection, exposing weaknesses in applications, and making them do something to your database that you would not normally observe.

Solution: Protecting against SQL Injection is difficult to achieve as every application has been developed to access the DBMS in its own way.

Knowing that there are no vulnerabilities is an impossible task. One approach is detailed code review of all applications. This is time consuming and may not provide sufficient guarantees.

Internal MisuseThis is the class of problem where authorised people are using the database in ways that are not normal.

Solution: a detailed understanding what your users should be doing is required. This should then be enforced to ensure conformance to what is normal.

Permission CreepOver time, many users and systems have extra access granted to them. In many situations these permissions are not reviewed in an effective manner.

Solution: Implement a least privilege access scheme by comparing the levels of access actually used to the levels of access that have been granted.

Application Feature CreepApplications developers love adding features. Unfortunately, each new feature expands the vulnerability surface of your DBMS.

Solution: Remove access to the database from features that are no longer necessary.
This is best achieved by understanding precisely which features access what information in the database.

Mis-configurationDefault installations of databases can result in a far too open DBMS. Many DBMS provide a large number of default usernames and passwords (which are easy to find on the Internet).

Solution: Audit the configuration and usage of databases by intelligently logging interactions with the database. Strive for least privilege access always.

"Recommended For You"

Stopping your database becoming a crime scene Kaspersky denies data lost during web hack