Database Security 3.0

Black Hat 2010

I’m back from Las Vegas caught up with my e-mail, well sort of. And finally I got some time to sort out my thoughts about Black Hat 2010. I had skipped 2009 and was excited to get back to Caesars Palace, meet colleagues and friends and listen to some great presentations.

Let’s just say it’s gotten big– almost overwhelming.  

There are now 22 tracks, compared to 14 in 2008. Also the vendor section has really grown. What used to be a couple of booths at the side of the hallway is now a dedicated hall with almost every security vendor showing a presence.

As usual, right after registration on Tuesday night, I sat down and started marking up the talks I was interested in. With so many tracks there was no shortage of interesting topics at the same time slot. Since there were no database specific talks on the first day, I had a great opportunity to expand my horizon and check out some areas that I’m only somewhat familiar with. The short:

· Security and forensics in the cloud and corporate virtual environments is an up and coming field with some interesting and new challenges. Do you know where your data is? How many copies of it exist in the cloud on different continents? Which laws apply regarding privacy, security and forensics in different countries? What are the challenges involved with using public clouds? 

· SCADA, especially Smart Grid stuff is just plain scary at this point. There’s a race to the market with new inexperienced startups that don’t have money for security and big corporations that are equally unaware of security best practices. With thousands of vulnerabilities in critical infrastructure components -- soon they will also be in a smart meter at your home. This makes hacking the grid seem like a close reality. I guess it’s time to stock up on candles.

· Even hackers still think there is free money to be had in Vegas. Why else would Barnaby Jacks presentation about hacking into ATM’s have filled the room to the gills? This was probably one of the most entertaining of all the talks I attended. Watching an ATM’s screen turn into a slot machine and spit out funny money was great!  In reality, he was really just hacking WinCE, so it’s not like he was breaking into Fort Knox. Of course he did not reveal the PoC code of his attacks, no blue print to free money for this audience.

· Dan Kaminsky is still on the DNS crusade. His talk was a huge sell for replacing existing DNS with DNSSEC. He is also getting really hip calling all his latest projects PhreeBird, PhreeShell, PhreeLoad and finally PhreeGP. Phreaky!

· System privileges through token kidnapping. Windows is getting better with security, but the really good hackers can still find more stuff. Cesar Cerrudo had probably the most hard core technical talk that I went to. Good stuff.

· Oracle DBMS. Oracle is releasing plenty of patches every quarter and it’s still a favorite amongst security researchers. Two great talks were “Hacking and Protecting Oracle Database Vault” by Esteban Martinez Fayo and “Hacking Oracle from Web Apps” by Sumit Siddharth.

· Browsers are still bad. Finally one of my favorite presenters, Jeremiah Grossman, presented on “Breaking Browsers: Hacking Auto-Complete” with vendor patches coming out just before his talk. Now that’s the kind of Black Hat action I like.

That’s it for today. Keep coming back from more posts on database security and vulnerability issues that I find interesting. 

Ask TeamSHATTER – checking ADMIN_RESTRICTIONS is enabled

Application Security, Inc.’s Team SHATTER (Security Heuristics of Application Testing Technology for Enterprise Research) has starting taking database security and vulnerability questions. Our first question was submitted by @jedimercer asking:

How can I verify ADMIN_RESTRICTIONS is enabled on an Oracle Database when I can access the TNS listener but I do not have database credentials?

In order to check the ADMIN_RESTRICTIONS flag, it usually requires proper credentials to the Oracle database. However, there is an unofficial way to work around this if you have access to the listener. Trying to set the LOG_STATUS will return a TNS-12508 error if the ADMIN_RESTRICTIONS flag is set.

See the following example from the lsnrctl prompt:

LSNRCTL> SHOW LOG_STATUS

Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=EXTPROC)))

LISTENER parameter "log_status" set to ON

The command completed successfully

LSNRCTL> SET LOG_STATUS ON

Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=IPC)(KEY=EXTPROC)))

