Fun with IDS funtime #3: heartbleed

I don't like the EmergingThreat rules, not so much because of the rules themselves but because of the mentality of the people who use them. I scan the entire Internet. When I get clueless abuse complaints, such as "stop scanning me but I won't tell you my IP address", they usually come from people using the EmergingThreat rules. This encourages me to evade those rules.

The latest example is the Heartbleed attack. Rules that detect the exploit trigger on the pattern |18 03| being the first bytes of TCP packet payload. However, TCP is a streaming protocol: patterns can therefore appear anywhere in the payload, not just the first two bytes.

I therefore changed  masscan to push that pattern deeper into the payload, and re-scanned the Internet. Sure enough, not a single user of EmergingThreats complained. The only complaints from IDS users were from IBM sensors with the "TLS_Heartbeat_Short_Request" signature, and from some other unknown IDS with a signature name of "Heartbleed_Scan".

That the rules can so easily be evaded is an important consideration. Recently, the FBI and ICS-CERT published advisories, recommending IDS signatures to detect exploits of the bug. None of their recommended signatures can detect masscan. I doubt these organizations have the competency to understand why, so I thought I'd explain it in simple terms.

Fun with IDS funtime, part 2

As I posted last week, intrusion detection systems (IDS) are catching me doing Internet-scale surveys. This gives me a chance to try and evade them. Of course, once I evade them, I have to document my tricks, so they can catch me again -- because I'm not actually trying to go undetected. I'm just having fun.

My latest trick involves DNS and the "version.bind" detection. You can query the version information of a DNS server by sending a "chaos txt version.bind" query to it instead of a normal query like www.google.com. The Snort signature that detects this looked like the following:

A bit of IDS history

I saw this tweet go by, and as a creator of a popular IDS (BlackICE aka. Proventia), I thought I'd discuss a bit of the history, as things are a bit more complicated than just that:

Have you read any of these early computer security papers archived by NIST? csrc.nist.gov/publications/h… The Anderson work was the basis for IDS.

— Richard Bejtlich (@taosecurity) August 10, 2012

From talking to fellow network IDS creators (Marty, Ron, Marcus, Vern), there was never any basis for our work other than "packets". We each built a packet analyzer to look for stuff we were interested in, each building a wildly different architecture in pursuit of wildly differing goals.

IDS is how everyone else described our work, but this was not necessarily the goal we had when starting out. I had code running for years (starting in 1990) before I ever heard the term "intrusion detection system". In much the same way, I called my inline version "inline IDS" before others decided to call it "IPS".

This is not say that the above papers don't deserve credit for coming up with brilliant ideas. They probably do. It's just that I've never read them, and they were not the "basis" for my work.

Likewise, while not the "basis", they probably influenced my work in some ways. Other people read them, creating a mishmash of ideas that probably influenced the direction of my work without me realizing it. Simply the fact that a "syslog" demon exists and that I send events to it means that I'm undoubtedly influenced by whoever invented "syslog".

Consider Marcus's IDS called "NFR". If it's based on anything, it's based on MUDs (multi user dungeons, a type of early text based "game"). He had bits of code lying around for which he repurposed into some totally unrelated bit of code. I use this as the most amusing example, but pretty much all early Internet code was developed with the same sort of model: lurching in unexpected directions rather than being based on a plan.

My own start was in 1990 with my first job out of college working as a generic software programmer for a company that made a product called the "Protolyzer", a protocol analyzer competing against the better known Network Genral "Sniffer". The Protolyzer's unique features was that it had a graphical user interface (based on OS/2) when all competing tools were text based.

Among my duties was to create "addons" for that plugged into the Protolyzer to look for interesting stuff other than simply decoding packets. A lot of these addons were to diagnose network faults. Others were related to security. Since these addons could act as filters, the Protolyzer had primitive "IPS" capability, in that it could capture, filter out security events (namely ARP spoofing), and retransmit.

