Database Security 3.0

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!