TNS-12508: TNS:listener could not resolve the COMMAND given

First, get the current status of the LOG_STATUS flag and then try to set it to that same status. You’re not trying to change any settings here – you just want to know if you can.

In the case that the SET LOG_STATUS command succeeds, the ADMIN_RESTRICTIONS flag is not set.

Do you have a question for Team SHATTER? Leave us a question in the comments space below or @TeamSHATTER on Twitter.

Team SHATTER Database Vulnerability 10 of 10 – Unencrypted Sensitive Data - At Rest And In Motion

Application Security, Inc.’s Team SHATTER (Security Heuristics of Application Testing Technology for Enterprise Research) has researched the Top 10 Database Vulnerabilities in order to provide you with the most up-to-date vulnerabilities, risk and remediation information.

Today’s post wraps up the Top 10 List with #10, Unencrypted Sensitive Data - At Rest and in Motion.

Encryption is an important part of housing sensitive data. Network traffic should also be encrypted to ensure that the passwords used to access sensitive, critical data cannot be seen by traffic. We’ve talked about how important it is to create strong passwords in our first post of the series, if they are visible to network traffic, it’s as bad as keeping your admin passwords set up or leaving a list of all your passwords on a post-it on your desk.

Any information that goes over the network or stored in the database should be encrypted and kept from prying eyes. Some network configurations and database management systems might allow for critical information to be sent in clear text. To ensure this doesn’t occur, make sure you have the latest version of software and turn off text indexing.

The Team SHATTER Vulnerability of the Day series on Twitter provides you with what to check for and how to mitigate these common risks. Stay informed. Follow @TeamSHATTER on Twitter.

Team SHATTER Database Vulnerability 9 of 10 – Unpatched Databases

Application Security, Inc.’s Team SHATTER (Security Heuristics of Application Testing Technology for Enterprise Research) has researched the Top 10 Database Vulnerabilities in order to provide you with the most up-to-date vulnerabilities, risk and remediation information.

Organizations house sensitive data – typically in databases. In response to the ever-changing vulnerabilities that are being exploited by attackers, database vendors release patches to ensure sensitive information in databases is protected from threats.

The good news.  Most vendors provide patch updates on a fairly regular basis. For instance, Oracle provides a critical patch update (CPU) every quarter. The most recent Oracle CPU was just released last Tuesday that provided patches to 13 database specific vulnerabilities. Team SHATTER was credited in the release for identifying 3 vulnerabilities. Once a vulnerability is publicly disclosed, whether a vendor has released a patch or not, Team SHATTER updates its vulnerability knowledgebase with workaround details to ensure databases are as secure as possible.

Now for the bad news. Once these patches are released they should be patched – at least the most critical vulnerabilities. If left unpatched, hackers can reverse engineer the patch, or can often find information online on how-to exploit the unpatched vulnerabilities, leaving a DBMS even more vulnerable that before the patch was released.

In our last post we discussed the SQL Slammer worm – this is a great example of what can happen when organizations don’t patch database vulnerabilities. 

Many organizations don’t implement patches right away – some even wait a year or more. The most common excuses are the downtime involved with implementing patches and the time involved with testing these patches to make sure they don’t affect the production software. Whatever the excuse may be, organizations should use database activity monitoring to manage the gap between patches on its databases containing critical information PII data.

The Team SHATTER Vulnerability of the Day series on Twitter provides you with what to check for and how to mitigate these common risks. Stay informed. Follow @TeamSHATTER on Twitter.

Team SHATTER Database Vulnerability 8 of 10 – Denial of Service

Application Security, Inc.’s Team SHATTER (Security Heuristics of Application Testing Technology for Enterprise Research) has researched the Top 10 Database Vulnerabilities in order to provide you with the most up-to-date vulnerabilities, risk and remediation information.

Today’s topic is Denial of Service.

