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 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.

Oracle released the April 2010 CPU

Yesterday, Oracle posted their Critical Patch Update (CPU) as they do every quarter. This update contained fixes for 8 database management system vulnerabilities.

Some of the more interesting findings from the update include:

· Attacks that combine all 8 database vulnerabilities identified in this CPU pose a very high risk to the database.

· CVE-2010-0870 is a fix to a vulnerability that was reported by Esteban Martinez Fayo, senior security researcher from Application Security, Inc.’s Team SHATTER.

· CVE-2010-0860 requires an authenticated user with ‘CREATE USER’ privileges – these entitlements are typically only assigned to higher privileged users.  This is a high risk vulnerability as it allows for a complete takeover of not just the database, but the entire server, including the operating system (OS). Of course an exploit escalating privileges using advantage of some of the other vulnerabilities fixed in this CPU will thus allow very low privileged users to completely take over your server.

· CVE-2010-0866 and CVE-2010-0867 are fixing the Litchfield Zero Day Vulnerability that was unveiled at the Black Hat Conference this past February. Our team worked around the clock to ensure our products were up to date with this vulnerability and also provided non-customers with workarounds. The Litchfield Zero Day Vulnerability allowed an attacker the ability to escalate their privileges and become a system database administrator (sysdba) to take control of Oracle databases 10g, 10gR2, 11g, or 11gR2.

As always, make sure to

• Always stay up-to-date on the latest security patches

• Minimize the attack surface by only installing and enabling functionality that is required for the business task

• Remove all unused default components

• Always assign only least privileges required

• Assign privileges through roles, not directly to users

Litchfield DBMS_JVM_EXP_PERMS 0-day on Oracle

At last week’s BlackHat D.C., David Litchfield revealed 0-day vulnerabilities in Aurora, the Java implementation built into Oracle.

Vulnerabilities in the following packages:

• DBMS_JAVA
• DBMS_JAVA_TEST
• DBMS_JVM_EXP_PERMS
  

allow an attacker to escalate their privileges to sysdba and take complete control of the database. It was successfully demonstrated how a low privileged user can grant themselves sysdba privileges, access on every file on the Oracle host server and execute those files, including a shell. It was also shown how to load binary code into the Oracle process and execute it. Finally a way to bypass Oracle Label Security was demonstrated.

There is currently no fix available from Oracle, however Oracle’s access control features allow for a workaround. By default EXECUTE is granted to PUBLIC for the above mentioned packages.

In order to protect against these current threats, database administrators should revoke execution privileges on these packages from PUBLIC and any other user that does not require them. The AppDetective and DbProtect ‘Object privilege granted to PUBLIC’ Oracle Vulnerability Assessment checks can be used to help find and remediate these privileges.

Application Security has also made available for download a custom policy and check to specifically find these privileges and learn if your Oracle databases are vulnerable. With Application Security, Inc.’s User Rights Review (URR) platform, customers will also be able to determine which users can exploit the vulnerability as well as an explanation of how to fix the vulnerability.

Team SHATTER also suggests adhering to the following general security considerations to minimize the risk of new attacks like this:

• Always stay up-to-date on the latest security patches
• Minimize the attack surface by only installing and enabling functionality that is required for the business task
• Remove all unused default components, accounts and databases
• Assign only minimal privileges required
• Assign privileges through roles, not directly to users

Related links:
SHATTER Security Bulletin

Patch 'em up, Patch 'em up....

By Josh Shaul

Every couple of weeks I hear a complaint from a DBA that they have been flagged for a security violation for not running the latest database patch. It usually goes something like:

“I got written up for a high-risk vulnerability because I’m running one or two patches behind the database vendor. I think it’s unfair and more to the point just plain wrong. I checked out the readme files for the missing patches, and there is no listing of any security fix at all, or at least not one that applies to my system.” 

At first glance, this sounds like a pretty solid argument. Why should someone get written up for a serious security violation for missing a patch when it appears that the patch has no security implications? The problem is, sometimes a patch is more then it appears or claims to be. Database vendors, actually nearly all software vendors release patches for their software periodically. Generally there is some description of the patch, what it’s for, etc…. The part that most folks don’t realize is that software vendors make no promises about fully disclosing what changes go into each patch. Some companies choose to document all changes, however most choose to document only the changes that are directly related to issues reported by customers. Issues uncovered internally are generally patched without any notice. This includes both functional bugs and security vulnerabilities.

