On Sept. 4, 2001, Cisco announced a series of products to enhance security, including a SOHO firewall and the Cisco IDS (Intrusion Detection System) Host Sensor. The company said that the products continue “to expand its technical and market leadership by delivering practical security and VPN innovations for real-world business demands.” The IDS Host Sensor is a new, host-based intrusion detection device. This product was an addition to the SAFE security platform for VPNs based on Cisco AVVID (Architecture for Voice, Video, and Integrated Data), and it sounded very impressive.

However, the next day, Cisco sent out another press release indicating that this IDS system can be tricked by hackers encoding packets using the %u encoding method. This method is a nonstandard form of URL encoding used by Microsoft in its IIS Web server. It’s similar to Unicode, but since it’s nonstandard, this encoding is not automatically decoded by all IDSs. Therefore, packets made using this coding method may be passed right through an IDS, as is the case with Cisco’s IDS.

Before looking at the details of this flaw, I should point out that I’m presenting the issue mainly to demonstrate the need to employ multiple layers of security. This particular problem is risky only for those who rely solely on IDS for security—but it serves as a powerful reminder to all administrators that depending on just a single layer of defense is dangerous.

Systems affected
The particular problem was discovered by eEye Digital Security, which then informed Cisco. EEye Digital Security provided this expanded list of systems that may be vulnerable to this flaw:

  • Cisco Secure Intrusion Detection System, formerly known as NetRanger, Sensor component
  • Cisco Catalyst 6000 Intrusion Detection System Module
  • ISS RealSecure Network Sensor 5.x and 6.x before XPU 3.2
  • ISS RealSecure Server Sensor 6.x prior to 6.0.1
  • ISS RealSecure Server Sensor 5.5
  • Dragon Sensor 4.x
  • Snort prior to 1.8.1
  • NFR (Network Flight Record)

Obviously, there may be other IDS systems that aren’t aware of the nonstandard IIS encoding option and that are, therefore, also vulnerable.

Details of the flaw and a workaround
In terms of Cisco equipment, the %u vulnerability applies to the old NetRanger (Secure IDS) Sensor component and the Catalyst 6000 IDS module. Service pack 3.0(2)S6, which contains a patch for the Cisco Secure Intrusion Detection System Sensor, is available, but it is still beta code. The full service pack 3.0 (which will also contain the patch for the Catalyst 6000 IDS) is slated for release in October.

Until the patch for the Catalyst 6000 IDS becomes available, you may want to consider the workaround, which can be applied to both the Cisco Secure Intrusion Detection System Sensor and the Catalyst 6000 Intrusion Detection System Module. The process consists of defining a custom string match signature that will detect the Unicode obfuscation, but Cisco warns that this may cause false alarms because there may be legitimate uses of the Unicode string. In other words, if you use this workaround, be prepared to monitor the log results carefully.

Here’s Cisco’s workaround, as listed in its announcement:
Signature 1
Unicode Obfuscation String:   
If you have Web servers listening on other TCP ports (for example, 8080), you will
need to create a separate custom string match for each port number.
Recommended Alarm Severity Level:
High (CSPM)
5 (Unix Director)

The custom string match feature is documented on Cisco’s Web site.

Again, I want to emphasize that this won’t be a major problem for anyone who doesn’t rely entirely on IDS to protect his or her server. However, since I’m using this as a warning example, I thought I should go ahead and include all the details. In fact, this could have been a major, even disastrous, problem if the Code Red worm’s designers had chosen to use %u encoding instead of attacking .ida.

Most networks aren’t vulnerable to this problem because other security measures will block the attack after it gets past their IDS. But it does peel away another layer of protection—and when enough layers are compromised, a network becomes vulnerable.

Bottom line
This isn’t a major vulnerability, and Cisco moved quickly in releasing information to get on top of the problem, but this incident is an excellent example of the need for a multilayer network defense. If a network is protected only by IDS, this flaw could cause major problems. The only mitigating factor is that most administrators wouldn’t rely only on IDS.

This is also yet another in a seemingly endless string of reminders that new software and hardware almost always have bugs. Sometimes they’re small; sometimes they’re major. But they’re always dangerous. Make sure your network has multiple layers of protection as part of your security strategy.

How do you implement a multilayer security strategy?

We look forward to getting your input and hearing about your experiences regarding this topic. Join the discussion below or send the editor an e-mail.