Think of a washing machine. The more clothes you put in it, the more work it needs to do. If you overfill it with clothes, it gets overwhelmed and stops working. The same thing happens with a Denial of Service attack. It creates so much traffic on a site, a server or even sections of the internet that it cannot function and shuts down.

The most infamous DoS involving database servers was in 2003 when a computer worm called the SQL Slammer compromised more than 75,000 servers and slowed internet traffic to a halt.

The problem – unpatched Microsoft SQL Server databases.

The SQL Slammer vulnerability was fixed by Microsoft fairly quickly – six months before the attack surfaced. Unfortunately, many DBAs didn’t patch their databases timely and because of it, the Slammer took down the internet.

To mitigate risk and ensure critical databases stay up and running, be sure to patch all databases with the latest vendor patches once they are available. 

The Team SHATTER Vulnerability of the Day series on Twitter provides you with what to check for and how to mitigate these common risks. Stay informed. Follow @TeamSHATTER on Twitter.

Team SHATTER Database Vulnerability 7 of 10 – Privilege Escalation

Application Security, Inc.’s Team SHATTER (Security Heuristics of Application Testing Technology for Enterprise Research) has researched the Top 10 Database Vulnerabilities in order to provide you with the most up-to-date vulnerabilities, risk and remediation information.

Today’s topic is Privilege Escalation.

In any well configured Database Management System (DBMS), accounts are restricted to only perform the actions and access the data that they require to perform their job functions. For anybody with malicious intent, this is like being at a candy store, but you’re stuck in the room that only has oatmeal cookies. There could be a whole database with millions of credit card numbers, but you only have access to the organizations marketing folder.

Of course, too often, the locks to the candy store are easy to pick.

A privilege escalation attack is when the attacker is using a known vulnerability in a DBMS that allows a user account with restricted privileges to execute instructions or query data that that typically requires higher privileges. Thus unlocking the locks in the candy store. 

There are different common vulnerabilities that allow for privilege escalation. Sometimes misusing a function that runs under a sysdba, sa or similar security context. In other cases it is done by exploiting vulnerabilities that allow a low-privileged account to grant itself more rights.

To protect against these types of attacks, it is important to always keep your DBMS updated with the latest security patches available from the vendor, as well as continuously monitor for known attack signatures.

The Team SHATTER Vulnerability of the Day series on Twitter provides you with what to check for and how to mitigate these common risks. Stay informed. Follow @TeamSHATTER on Twitter.

Team SHATTER Database Vulnerability 4 of 10 – Minimize your attack surface

Application Security, Inc.’s Team SHATTER (Security Heuristics of Application Testing Technology for Enterprise Research) has researched the Top 10 Database Vulnerabilities in order to provide you with the most up-to-date vulnerabilities, risk and remediation information.

Database Management Systems (DBMS) have extended far beyond the simple data storage systems that they were in the early 1970s and are now impressive software packages  in their own right.  They now offer many features to analyze and report on data, run Java and other extensible languages, and even have various levels of OS access built in.

These features provide database application developers with a lot more power when working with a DBMS.   The flipside of the coin is, the more power you give a developer, the more attack vectors you potentially expose to the bad guys.

Many of these features are optional and are not required by applications accessing a Database Management System. DBMS vendors like to include all the bells and whistles in order to up-sell opportunities.

In this week’s edition of our Database Vulnerability of the Day series, we will highlight various optional components and features that should be removed or disabled – unless there is a valid business reason to make them available.

In our Team SHATTER Vulnerability of the Day series on Twitter, we will provide you with what and how to check for to mitigate these risks. To stay informed on the Top 10 Database Vulnerabilities follow @TeamSHATTER on Twitter.

Team SHATTER Database Vulnerability 3 of 10 – Extensive User/Group Privileges

Application Security, Inc.’s Team SHATTER (Security Heuristics of Application Testing Technology for Enterprise Research) has researched the Top 10 Database Vulnerabilities in order to provide you with the most up-to-date vulnerabilities, risk and remediation information.

Today’s topic is about extensive privileges assigned directly to users or indirectly through user groups.

