Here are the slides and links I am using for the “Database Security Using White-Hat Google Hacking” at the 2008 MySQL Users Conference and Expo.

pdf slides

Where to Start:
http://johnny.ihackstuff.com/ghdb.php

i-hacked.com/content/view/23/42

for the impatient

Google’s Terms of Service
Google Operators

More Googlehacks to run:
Page 35 of http://www.sdissa.org/downloads/San%20Diego%20ISSA%20Google%20Hacking%20and%20Beyond%20May%202006-rhd.pdf

http://pauldotcom.com/wiki/index.php/Episode81#Tech_Segment:_Google_Queries_To_Run_Against_Your_Own_Domain

http://ferruh.mavituna.com/makale/sql-injection-cheatsheet/

Goolag

Google Hacks sofware

Google Hacks Honey Pot

www.robotstxt.org

Wikto

Nikto

The answers to the last pop quiz are up: http://www.pythian.com/blogs/868/pop-quiz-mysql-cluster

So here’s another pop quiz. Given the following:

Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 16450949 to server version: 4.1.14-standard-log

Type 'help;' or '\h' for help. Type '\c' to clear the buffer.

mysql> select count(*),length(password) from mysql.user group by length(password);
+----------+------------------+
| count(*) | length(password) |
+----------+------------------+
|       49 |               16 |
|       31 |               41 |
+----------+------------------+
2 rows in set (0.00 sec)

mysql> select password('foo');
+-------------------------------------------+
| password('foo')                           |
+-------------------------------------------+
| *F3A2A51A9B0F2BE2468926B4132313728C250DBF |
+-------------------------------------------+
1 row in set (0.00 sec)

mysql> show variables like "old%";
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| old_passwords | OFF   |
+---------------+-------+
1 row in set (0.00 sec)

Since the server has old_passwords set to OFF, you may think that you can delete all the entries in the mysql.user table whose passwords have a lenth of 16. So you do this for security’s sake, and then flush privileges, and none of your applications can connect to the server any more. You scratch your head, wondering how on earth those could even be used, because wouldn’t you get a “Client does not support authentication protocol” error if the old passwords were being used?

So, what is the answer to this question?

I was asked this question recently, and I thought it was a great little tidbit of knowledge to pass along. The short answer is “no”. The slightly longer answer was written up by Jan Kneschke when dealing with a forum post about proxy + connection pooling.

From http://forums.mysql.com/read.php?146,169265,169700

The clear-text password is _never_ transfered in the authentication phase.

On the network we have:
* client connects to server (no data)
* server sends a seed (40 char, one-time, random)
* client sends 40 char hash of (seed + PASSWORD(clear-text-password))
* server compares against the hash(seed + SELECT password FROM mysql.user WHERE username = )

That way we never have the password as clear-text on the wire. (only in SET PASSWORD or GRANT statements).

I was recently asked a question by someone who had attended my Shmoocon talk entitled “Why are Databases So Hard to Secure?”. PDF slides are available (1.34 Mb). I was going to put this into a more formal structure, but the conversational nature works really well. I would love to see comments reflecting others’ thoughts.

I found several things of interest in your talk about database security and several new things to think about.

In particular I realized that DBMSs have at least two hats in the world of software architecture namely as technical services (”smart file system”) and as application framework. Perhaps that “depth” is one of the reasons why dbms is hard to secure? For example, considering just the question of who or what have user roles within a DBMS deployment. From the “deep” point of view, the “user” could be an application, or a module, or just the next layer up in the architecture stack. From the “shallow” point of view, the “user” should be an actual person whose UI actions are touching the database. I think someone in the audience was advocating that, and perhaps you were too, namely using the DBMS’s permissions and roles system to authorize actual users. But that would be different from common (even careful) practice, wouldn’t it?

I meant to grab you and re-ask my question though, namely “is all this complexity caused by the inherent difficulty of securing DBMS, or is it the _cause_ of the difficulty”? So I’ll re-ask now…

Best regards

And my response: (more…)

