Saturday, October 22, 2005

The Coming Snort Worm

This week we learned via an advisory of a vulnerability in the Back Orifice preprocessor in Snort version 2.4.2, 2.4.1, and 2.4.0. The vulnerability was discovered by another ISS X-Force researcher. I bet (but have no inside knowledge) that he was following the same marching orders that Mike Lynn received: find vulnerabilities in competitors' products. Mike looked at Cisco, and Neel Mehta looked at Sourcefire's Snort.

I am sure ISS is still bitter over the Witty worm that revealed the installed ISS RealSecure and BlackIce userbase to be about 12,000 systems. The Witty worm spread via a single UDP packet with a fixed source port of 4000 UDP.

Let's consider the factors that lead me to believe that the Snort BO vulnerability will produce a worm.

  1. The new vulnerability can be exploited by a specially crafted UDP packet to or from any port other than port 31337. (Thanks to Jose Nazario for correcting me on this point.) This is similar to the UDP packet used by Witty. UDP is an ideal worm vector, as demonstrated by Slammer. There is no need for a TCP handshake, which means spoofing is much easier.

  2. Sensors need not be directly targeted. All a worm has to do is send exploit UDP traffic to a segment monitored by a vulnerable Snort sensor. The attacker need not know anything about the target's management IP address.

  3. Snort has been in the news recently as a result of its acquisition by Checkpoint. A worm coder can kill or embarrass two birds with one UDP stone.

  4. Snort is everywhere -- .com, .net, .org, .edu, .gov, etc. 0wning a .mil or .gov Snort sensor gives intruders the ultimate vantage point over a monitored network. I imagine sophisticated intruders have already compromised a slew of sensitive Snort sensors, but at some point a lower life form will decide to turn the exploit into a worm.

  5. Snort source code is available, so comparing 2.4.0-2.4.2 with 2.4.3 means the vulnerability can be quickly identified.

I can imagine a few factors that will reduce the likelihood of a worm.

  1. The vulnerability reportedly exists in Snort versions 2.4.0 through 2.4.2. That's a narrow set of versions, given Snort 2.4.0 was released in July. I have heard of users running Snort 1.8.x and 1.9.x; they complain about rules that don't work with their versions. Argh!

  2. Snort runs on a huge number of platforms. That is one of the beauties of the program. Will a worm target Snort on Linux? If so, what distro/kernel/version/etc.? How about Snort on Windows? That would make the most sense -- the OS would be fairly similar, and the user base would make for good targets. We'll see.

  3. Sophisticated intruders will keep any exploit to themselves. They may try to keep it out of the hands of the bottom feeders.

What do you think? Will we see a Snort worm? I'm keeping an eye on FrSIRT.

On a related note, be sure to upgrade to Ethereal 0.10.13 -- 0.10.12 has bugs too.


Scott said...

ISS discovered this issue, I thought it was USCERT???


"On Thursday, October 13th Sourcefire was contacted by USCERT with news of a vulnerability in Snort."

Richard Bejtlich said...

ISS discovered it, then worked with US-CERT.

Scott said...

Ok, thanks for clarifying that.

Anonymous said...

The most likely outcome of trying to exploit this vulnerability is a DoS, not an overflow. People keep talking about this vulnerability as if it's trivial to exploit on all the platforms that Snort supports but it's not.

Anonymous said...

Couple of things not mentioned which reduce the impact of this vulnerability.

If you run snort as unpriv username "snort" instead of "root" (which should be the majority), then they get local access - not root.

Secondly, snort should be run in a chroot'ed jail (the "-l" option) - so the exploit would give the hacker unpriv access in a jail containing no interesting files. In fact, most overflows attempt to invoke /bin/bash waaay at the beginning - and I'm yet to meet a jail which has that binary in it! ;-)

Ilja said...

There's really no need to compare 2.4.2 with 2.4.3, If you can read some c code and just take a look at the BO preprocessor you should be able to spot the bug in a couple of minutes.

Hm, the thing about people saying that it's likely going to be a DoS and not be exploited is odd. All the reasons being mentioned are true not just for this bug but pretty much ALL stacksmashes. And I would classify most stacksmashes (including the one in snort) as (almost) trivial. It would have been a whole different thing if it was some sneaky heap off-by-one (or something simular), but it's not !

Richard Bejtlich said...

I just posted the results of running 'diff -u snort-2.4.3/src/preprocessors/spp_bo.c snort-2.4.2/src/preprocessors/spp_bo.c > 2.4.2-2.4.3_diff.txt' here.

jose nazario said...

richard, you have a critical fact wrong above. it's UDP packets to and from any ports BUT 31337. 31337 short circuits the logic and bypasses the vulnerable code in spp_bo.c. anything but 31337 (where the src and the dst ports are not 31337) gets the vulnerable treatment in 2.4.0-2.4.2.

Richard Bejtlich said...

Jose, thanks for the correction!