There are two very important concepts that apply to information systems security controls: separation of duties and the principle of least privileges.

Separation of duties manages conflicts of interest and implements an appropriate level of checks and balances on an individual’s activities to ensure they do not have toxic privilege combinations.

The principle of least privileges requires that users have the least amount of privileges required to perform their specific tasks – only they the data they need and nothing more.

The process of collecting a comprehensive list of all rights that a user has can become a daunting task. Privileges aren’t typically just assigned directly to the users they also inherit privileges from groups or roles they belong to.

In this week’s edition of our Database Vulnerability of the Week series, we will highlight several important rights, privileges and common groups to look out for when reviewing user and group rights, as well as group memberships.

In our Team SHATTER Vulnerability of the Day series on Twitter, we will provide you with what and how to check for to mitigate these risks. To stay informed on the Top 10 Database Vulnerabilities follow @TeamSHATTER on Twitter.

Team SHATTER Database Vulnerability 2 of 10 – SQL Injection in the Database Management System

Application Security, Inc.’s Team SHATTER (Security Heuristics of Application Testing Technology for Enterprise Research) has researched the Top 10 Database Vulnerabilities in order to provide you with the most up-to-date vulnerabilities, risk and remediation information.

Today’s topic is SQL Injection in the Database Management System.

SQL Injection in the DBMS through Web apps because of a failure to sanitize user inputs is a well known attack vector.

Similar to the Web-based variant, SQL Injection in the DBMS exploits passing SQL commands as a parameter of a function or stored procedure. This will then execute the malicious SQL commands in the context of the component that provides the called function. Often this is done using components with system or admin privileges resulting in privilege escalation.

For example: A component that provides backup functionality, usually runs at a higher privilege, calling a SQL Injection vulnerable function in that specific component  could allow a regular user to escalate privileges and become a DBA.

All the vulnerabilities mentioned this week have been fixed by the database vendors and patches are currently available.

In our Team SHATTER Vulnerability of the Day series on Twitter, we will provide you with what and how to check for to mitigate these risks. To stay informed on the Top 10 Database Vulnerabilities follow @TeamSHATTER on Twitter.

Team SHATTER Database Vulnerability 1 of 10 - Default, Blank & Weak Username/Passwords

Application Security, Inc.’s Team SHATTER (Security Heuristics of Application Testing Technology for Enterprise Research) has researched the Top 10 Database Vulnerabilities in order to you with the most up-to-date vulnerabilities, risk and remediation information.

Today’s topic is Default, Blank & Weak Username/Passwords.

It has been a long standing practice in the software industry to create default accounts during the installation of software packages. Some are required to complete the actions required during installation.  Others are present to provide users with a convenient means to start testing the software out of the box. Many are part of demo packages and others get created during the installation of 3^rd party software. For example, a CRM package might create several accounts in the backend database, for install, admin and regular users.

The database management system or DBMS industry has not been excluded from this practice. For a long period of time, Oracle created the username/password of ‘SCOTT’/’TIGER’. SQLServer had ‘sa’ with a blank password.    DB2 came with ‘db2admin’/’db2admin’ as a default.  The list goes on. Other default accounts are installed by 3rd party products.  For example, SAP creates a slew of default database users at the time of installation.

Attackers are constantly looking for an easy way to steal sensitive data.  By undertaking the simple task of creating customized username/password combinations and ensuring DBMS do not have default, blank, and weak username/passwords you can easily mitigate internal and external threats to your sensitive data.

Recently, things have improved. Most DBMS’s now ask for custom usernames and/or passwords in the installer screens.  Nonetheless, the risk has not been eliminated.  At present, Googling ‘Oracle default users’ produces 4.5 million pages, with more than 1,000 default username/password combinations.

In our Team SHATTER Vulnerability of the Day series on Twitter, we will provide you with what and how to check for to mitigate these risks. To stay informed on the Top 10 Database Vulnerabilities follow @TeamSHATTER on Twitter.