The company was then bought by Network General and the technology folded into the Sniffer, and largely died. I tried to interest the company in resurrecting it in a Version 2.0 form that I had come up with using "streaming state-machines". You see, all previous protocol analysis was done at the level of "packets" or "packet payloads". My design was to use the TCP "stream" as the atomic unit, and instead of buffering packets to reassemble them into buffers, to parse the stream using a state-machine.

This is actually a pretty common technology now, and the basis for most network IDS/IPS, but back then it was unique.

But Network General wasn't interested, so in 1998 when Network General merged with McAfee Associates to form Network Associates, I left to found my own company and implement my technology. The result was "BlackICE", the first intrusion prevention system, now sold as IBM Proventia (ISS acquired my company in 2001, then IBM acquired ISS in 2006).

The point of this story is to describe what my stuff was "based on". It was based upon my experience with hacking computers, and based upon my experience in analyzing packets. Indeed, I probably would have done a better job had I read more academic papers. For example, I "invented" my own multi-pattern matching system that, as it turns it, is just the Aho-Corasick algorithm. I would have saved a lot of time and effort had I just studied a bit better.

Conclusion

I'm not trying to diminish earlier works, or praise us early IDS inventors for inventing everything ourselves. Instead, I'm trying to describe how things were messy, how we didn't really follow a plan, didn't really "base" our work on anything, and how we are as surprised as everyone else how things turned out.

Also, I don't want to put words in the mouths of Vern, Marcus, Marty, or Ron (which is why I only use first names so that it may be hard for you to identify them), so much as tell my own story. They will undoubtedly have very different stories if you talk to them. (I'm eagerly awaiting a comment from Marcus correcting my interpretation).

So in short, while IDS may indeed be "based" on earlier things, the path to get there is "complicated".

---

Updates:

@securityskeptic @erratarob That paper and the Tweets/posts following miss @toddheberlein and his NSM taosecurity.blogspot.com/2007/04/networ…

— Richard Bejtlich (@taosecurity) August 10, 2012

Some IDS comments

I saw this go across my twitter feed:

d3tm4r a.k.a Kamerazukleber 

Still missing in Snort: inclusion of HTTP response codes in alerts & appropriate prioritization.

1 hour ago Favorite Retweet Reply

Wireless NAC != Wireless IPS: AirTight...Leaks...

Rob Graham and I came in contact with some Airtight boxes. In case you don't know they are a maker of wireless IDS technology. Since we know a thing or two about wireless we wanted to look and see how these boxes work and if the perform as advertised. If you don't want to read the entire blog post the short answer is: not completely. In our quick peek we found 3 problems. If we were doing a real assessment we would have pulled out the screw drivers and, ICE gear, and disassembler but instead we looked at this from a blackbox remote perspective.

Problem 1: Protection relies on you being a good citizen.

One of the most touted features is the ability to shutdown rogue access points and give administrators the ability to control who has access points and who doesn't and which ones are legitimate and which ones are not. This is done by detecting the access point, determining if it is legitimate and then flooding it with deauthentication packets if it isn't. It does this by spoofing deauthentication packets in both directions from the user to the access point and from the access point to the user (Packet caps of this to the right). These packets are in the standard and are basically there to say "go away, I am not interested in working with you". So I am sure you are curious what happens if you modify you driver and an access point to ignore these types of packets? Nothing, you can just keep humming away and do whatever it is you want to. Now the argument we heard when we originally mentioned this to people is that these types of devices are not designed to stop determined attackers, just a clueless guy who plugs in a Linksys in accounting and those guys don't use custom wifi drivers. To bad, we do, and this company would have failed a penetration test. Relying on a remote attacker to adhere to a standard for your security too to work is crazy, that's as bad as the Cisco Security Agent API hooking that relied on you executing jumps to its analysis engine to work properly. In the Cisco case and the Airtight case you can just ignore the spec and the security breaks down.

Problem 2: Slowdown

