Musings on Database Security

Dennis wrote an interesting blog entry about an experiment he conducted.

He found that out of roughly every 69,000 randomly scanned IP addresses, there is one open Oracle TNS Listener. That’s interesting because we all know that there are numerous attacks on (even fully patched) listeners that do not require any authentication.

Looking at the listener versions, you can see that many of the versions are not even getting patches from Oracle any more. This is like leaving your door wide open and putting up a big sign inviting hackers to come in, especially in light of many working exploits out there.

I didn’t try it, but I’d bet that many of these listeners do not even require a password. Come on people, at least keep your database behind a firewall!

Ah, time flies when you’re having fun. It seams that only yesterday we worked on the October CPU and now Oracle released the January CPU.

This time, Oracle acknowledged 24 security fixes, 9 of them in the database layer. This number is a bit lower than the average but as in the previous CPU, you have a vulnerability that can be exploited remotely without authentication to take control of the machine (on Windows) or the Oracle account (on *nix).

Analyzing the CPU provides an interesting story. As always, Oracle talks about x vulnerabilities but actually patches y (which is much bigger than x). In this CPU, we’ve already analyzed more than 15 different vulnerabilities and we’re still counting!

Based on the severity of some of the vulnerabilities, if you have one of the supported versions you know you need to patch!
It’s also important to understand that if you have any 9i, 10gR1, 10gR2 or 11gR1 you’re vulnerable. Oracle just provides CPUs to the latest patch-sets.

I’m happy to see three Sentrigo researchers were credited in this CPU (including myself!). Go Red Team!

Of course, Sentrigo customers are already protected against many of the vulnerabilities using our own vPatches and we will release updated vPatches to cover the others.

In this case, my advice to wait a week to make sure that there are no issues with the patch and then patch as soon as possible since the vulnerabilities are so severe. Patch as soon as possible – but only after ensuring that your applications are not breaking.

If you can’t patch quickly or unable to patch at all due to valid reasons , try virtual patching as a stop-gap solution.

I’ve talked about displaying errors from the database on the user screen a while ago. In my opinion, this is definitely a big no-no and a security problem just waiting to happen.

As some of you know, I have an iPhone (and I like it a lot, but that’s another story). I’ve installed a nice little game called Tap Tap Revenge from Tapulous, a fairly known company and game in the iPhone scene. Immediately after installation, it required me to register or login.

Here is the error I got  trying to click on a email link trying to reclaim my username (I changed the error a bit):

Warning: mysql_connect() [function.mysql-connect]: Too many connections in /var/www/html/tapservices/v1/lib/tapsql.php on line 49

Warning: mysql_select_db(): supplied argument is not a valid MySQL-Link resource in /var/www/html/tapservices/v1/lib/tapsql.php on line 50

Warning: mysql_query(): supplied argument is not a valid MySQL-Link resource in /var/www/html/tapservices/v1/lib/tapsql.php on line 94
INSERT INTO tapulous.devices (user_id, device_id, time) VALUES (‘xxxx’, ‘yyyy’, NOW()) ON DUPLICATE KEY UPDATE user_id=’xxxx’, time=NOW()
Too many connections

Hmmm…

Let’s count how many details we can get from the error message:

• They are using PHP
• They are using MySQL
• They probably use Apache on Linux or some other *nix variant
• We know the directory structure (and also that it’s v1)
• They have the SQL code separated in a file called tapsql.php
• The MySQL server is not configured correctly with regards to the number of connections (or the connection pool is not configured correctly)
• The database for Tapolous data is called tapolous (shocking, I know)
• The table for the devices is called devices (another shock)
• I did not post the link I clicked but if we examine the link and the INSERT statement in the error, it’s easy to see that user input is directly concatenated into the query – this one is really shocking – SQL Injection, anyone???

I’m sure that if you think a bit, you can find even more details in the error message but the last one is the most important one. I would have thought that in this day and age everybody is using bind variables. The first try to SQL Inject the link succeeded, of course. This is a popular application (and site) with a lot of registered users (including me) and having our details out there in the database does not inspire confidence.

I, of course, notified Tapulous immediately and received an email saying that the problem was fixed. Otherwise, I would not have written anything.

Oh, and looking at the original link and the SQL command being executed, I believe it’s very easy to write a small script (shell, Python, just choose your favorite) to iterate on all users and associate all the usernames with your own device…

I’d love to hear your thoughts.

In the midst of all the excitement around healthcare reform, the fact that both the house and senate made some progress on their (separate) bills for protecting personal information hasn’t received the attention it deserves.  Sure, I think we’re up to 46 states that now have their own breach notification laws, but simplifying this and raising the bar in some of the states with more lax regulations, is certain to improve the state of database security overall.

So, where does this stand?

The biggest advance was in the house, where the “Data Accountabilty and Trust Act” (aka H.R.2221) passed on December 8^th, and has been sent to the senate.  It includes provisions aimed at improving security policies, as well as breach notification requirements.  See:  http://www.scmagazineus.com/national-data-breach-notification-bill-passed-in-us-house/article/159404/

The senate, has 2 of their own bills that made it out of “committee” in November, and await a floor vote.  The “Personal Data Privacy and Security Act of 2009” (looks like they’ll have to update the name) and the “Data Breach Notification Act” address the need to better secure sensitive information and notify individuals in case of a breach, respectively.   See:  http://www.eweek.com/c/a/Security/Senate-Committee-Passes-Data-Breach-Laws-590570/

There is still work to be done in Washington (the senate must pass their bills, then on to reconciliation to get the house and senate versions aligned, and of course they all get to vote again), but even so, I’m optimistic that something will come of this next year.  Maybe I should have put that in my predictions for 2010.  If that’s the case, I think it will bring more focus in virtually every company on the need to better secure databases.  Those that have already taken the step to deploy tools to monitor activity will be in the best position to meet the new requirements with minimal disruption, and for those that have been looking for ways to justify the expense to management, this will make it much easier.