Hacker's Choice: Top Six Database Attacks

Next Page: Brute-force (or not) cracking of weak or default usernames/passwords

It used to be that most Oracle databases came with a default user -- “username: Scott” and “password: tiger” -- and Microsoft’s 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 don’t let you keep default and blank username/passwords. That doesn’t mean, however, that all organizations still don’t 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,” Forrester’s 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 aren’t hacker-safe. “You can always find weak and easily guessed passwords with customers,” Sentrigo’s 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. “That’s 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. “It’s a control issue. Sometimes a business doesn’t provide a good framework for who needs to get access to what... And normally, database administrators don’t have a business understanding of the data. That’s one of the problems,” Forrester’s Yuhanna says.

And sometimes an inside attacker (or an outsider who has taken over a victim’s 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 wasn’t authorized [on the database]... Some of these controls are not well-centralized,” Yuhanna says.

Sentrigo’s Markovich was recently able to break into a customer’s 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 don’t 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?” Forrester’s Yuhanna says. “This area is starting to evolve as well.”

Next Page: Exploiting unused and unnecessary database services and functionality

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 don’t 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,” you’re exposing the database and possibly letting the hacker in without authentication and authorization, Forrester’s 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 it’s the easiest way to get it rolling and out of the lab and into production,” AppSecInc’s 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 don’t deploy a feature, you won’t 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 can’t keep up with them, so they’re 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,” Forrester’s 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 can’t patch] because they can’t shut down their operations," he says.

Sentrigo’s 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 it’s tough to keep up with the patching cycle, organizations should keep patching. Oracle’s 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 they’re 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. It’s 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 doesn’t examine the content of the logon. “The problem is that the authentication and authorization has been moved to the application server,” says Forrester’s Yuhanna.

“Now instead of a user name, it’s a SQL command and it’s 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.

“That’s poor developer practice. You have to look at the content the user is providing. Whatever you execute, the database will execute. That’s the scary part,” he says. “SQL injection has been a very big problem.”

Sentrigo’s 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 wasn’t encrypted and it lands in the wrong hands, you’re 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 isn’t some ancient version of Informix or DB2 on HP-UX, an attacker could strike gold, notes AppSecInc’s Julian. “All they have to do is mount” the tape, and they’ve got the database, he says.

This type of attack is, of course, “incidental,” unless it’s 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 don’t always keep good tabs on their backups, either. “People take too many backups of data and lose track of them,” Forrester’s Yuhanna says. “Tapes are vulnerable because no one focuses on them... and they don’t 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.