We looked at how these devices would detect new access points. I thought at first it would be done via a combination of beacon and probe response to verify they were real access points but we noticed something. The device would detect the access point from what appear to be probe response packets and then one of their sensors would spoof a packet to be transmitted through the access point to itself. If it received the packet then it would know the access point is indeed on the network. So what happens if you generate hundreds of thousands of fake probe responses? There is such a slow down in responding to them that you could actually go about your normal business of plugging in a rogue access point and letting people external to your offices have access to you network before the sensors will actually detect it and start blocking it. Saturating it with about 10,000 fake probe responses meant that we would have between 1:30 minutes and 3:30 minutes before Airtight realized our access point had appeared. This may not seem like a lot but if you are trying to copy things out unseen or quickly infect a company with a worm, that all the time you need. We didn’t spoof for very long, but it appeared that if we left it running, we’d eventually fill up the database and take down the system.

Problem 3: It really does leak
In problem 2 it was noted to verify that an access point is actually on the network a sensor would spoof a packet to be transmitted through the access point and if it was received by the sensor the containment process would begin by generating fake deauthentication messages. This is a problem because it leaks information about your internal network. This method of determining whether or not an access point is on the network means that UDP packets are being generated with the internal IP address of not just the sensor sending the spoofed packets but also the management console and sending them over sniffable wireless access for all to see and capture. So even if you are not on the network and just sniffing the channel the AP is on you can get information on that company's internal network information like addressing scheme and layout; you could even write a snort rule to detect just these types of packets.. Thank you very much! With the work that has been done on Ferret we have become hyper sensitive to unintentional information leaks and this is definitely one.

Verdict: Great for clueless folks but will not keep out a skilled attacker

While these boxes may keep Bob from accounting from buying an access point at lunch and sharing your network to the world, they will not stop and in some cases aid a determined attacker in compromising your enterprise. They should not be labeled either "intrusion detection" or "intrusion prevention". These devices have no ability to stop a driver level attack like the ones we have previously discussed.

Also I hate recreating other peoples work. After we found these problems I was pointed to the paper below that contains information about the deauth problems. It has a far more in-depth review of the weaknesses and why most of these products just don't add up.http://802.11ninja.net/~jwright/802/papers/wlan-sess-cont.pdf

Storm Worm vs. IDS

News from last week was this "Storm Worm". A hacker launched malware by a massive spam campaign. This meant that thousands of users were likely infected before the anti-virus companies had a chance to respond to the virus and release signatures to their customers.

SANS has an interesting post about how this shows that traditional anti-virus can't deal with the problem. The describes a one-line Linux shell script that can detect whether a ZIP file likely contains a virus:

if zipinfo patch-58214.zip grep -q 'BX.*\.exe' ; then echo 'encryped executable'; fi

This is almost identical to a signature I wrote for the Proventia IPS. Proventia is based upon protocol-analysis technology. This means that it decodes the SMTP protocol, e-mail format, and BASE64 decodes MIME attachments. It then parses the ZIP file just like 'zipinfo'. While it doesn't uncompress/decrypt the contents of a ZIP file, it can still process the filenames. My signature tests the filename to see if it ends in something executable, such as .exe, .scr, .pif, etc. Because it uses protocol-analysis, Proventia blocks the e-mail by sending a "500" return code in SMTP instead of killing the TCP sesson. Because it uses protocol-analysis, it reports to the operator the filename, the subject line of the e-mail, and the from/to addresses in the SMTP session. Because it's NOT a store-and-forward proxy, it can run at multiple gigabits-per-second. This, and a few similar signatures in Proventia will stop most 0day e-mail viruses at gigabit speeds. It's fabulously useful, but of course, few people use it.

The technology is ready for 0day viruses, the problem is that the market still isn't. The technology I describe above doesn't fit within any easy market category, it's neither precisely what people understand as "intrusion-prevention" nor "anti-virus". It's like a thousand other bits of technology that languish in our industry because there is no neat category for them. I created the first IPS (BlackICE Guard aka. Proventia), but it was a just an IDS feature until Intruvert showered money on Gartner to create a new category for it.

EDIT: btw, for people interested in the history of IPS, the following is a post from 2001 I made to the Security Focus IDS mailing list. This was before Gartner created the market segment. You can tell my frusteration trying to differentiate IPS from firewalls and pure IDS.

http://archives.neohapsis.com/archives/sf/ids/2001-q1/0168.html