It’s yet again time for Oracle’s critical patch update (CPUJAN2008). The update will be released on Tuesday January 15, and as of yet there are no details on exactly what vulnerabilities have been found, but the description page mentions that the following products have unauthenticated remotely-exploitable issues discovered:

• Oracle Application Server (5)
• Oracle E-Business Suite (3)
• Oracle Enterprise Manager (1)
• PeopleSoft Enterprise (1)

So especially for you folks running the above products, start planning your maintenance windows!

Disclaimer: In most countries, looking at user passwords is illegal. Never try what is written below on a system that somebody other than you can access.

Oracle Grid Control documentation warns against leaving the emkey in the Grid Control repository. It says here:

After the emkey has been copied, you must remove it from the Management Repository as it is not considered secure. If it is not removed, data such as database passwords, server passwords and other sensitive information can be easily decrypted.

You may wonder: how easily?

A Bit of Background

When you deal with management tools, you want to collect metrics and run various tasks on different targets. Unless you evolve in an very advanced security infrastructure such as a PKI or another “real” Single Sign-On solution, it’s likely that you’ll need a username/password to connect to a remote server, a remote database, or a remote application server. Because Grid Control enables you to automate a great number of tasks, it has to be able to connect without prompting the users for credentials. In order to do that, it has to know the real passwords because it will itself authenticate on the targets. Because there no magic in there, it has to store these informations in its repository!

As a consequence, if the password you type to connect to the Grid Control is stored in a HASH form only, the one you store in Grid Control to run a task, collect data, or simply avoid typing it when you drill down to a target, has to be reversible. But I guess it’s the same for all management solution.

Let’s Be More Specific

Oracle Management Service 10.2 uses several ways to protect these sensitive data, including Virtual Private Database and Password Encryption.

• To overcome the first one, you have to be able to connect to the database as the SYS user.
• To overcome the second one, you have to know the encrypted password form, the key, and the associated algorithm.

Obviously, the key used to cipher the password is the emkey. It is located in $OMS_HOME/sysman/config/emkey.ora by default, and it can be generated/configured with "emctl xxx emkey". So the next question is, “Where are stored the ciphered passwords?”.

(more…)

I’m a Linux fan, and when it comes to specific problems, I’m afraid not all operating systems are equally armed. Enabling a specific user to listen on a port below 1024 is one of these problems that was solved for years with various approaches:

• The Windows approach: we just don’t care!
• The Solaris 10 approach: we have an advanced privilege (net_privaddr)
• The Linux approach*: you’ll find a way to make it work anyway (man setuid)

So you may think, obviously you can access the GridControl 10.2 agent on Linux with HTTPS only, on port 443! And obviously you can — but:

1. The agent cannot listen on port 443 on Linux because it uses the OC4J HTTP listener and cannot run under port 1024. I didn’t try to install the agent as root and you may know something I don’t.
2. You cannot, with 10.2, set up an HTTP front-end, like Apache, for your agent. That’s because the agent sends its listening port to the Oracle Management Server (OMS) so that the OMS can interact with it.
3. Here is a section of EM 10.2.0.4 documentation, you may want to consider: “The final step in that configuration process is to restrict uploads from the Management Agents to secure channels only. Before completing that step, configure your firewalls to allow both HTTP and HTTPS traffic between the Management Agent and Management Repository and test to be sure that you can log in to Enterprise Manager . . . ”
4. There is another interesting section of the documentation. It explains that the OMS directly accesses the target database with the Oracle*Net Protocol.

Regarding the last point, you can open the firewall to Oracle*Net traffic or have a look at Connection Manager (CMAN) to create a kind of Oracle*Net DMZ access to your databases. I’m wondering if SSH tunnels are reliable enough to handle this? I wouldn’t use it.

I know I least one other way, but I need to keep some material for future posts.

Part 1: How to Make the OMS to Agent Traffic via port 443

Can you use only port 443 between the OMS and the agent on Linux? The answer is obviously yes, and here is at least one approach: port address translation. (more…)