It takes the average attacker less than 10 seconds to hack in and out of a database -- hardly enough time for the database administrator to even notice the intruder. So its no surprise that many database attacks go unnoticed by organizations until long after the data has been compromised.
And surprisingly, according to many experts, the database -- home of the enterprises crown jewels -- is still not secured properly in many enterprises. Malicious hackers are using shockingly simple attack methods to break into databases, such as exploiting weak passwords and lax configuration, and capitalizing on known vulnerabilities that go unpatched.
And dont even get us started on the epidemic of missing backup tapes: If the lost or stolen tapes are unencrypted, youre toast if a bad guy gets hold of them. No hack required.
One of the biggest problems is that many database attacks are not even known about, says Noel Yuhanna, principal analyst with The Forrester Group. The typical database may have 15,000 to 20,000 connections per second. Its not humanly possible to know what all of these [connections] are doing.
Hackers are well aware of enterprises' database patch dilemma -- in fact, theyre banking on a backlog. Gone are the days when companies could lock down a handful of databases in the data center: Most organizations today have hundreds, even thousands of databases to configure, secure, and monitor -- and remote users, customers, and business partners all need access to them.
The big thing that bothers me is when I go to a customers site, usually their [database] configuration is so weak that its easy to exploit. You usually dont need buffer overflow or SQL injection [attacks] because the initial setup of the database is totally insecure, says Slavik Markovich, CTO of Sentrigo, a database security vendor.
Database attacks dont have to be complicated with all of this low-lying fruit hanging around. Those are basic configuration problems, so a hacker doesnt have to do something really sophisticated because these easy things work, Markovich says.
So what are these hacks, and how can enterprises stop them? Heres a look at the top six database hacks attackers are using today. Many of them take advantage of painfully obvious weaknesses in how organizations set up their databases. Some are more useful to the malicious insider; others are used by bad guys trying to get to valuable corporate data. Either way, the only way to lock down the database is to get to know where the bad guys are getting in.
Hackers' top six database attacks:
- 1. Brute-force (or not) cracking of weak or default usernames/passwords
- 2. Privilege escalation
- 3. Exploiting unused and unnecessary database services and functionality
- 4. Targeting unpatched database vulnerabilities
- 5. SQL injection
- 6. Stolen backup (unencrypted) tapes
It used to be that most Oracle databases came with a default user -- username: Scott and password: tiger -- and Microsofts SQL Server came packaged with default passwords (read: publicly known) for systems administrator accounts.
Those default logons were convenient, for sure -- especially for malicious hackers who got an instant back door into the database by using them.
Oracle and other major database vendors get wise in the newest versions of their products, which dont let you keep default and blank username/passwords. That doesnt mean, however, that all organizations still dont leave that door open with older databases.
The problem is that enterprises have 15,000 databases out there, and trying to nail them all down is difficult, Forresters Yuhanna says. Sometimes they [secure] only the critical ones, and leave the others not as secure... Now, newer databases force you to change default passwords for systems administrator accounts as you install them. But the older releases can be the problem.
But even unique, non-default database passwords arent hacker-safe. You can always find weak and easily guessed passwords with customers, Sentrigos Markovich says. They are simple to find... with brute force [cracking] or even trying different combinations."
And password-cracking tools are plentiful and easy to obtain, via a Google search or sites like sectools.org, which links to popular tools such as Cain and Abel or John the Ripper. There are always no-nonsense, no-hack, Google dorks in the Google Hacking Database created by famed hacker Johnny Long, too -- where real passwords turned up in Google searches.
The best way to protect yourself from a password hack: Steer clear of default passwords, and institute tight password management and regular change-ups.
Next Page: Privilege escalation
There have been several insider attacks that came as a result of a malicious user possessing more system privileges than he or she should have had. And outside attackers sometimes grab higher-level privileges by compromising the operating system. Thats a common threat vector, says Ted Julian, vice president of marketing for Application Security Inc.
More often than not, privilege escalation has more to do with misconfiguration: A user is mistakenly granted more access and privileges on the database or related applications than he actually needs to do his job. Its a control issue. Sometimes a business doesnt provide a good framework for who needs to get access to what... And normally, database administrators dont have a business understanding of the data. Thats one of the problems, Forresters Yuhanna says.
And sometimes an inside attacker (or an outsider who has taken over a victims machine) can merely jump from one application to the database, even if he doesn't have database credentials. A nonprivileged user could try out connecting to the database... as long as he has access to one system, such as the CRM, he could [conceivably] get through with the same password, even if he wasnt authorized [on the database]... Some of these controls are not well-centralized, Yuhanna says.
Sentrigos Markovich was recently able to break into a customers database with a low-privilege user account. They asked me to break into their database. I found out a low-privilege user password, and logged in. Then I checked his privileges, and he had read-only access to the database, Markovich says. So a low privilege user has access to read any table inside the database, including credit card information, personal information. So I said [to the customer]: I dont have to break into the database.
The rule of thumb should be to give users only the access and rights they need on the database, nothing more, experts say.
Then there are those privileged users who have legitimate access, but may not have legit actions in mind. How are you going to control access? Forresters Yuhanna says. This area is starting to evolve as well.
You can bet one of the first things an outside attacker will look for -- after wimpy database passwords -- is whether his potential victim is running the Listener feature on its Oracle database. Listener seeks out and forwards network connections to the Oracle database, and thus can expose users and database links.
With a little Google hacking, an attacker can search and find exposed Listener services on databases. Many customers dont set passwords on Listener... so the hacker can search for strings and find out where live Listeners are on the Web, Markovich says. I did a search a while ago and found some interesting stuff exposed... such as government sites. This is a really big problem.
Other features, such as hooks between operating systems and the database, can leave the database exposed to an attack. Such a hook can become a communications link to the database. When you link libraries and write programs... that interface with the database, youre exposing the database and possibly letting the hacker in without authentication and authorization, Forresters Yuhanna says.
Often, database administrators merely opt for the kitchen sink rather than turning off unneeded features. They just throw it all on. The project is running late, management is pissed off, and its the easiest way to get it rolling and out of the lab and into production, AppSecIncs Julian says. Unnecessary services wind up on the infrastructure and open you up to vulnerabilities, he says.
The key is to keep your database features lean and mean, installing only what you must use. Nothing else. Any features can be used against you, so install only what you need, Markovich says. If you dont deploy a feature, you wont have to patch it later.
Next Page: Targeting unpatched database vulnerabilities
The good news is that Oracle and other database vendors do patch their vulnerabilities. The bad news is that organizations cant keep up with them, so theyre always at the mercy of a wily attacker looking to capitalize on that window of opportunity.
Database vendors are careful not to disclose many details about the vulnerabilities their patches fix for fear of tipping off attackers, but organizations still struggle with the massive manpower and time it takes to test and apply a database patch. Patching requires the painstaking task of testing all applications affected by the patch, for instance.
The biggest problem is that most companies are behind in [installing] their patches, Forresters Yuhanna says. One company told me they can only shut down their database once, for six hours [to patch] they have to take a risk [on what they cant patch] because they cant shut down their operations," he says.
Sentrigos Markovich says that there are at least 10 to 20 known vulnerabilities in most Oracle databases running today that a hacker can use to break in. These are not patched, he says. If a hacker can compare versions and find exactly where the vulnerabilities are, then he can go after the database.
And some hacker sites post exploit scripts for known database vulnerabilities, he says. Even though its tough to keep up with the patching cycle, organizations should keep patching. Oracles April 15 patch, for instance, contained 17 issues inside the database, he says. Those [and other] patches should not be taken lightly. Every [issue] there can compromise your database.
Next Page: SQL injection
SQL injection attacks are nothing new, but theyre all the rage lately on Websites, with the recent attack on hundreds of Websites that have hit some high-profile sites. (See Silent But Deadly Web Defacement.)
Although the infected Web page and the user who visits it are typically highlighted in these attacks, these are also a clever way for hackers to get into the database. Its a lot easier to execute a SQL injection attack on a Web application that front-ends a database than on the database itself, database security experts say. Direct SQL injection attacks on a database are rare.
SQL injection attacks occur where the fields available for user input let SQL statements through to query the database directly.
Outside of the client, Web applications typically are the weakest link. In some cases, if the attacker gets a screen on the application for username and password, all he has to do is provide a SQL statement or database command and that goes directly to the database, Yuhanna says, if the app doesnt examine the content of the logon. The problem is that the authentication and authorization has been moved to the application server, says Forresters Yuhanna.
Now instead of a user name, its a SQL command and its put into a packet and sent by the app server... to the database. The database reads the [rogue] SQL command, and it could shut down a database altogether, he says.
Thats poor developer practice. You have to look at the content the user is providing. Whatever you execute, the database will execute. Thats the scary part, he says. SQL injection has been a very big problem.
Sentrigos Markovich says SQL injection attacks can occur both from the Web app to the database, and from within the database itself. But there are some programming practices that help prevent SQL injection flaws in applications, such as using what are called bind variables, or parameters for queries.
In languages such as Java, that means using question marks as placeholders in the SQL statement and binding the received values to those placeholders, Markovich says. Another practice is to avoid displaying certain database error messages to avoid giving away potentially sensitive information to a would-be attacker, he says.
Next Page: Stolen backup (unencrypted) tapes
What is it with backup tapes falling off of trucks and disappearing from warehouses these days? If the database data on those types wasnt encrypted and it lands in the wrong hands, youre breached without a hacker ever touching your network.
But this type of attack is more likely to occur with an insider selling the media to an attacker. As long as the stolen or found unencrypted tape isnt some ancient version of Informix or DB2 on HP-UX, an attacker could strike gold, notes AppSecIncs Julian. All they have to do is mount the tape, and theyve got the database, he says.
This type of attack is, of course, incidental, unless its an insider-driven attack, Julian notes. There would happen to be a [readable] copy of the database... that falls off of a truck or gets lost." Thumb drives are another risk for the same reasons, he says.
Aside from the obvious precaution of encrypting data on a backup, organizations dont always keep good tabs on their backups, either. People take too many backups of data and lose track of them, Forresters Yuhanna says. Tapes are vulnerable because no one focuses on them... and they dont encrypt them most of the time.
Have a comment on this story? Please click "Discuss" below. If you'd like to contact Dark Reading's editors directly, send us a message.