There was recently a good example of this with an Oracle July 2008 CPU. In that CPU at least one undocumented issue was fixed, a flaw with Database Vault that allows a DBA to bypass the vault protections and gain access to all the data in the system. If you’re not familiar with database vault, it’s a special kind of Oracle database designed to segregate database management from the data being managed. Basically it’s a tool to keep DBAs from looking at sensitive data in the database. The flaw that Oracle corrected made it trivial for anyone with DBA rights to gain access to any data in the database. 

This is important to know about. The vulnerability Oracle fixed is a fairly big one….but it only impacts data vault. In the grand scheme of things, for the database community at large this was a fairly minor issue. Maybe that’s why Oracle chose not to document it. Not enough deployments of database vault to make it worth their while? Embarrassing to fix a vulnerability in a security bolt-on for the database? Who knows. Thing is, if you’re running database vault to protect your organization’s crown jewels, I’m sure you would want to know about this issue. Otherwise you may choose to skip the patch….and that’s really the point of this post. 

Those complaints that I get about missing patches causing security violations always get the same response: “You can’t trust the vendor to fully disclose what a patch fixes, so you should assume the worst case and patch if you want to ensure your systems are protected.” That’s the bottom line. Missing patches, no matter what the readme docs may say, should always be viewed as a security violation. Not doing so leaves you open to get bit on the you know what……. 

So if Oracle didn’t disclose the vulnerability or the fix, how do we know about it? Well, there is the folly of the partial disclosure approach. Some smart security researcher  (Alex Kornburst) found the vulnerability on his own. He reported it to Oracle, and they responded by telling him that this was a known issue that was (silently) fixed in July 2008 CPU. Oracle is getting better about this kind of stuff, but they still have some room for improvement. I hope that as their security processes continue to grow, that they’ll become much more open about what security issues they are fixing with each patch.

It’s got to be a little embarrassing when one of these “secrets” gets out. Oracle has taken so many big steps to improve their perception about being very serious about security (no doubt Oracle is VERY serious about security)…but when this kind of thing happens, it reminds folks of the dark days when security issues were swept under the rug, and that’s not good for anybody…… 

Interested in learning more? Check out Alex’s blog post about this and another issue with database vault:

http://blog.red-database-security.com/2008/11/21/oracle-database-vault-privilege-escalation-exploit-published/ 

Happy New Year everyone!

 

 

 

Cinema Smackdown Winner Crowned at Oracle Open World

Last week, Application Security exhibited at Oracle Open World in San Francisco, CA. Like most database shows, database security continued to be a hot topic.

As part of the show, Application Security held the first annual Database Security Cinema Smackdown film contest. In the months leading up to Open World, amateur filmmakers submitted videos on the importance of database security.

Thousands of attendees stopped by the Application Security booth to share their thoughts on database security and to put in their votes for the top video. The attendees crowned Database Security is Important as their favorite.

Other Great Entries

If you have a couple of minutes, check out some other great videos including the four finalists.

Black Hat 2008

Last week I took part in  the yearly security pilgrimage called Black Hat in Las Vegas. This years briefings were at Cesars Palace, with 8 parallel tracks ranging from App Sec and 0-Day to Reverse Engineering and Over The Air.

Day 1

I started the day out with a great refresher on everything Application Security by Jared DeMott. Anybody interested in a great general purpose intro on all the different App Sec jargon, and techniques should take a look at this once it shows up in the Black Hat archives.

Next I wanted to see Dan Kaminsky’s ‘DNS is broken’ presentation. Unfortunately clouds of people were already outside the doors and I could not get in the room. But then this got covered by the press and on various blogs in enough detail by now. So in the end, it won the ‘coveted’ most overhyped talk award at the end of day one.

After lunch I sat in the talk by Petko Petkov aka PDP. He had a great presentation mostly talking about x-site/application authentication issues. The core of his message was that we can’t take systems out of context for security testing. An application that is quite secure standalone or in a particular environment, can be used quite maliciously when integrated with another app, or ported to a new platform. For example Apple’s Quicktime™ which runs quite secure in the Mac™ environment has had a flew of issues in the recent past on Windows™.

