SNMP issue gives IPS vendors tested the most headaches.
Of the three chosen exploits, the one involving SNMP gave our IPS vendors the most trouble, though we ran into problems with all three of them on some devices.
For example, a GET query normally goes to destination port 161. If an attacker instead sends a perfectly well-formed SNMP query to port 162 (the TRAP port), vulnerable versions of IOS will reboot. Because reboot time on some devices runs into the minutes, even an attack at a very low rate could keep a vulnerable router, switch or access point off the network.
Cisco announced and patched the vulnerability in May 2004. Considering the exploit’s age and high profile, we expected all IPS systems to detect and block it without incident. To make sure that our ThreatEx tool was firing a valid attack, we tracked down a vulnerable version of IOS, loaded it up on a Cisco router and proceeded to crash it repeatedly.
Only the TippingPoint 5000E spotted the exploit in initial testing. The other five all missed it. In several cases, vendors asked us for a traffic capture, so they could write a signature.
Even the 5000E missed one highly improbable variation of the exploit during initial testing. IOS listens for unsolicited messages on UDP port 162 and on one random port in the range of 49152 to 59152. The TippingPoint device blocks solicited messages sent to either of these ports.
But if the randomly chosen port is in use, IOS instead listens on a port in the range of 59153 to 65535. Initially, the TippingPoint device did not spot exploits offered to a port in this second high-numbered range. Note that the probability of this vulnerability occurring is extremely low.
TippingPoint wrote a new signature to cover this remote possibility, but it had the effect of forwarding a small number of Cisco exploits when offered concurrently with benign TCP traffic – even when offered to port 162 (an exploit that TippingPoint previously blocked). TippingPoint gave us a second updated signature, but the problem persisted. TippingPoint was unable to replicate the leakage in its own testing.
As we started heating up the technical-support lines for all the other vendors, the patched signatures showed up fast and furious. Some vendors rapidly developed a comprehensive signature that blocked any form of the exploit. Other vendors, reacting to our test, rushed the job and wrote signatures that were so vague as to virtually guarantee false positives and negatives.
What was interesting to us was how poorly the signature-writing process worked. Demarc delivered a signature for its Snort-based system, and to its credit, also contributed the signature to the open source bleedingsnort.org signature repository. Demarc’s first attempt covered only port 162, but it quickly added signatures to cover exploits offered to high-number ports. Demarc did a great job, even though it took them a few tries to get it right, compared to Ambiron TrustWave’s ipAngel, another Snort derivative.
When ipAngel initially missed the Cisco exploit, Ambiron TrustWave delivered a signature that blocked the specific variant of the Cisco SNMP exploit we used in testing, but the signature likely would lead to false positives in a production setting. The ipAngel signature checks for any SNMP traffic sent to UDP destination ports 162 or 49152-65535. That enabled the device to pass our performance test, but the signature also would generate false positives on any legitimate SNMP TRAP. The company says it has written a more narrowly defined signature since we completed testing.
We also discovered the drawbacks in combining IPS technology into UTM firewalls, a difficult design to get right. Fortinet’s FortiGate initially forwarded all exploit traffic, not just the Cisco SNMP attack. This was because of a UDP learning issue in the FortiGate UTM box, in which it would broadcast all traffic for which it had not yet seen destination MAC addresses. In this regard, FortiGate worked like an Ethernet bridge, not a security appliance. Fortinet corrected that behavior with new firmware, but the IPS still forwarded all exploits when we attacked at 16% of the system’s capacity. It also forwarded the Cisco exploit at any offered rate when we used a high-numbered destination port. It took another new firmware release to shut out the exploits for good.
NFR developed an effective signature after we sent its engineers a capture of the exploit traffic we used when the NFR Sentivist missed the exploit on the first try.
Top Layer’s IPS 5500 initially forwarded Cisco exploit traffic. After we supplied the traffic capture, Top Layer supplied a pattern-matching signature that we found easy to evade. First, it detected only an SNMP GET message and not other solicited message types such as GETNEXT that also would cause reboots. Second, it covered only queries exactly 28 bytes long, when in practice SNMP message length is variable. Third, the signature covered only exploits sent to destination port 162 and not high-numbered ports.
Top Layer supplied additional signatures to cover the first two issues. As for listening on high-number ports, the company disagreed that an IPS would need to block these. Company engineers stated that firewall policies and/or router access-control lists should be sufficient to block this traffic.
That’s a disingenuous argument, in our opinion. If firewalls were always perfectly configured, and if hosts were always fully patched, the need for signature-based IPS would disappear. Because we were testing IPS systems on their ability to do their jobs, it didn’t seem relevant that most enterprises would have intended to block SNMP, Witty and SQL Slammer at their external firewall. More important, the Witty and SQL Slammer worms became notorious because people didn’t have firewalls in place and properly configured.
These results don’t mean that IPS systems aren’t useful at increasing the security of enterprise networks. What they do say, though, is that an IPS can only be one component in a defense-in-depth security strategy, and that it’s much better to eliminate the vulnerabilities in your network by patching software and firmware than it is to depend on the IPS to provide protection.
Previous: Full results of usability testing | Next: Downsides of IPS coverage >
