Database Insecurity And The Trends Of 2013Team Shatter Exclusive

Posted January 30, 2013 by Josh Shaul in Attack Vectors, Data Breach, Database Security, Team Shatter Exclusive with 0 comments

What is in store for us in 2013? What new threats should organizations be aware of? Are you next to be hacked?

Let’s first take a quick look back at the events of 2012. In the past twelve months, the good news is that the hacktivists went away (mostly). However, we saw an increase of 45% over 2011 in the number of breaches disclosed, there were lots of new database vulnerabilities reported and patched, including one with a CVSS 10.0 from Oracle (highest possible risk.) Malware was a common attack method; we saw it installed via spear phishing in the South Carolina Department of Revenue breach. Meanwhile, database malware was spotted in the wild by Symantec researchers. Finally, executives began to realize that compliance does not equal security.  Hackers will always go where the vulnerabilities are.

I predict that little will change in 2013. Databases will continue to be the primary target for hackers, because they hold the most valuable information. Year over year, over 90% of stolen data comes from databases. Database patching is still unacceptably slow with an average of 6 -9 months to patch a production database. And so, we will see the same old vectors continue to yield success. SQL injections are still working, powerful new attacks are surprisingly easy to exploit, and the attackers toolkit is bigger than ever.

Here’s a list of my top database security risks in 2013:

  • SQL Injection
  • Password Attacks
  • Improper and Ineffective Access Controls
  • Database Java Exploits
  • Misconfigured Database Security Settings

SQL Injection vulnerabilities exist in all major database platforms. Sybase in particular disclosed a rash of extremely powerful SQL Injection vulnerabilities that are trivial to exploit. It takes a patch to fix these problems, which leaves most production systems vulnerable for 6-9 months.  Sometimes more. These traditional attacks will continue.

Despite the fact that we are given various criteria to create a password – must include an upper and lower case, must include a number, etc. – we are getting good at choosing easily-remembered (and easily guessed!) passwords that pass this criteria. Once the hacker correctly guesses an employee password, they are in the system. Database password cracking tools are freely available and default passwords are often found in production systems. Despite all of this, we have seen things like the Oracle11g Stealth Password Cracking Vulnerability this past year, which allows an attacker to brute force any user’s password without any failed login attempts.  This vulnerability was fixed in the October 2012 CPU, but it just goes to show how crafty these attacks are getting.

Improper and ineffective access controls are unfortunately a common issue. It’s almost impossible to determine what database privileges a user has without the help of 3rd party tools. Very few organizations can even define what it means to be a privileged user, and if you can’t define what privileged user means, you obviously can’t make a list of privileged users.

In recent years, major database vendors have added Java support to their RDBMS product line. The ability to run Java brings database functionality to a whole new level, but also changes the game for an attacker who can get the system to run whatever Java they choose. Each vendor (Oracle, Sybase, IBM) has patched critical vulnerabilities that allow an attacker to load and run arbitrary Java. In each case, PUBLIC (any database user) could assume complete control of the database server through a simple attack. Too many databases out there have unused and unpatched Java systems enabled and waiting to be attacked. It takes a patch to fix these problems, leaving systems exposed.

We will continue to see these exploit methods for the remainder of 2013. Although organizations may be starting to take security efforts a bit more seriously than they have in past years, many do not have a proper database security program in effect yet. The hackers are going after the path of least resistance to steal information – and it’s in the insecure database.

Leave a Reply

Name (required)

Mail (will not be published) (required)


Please note: JavaScript is required to post comments.

Powered by