Bruce Potter of SchmooCon fame, had probably the funniest of all presentation and should really consider a second career path as a comedian. While he did quite extensively promote his newest venture, he had some really good thoughts on presenting vast amounts of audit data. Presentation of data can make or break a security product and I’m really exited about our continued reporting enhancements in DbProtect.

Day 2

I started the day out with Arian Evans presentation about double/triple-encoding as well as transcoding attacks. This February’s highly successful SQL Worm and its more recent derivatives are using this class of attacks. Basically an attacker can circumvent all web app firewalls by properly encoding SQL code, and hide its malicious payload until the database interprets the mumbo jumbo passed through from the web sites POST command. Our security team jumped on this earlier this year, and we were able to create DbProtect activity monitoring filters and rules for these attacks.

I see this as proof, that a comprehensive security posture requires more then just perimeter protection, but that the bad guys will always find their way around these protections, and make their way to where the data is, which is where DAM really comes to shine.

Incidentally, my next stop were some short ‘turbo talks’ of which one was by Justin Clarke, who looked at the same class of attacks from a slightly different angle, and who had a really nice working attack demo.

Later this day Microsoft™ introduced 3 new security initiatives. As a security vendor I was really exited about MAPP, the Microsoft Active Protections Program. In a nutshell, Microsoft will give pre-release announcements to select 3rd party vendors for upcoming security patches, including some pretty detailed vulnerability information. This will give active protection vendors like AppSec a leg up on the hackers, allowing for release of application protection content at the same time new patches are released. Allowing IT departments to thoroughly test these new patches, while still being protected from new attacks exploiting the new vulnerabilities.

I really hope for this to be successful, and for IBM™, Oracle™, etc. to come up with similar initiatives.

Finally I was all set to go to David Litchfields talk. I had never had the chance to see him before and was really looking forward to it. Turns out he lost his passport, and by the time he got a replacement, the airfare would have been not worth it for him, to go for one day.

I can’t help it, but to be disappointed. While I don’t know how much his airfare would have been, I wish he would have thought about his audience, too.

Blog Post - We know about SQL Injection, Buffer Overflows, and even Privilege Escalation...but self-resetting passwords?

By Josh Shaul

That’s right, self-resetting passwords. In the Oracle April 2008 CPU a vulnerability (DB13) was corrected which revolved around the password for the OUTLN account resetting itself when a user creates a materialized view. This is a most unusual vulnerability that has really thrown me for a loop. What was the developer thinking when he or she wrote the offending code?

That code it turns out is inside a package called DBMS_STATS_INTERNAL, where there is a function that is called as part of Oracle’s internal processing that occurs when a materialized view is created. This function executes the SQL statement:

          GRANT DBA TO OUTLN INDENTIFIED BY OUTLN

This line of SQL code resets the password of the OUTLN account to the well-known and easily guessed default value of OUTLN and to make matters worse, it also grants OUTLN membership in the DBA role. This is a dangerous combination; a well known account with a default password in place, and full DBA rights in the database.

OUTLN is an account used to support Oracle’s Query Plan Stability or Stored Outlines feature. Stored Outlines allow a DBA to store optimized plans for executing specific SQL. This is an important performance enhancing feature of Oracle. It lets a DBA optimize queries that live in code they cannot touch (such as in 3rd party applications), it also speeds up commonly run queries by storing a fixed execution plan which can be quickly retrieved and executed, rather then having to periodically recalculate an optimized plan on the fly in reaction to various database changes.

Since stored outlines persist through changes such as modifying table data, modifying table structure, or even updating the optimizer, queries will continue to follow the stored execution plan eliminating any performance penalties associated with the changes. OUTLN and its associated schema is important to the operation of the database and should not be removed.

By default, the OUTLN account is locked. This provides adequate security as long it stays locked. Some security experts (including myself) have advocated for changing the passwords on default accounts to so-called impossible passwords. The idea here is to totally eliminate the potential for an account to be used to access the database, regardless of whether the account is locked or not. This is a great strategy, assuming the database doesn’t go resetting passwords to default values.

With this vulnerability in place, those who have set an impossible password and unlocked the OUTLN account are at risk, and should immediately move to ensure the account is locked (there is no need to change the password, keeping an impossible password on a locked account is just fine). Until you can apply the patch to correct this vulnerability, be sure to regularly check the OUTLN account and make sure that it remains locked and does not reset to the default password. A database vulnerability scanner makes this an easy job to repeat on a very frequent basis. 

This vulnerability was found and reported by Alex Kornbrust of red-database-security.com.

Oracle's Remote OS Authentication

Submitted by Josh Shaul

A client recently asked me about Oracle’s Remote OS Authentication feature. What does it mean? How does it work? What’s the impact on the security of my database? There are a few interrelated components at play here, and the answers are neither simple nor well known. 

Let’s start with the basics. Oracle supports a number of authentication mechanisms, the most commonly used being database authentication and operating system authentication. Database authentication accepts a username and password, then checks these against credentials stored in the database. Oracle ships with a number of default database accounts, all of which are setup for database authentication. It’s simple to setup accounts for database authentication, when you create the user give them a password:

CREATE USER SCOTT IDENTIFIED BY TIGER

Connecting to Oracle (via sqlplus) with database authentication looks like this:

sqlplus scott/tiger

Note that both a username (scott) and password (tiger) are provided. Also note that versions earlier then 11g, Oracle passwords are not case sensitive.

Operating System Authentication relies on the OS to validate a users logon credentials. Oracle trusts the operating system to do a good job with authentication, and assuming the OS user is a valid database user, they are allowed to login to the database without supplying a password. To create an OS authenticated user, tell Oracle that the user will be identified externally:

CREATE USER OSUSER IDENTIFIED EXTERNALLY

Connecting to Oracle with operating system authentication looks like this:

sqlplus /

Note that no username or password are provided. Oracle takes the username currently logged into the OS, looks up a database user of the same name, and then makes the connection.

There are two types of Operating System Authentication supported, Local OS Authentication and Remote OS Authentication. Local OS authentication is enabled by default, and uses the local operating system (the database server’s OS) to authenticate users. Remote OS authentication is just the opposite. It is disabled by default, but when switched on, it allows a remote OS (which is any client that can make a network connection to the database) to authenticate users. Consider that for a moment. Allowing any client that can make a network connection to the database authenticate users on behalf of the database. If I can get administrative access to any machine on the network, or if I can bring my own machine in, I can create OS users on my local box with the same names as database users and easily make connections to the database. It’s almost like disabling any security for any accounts that can login via OS authentication.

This brings us to another question. Which users can login via OS authentication? This depends on two factors. First is an initialization parameter call OS_AUTHENT_PREFIX (OS authentication prefix). When users connect via OS authentication, Oracle takes the OS_AUTHENT_PREFIX value and prepends it to the OS username to create the database username. By default, the OS authentication prefix parameter is set to OPS$. In this case if I want to allow an OS user named OSUSER to connect to the database, I would have to create a database user as follows:

CREATE USER OPS$OSUSER IDENTIFIED EXTERNALLY

OS_AUTHENT_PREFIX seems simple enough, but it has a dark side. When set to the default value of OPS$, it removes the Oracle security restriction that requires users to be IDENTIFIED EXTERNALLY in order to logon via OS authentication.  This removes an important control and presents some security risk. The reason for this is backwards compatibility, with Oracle6!

What this means to our question about who can login via the OS is that if the OS_AUTHENT_PREFIX = OPS$, then any username that beings with the string OPS$ can logon via the OS. If OS_AUTHENT_PREFIX is set to any other value, only users that are IDENTIFIED EXTERNALLY  (Password column in DBA_USERS/SYS.USER$ will read EXTERNAL) and whose username begins with the OS_AUTHENT_PREFIX can login via the OS.

Ok, so now we know who can authenticate via the OS. We can also check if remote OS authentication has been turned on by examining the init.ora file (REMOTE_OS_AUTHENT parameter). While we’re there we can grab the value for OS_AUTHENT_PREFIX as well. With this information you can figure out if your database has been left open to trust remote (client) operating systems to authenticate their own users, and if so, which users in the database are susceptible to attack via a remote OS authenticated connection.

From a best practices perspective, I recommend that you disable Remote OS authentication on all your Oracle systems. It represents a significant security risk that is almost always unnecessary. I also recommend changing the value of OS_AUTHENT_PREFIX to something other then the default value of OPS$, as this opens yet another security hole. Finally, I recommend checking these settings periodically, at least quarterly on your production systems. Just because the settings look good today doesn’t mean that someone isn’t going to change them tomorrow!