Are You Ready?
Bookstore

IPonEverything.net Security Advisory:
Blocking Code Red Worm with Cisco IOS NBAR

Release Date: 4 Aug 2001, 12:00PM EDT

Last Updated: 7 Aug 2001, 11:25PM EDT

We Need Your Help!

We'd like to hear from those that have implemented either of the solutions outlined in this advisory. While we have tested & implemented both approaches, we hardly have what we'd call a heavy load of traffic to gather statistics (we're blocking about 3,000 hits/day). If anyone has implemented this in a production environment with real traffic loads, drop us an e-mail. In particular, we'd like to know about observed CPU impact and overall effectiveness of this solution.

Thanks,
Randy

Summary:

This advisory provides 2 methods for blocking the Code Red worm using Network Based Application Recognition (NBAR) within IOS software on Cisco routers. The first solution classifies inbound traffic using NBAR, then filters traffic on an outbound interface using extended ACLs. The second solution also classifies inbound traffic using NBAR, then uses class-based policing to drop offending traffic. These solutions should be used in conjunction with the recommended patches for IIS servers from Microsoft.

Details:

Of course, the first thing that needs to be done to combat "Code Red" is to apply the patch available from Microsoft (see links below). This will both protect vulnerable systems and remove the worm from an infected system. However, applying the patch to your servers only prevents the worm from infecting the server, it does not stop the HTTP GET requests from hitting the server. Obviously, there is still the potential for the server to get bombarded with a flood of infection attempts.

The solutions detailed in this advisory are designed to work in conjunction with the Microsoft patch to block the Code Red HTTP GET requests at the network level.

After reviewing the access logs on my web server and seeing a whole bunch of entries for Code Red infection attempts, I decided to see what I could do to block these attempts on my access router. Below is a summary of what I came up with. Bottom line is that the infection attempts can be blocked with a combination of class-based marking and an extended ACL.

Detecting the infection attempt in IIS web logs

The initial infection attempt sends a large HTTP GET request to the target IIS server. A couple samples are below:

Original Code Red footprint:

   2001-08-04 16:32:23 24.101.17.216 - 10.1.1.75 80 GET /default.ida 
   NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
   NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
   NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN
   NNNNN%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u
   7801%u9090%u9090%u8190%u00c3%u0003%u8b00%u531b%u53ff%u0078%u0000%u00=a 403 

Code Red II footprint:

   2001-08-04 15:57:35 64.7.35.92 - 10.1.1.75 80 GET /default.ida XXXXXXXXXXX
   XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
   XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
   XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX%u9090
   %u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%
   u9090%u8190%u00c3%u0003%u8b00%u531b%u53ff%u0078%u0000%u00=a 403 -

Notice that the GET request is always looking for a file with a '.ida' extension. This is a common string that will be in all infection attempts and can therefore be used as a match criteria with class-based marking in IOS. The remainder of the GET request will not necessarily be consistent as it is just attempting to create a buffer overflow. This can be seen by comparing the 2 entries above.

It is now being reported that the difference between these 2 signatures is due to a new strain of the Code Red worm, dubbed CodeRed.v3 or CodeRed.C. The original Code Red strain contains the "NNNNNNNN" string in the GET request, while the new strain contains "XXXXXXXX." Refer to the Symantec Advisory link below for more details.

Update:

At 6:24PM EDT, 6 Aug 2001, we recorded a new footprint in our IIS server logs. We have since learned that this is the footprint that is left behind by the eEye vulnerability scanner.
   2001-08-06 22:24:02 24.30.203.202 - 10.1.1.9 80 GET /x.ida AAAAAAAAAAAAAA
   AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
   AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
   AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=X 403 HTTP/1.1 -

Note that the techniques for blocking Code Red provided in this advisory can also block these scanning attempts simply by tightening the class map definition as shown below in [1].

Approach #1: Inbound classification with NBAR, outbound filtering with ACLs

The advantage of using this approach is that much more information is avaiable about the blocked Code Red traffic since extended ACLs are used. By logging the ACL violation, the exact number of blocked attempts can be logged, as well as the source address of the attacking station. The disadvantage of this approach is that it is slightly more complex since it requires an outbound ACL along with the traffic classification. Also, we would expect greater CPU impact with this approach compared to the policing approach below.

While we have tested and validated both of these solutions, we do not have sufficient traffic to provide any useful information about actual CPU impact.

[1] Classify inbound Code Red Hacks with the class-based marking feature in IOS:

You must start by enabling CEF globally on the router since it is required for NBAR. When CEF or dCEF is enabled globally, all interfaces that support CEF are also enabled by default.

The traffic is then classified by using a class map to match known 'signatures' of the offending traffic.

   Router(config)#ip cef
   Router(config)#class-map match-any http-hacks
   Router(config-cmap)#match protocol http url "*default.ida*"
   Router(config-cmap)#match protocol http url "*x.ida*"
   Router(config-cmap)#match protocol http url "*.ida*"
   Router(config-cmap)#match protocol http url "*cmd.exe*"
   Router(config-cmap)#match protocol http url "*root.exe*"
The above class map will look inside of HTTP URL's and match any of the specified strings. Notice that I have included other file names besides Code Red's 'default.ida'. This same technique can also be used to block similar hack attempts, such as the Sadmind virus, which I continue to see in my server logs on a regular basis:
http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/bulletin/MS00-078.asp http://www.sophos.com/virusinfo/analyses/unixsadmind.html

[2] Mark inbound Code Red Hacks with a policy map:

Once the inbound traffic has been classified as a Code Red hack, it can be marked with a specific DSCP. In this case I have simply chosen a decimal value of '1' as it is unlikely that any other traffic would be marked with this DSCP.

Router(config)#policy-map mark-inbound-http-hacks Router(config-pmap)#class http-hacks Router(config-pmap)#set ip dscp 1

Apply the service policy to the 'outside' interface, or wherever the Code Red attacks are originating:

Router(config)#int e 0/1 Router(config-if)#service-policy input mark-inbound-http-hacks

[3] Block marked hack attempts with an ACL:

The ACL will match on the DSCP value of '1' that was marked as the hack attempt entered the box:

Router(config)#access-list 105 deny ip any any dscp 1 log Router(config)#access-list 105 permit ip any any

Apply it outbound on the 'inside' interface, or wherever the target web servers are:

Router(config)#int e 0/0 Router(config-if)#ip access-group 105 out

[4] Verify operation:

Router#sh access-list 105 Extended IP access list 105 deny ip any any dscp 1 log (2406 matches) deny tcp any any dscp 1 log permit ip any any (731764 matches) Router#sh log Aug 4 13:25:20: %SEC-6-IPACCESSLOGP: list 105 denied tcp 24.163.120.238(0) -> 10.1.1.75(0), 6 packets Aug 4 13:26:32: %SEC-6-IPACCESSLOGP: list 105 denied tcp 24.163.95.138(0) -> 10.1.1.75(0), 6 packets Router#sh policy-map interface e0/1 Ethernet0/1 Service-policy input: mark-inbound-http-hacks Class-map: http-hacks (match-any) 3101 packets, 4292566 bytes 30 second offered rate 2000 bps, drop rate 0 bps Match: protocol http url "*default.ida*" 3101 packets, 4292566 bytes 30 second rate 2000 bps Match: protocol http url "*cmd.exe*" 0 packets, 0 bytes 30 second rate 0 bps Match: protocol http url "*root.exe*" 0 packets, 0 bytes 30 second rate 0 bps QoS Set ip dscp 1 Packets marked 3101

Update:

Approach #2: Inbound classification with NBAR and class-based policing

The advantage of this approach is that it is simpler and we would expect less impact on the CPU compared to the ACL approach. Therefore, it may be better suited for SP implementation where performance is of primary concern. The disadvantage of this approach is that there is less information available about the blocked traffic. Since ACLs are not being used, it is not possible to log the number of successful blocks or the source address of the attacking node.

While we have tested and validated both of these solutions, we do not have sufficient traffic to provide any useful information about actual CPU impact.

[1] Classify inbound Code Red Hacks with the class-based marking feature in IOS:

This step is identical to the classification used above in the first approach. Once inbound traffic has been classified, class-based policing can be implemented at the ingress interface on the box.

[2] Apply class-based policing at router ingress:

In this particular case, it doesn't matter what actual values we use for rates and bursting limits as we will simply drop all traffic. That is, we will drop conforming, exceeding and violating traffic.

Router(config)#policy-map police-inbound-http-hacks Router(config-pmap)#class http-hacks Router(config-pmap)#police 8000 1500 1500 conform-action drop exceed-action drop violate-action drop

Apply the service policy to the 'outside' interface, or wherever the Code Red traffic is originating:

Router(config)#int e 0/1 Router(config-if)#service-policy input police-inbound-http-hacks

[3] Verifying operation:

The only method we are aware of to see the resulting action of this approach is with the 'show policy map interface' command, as shown in the sample below.

In this example, 216 packets have been dropped as a result of the policing action. This number can be seen in the 'Class-map' section, and also if you add the values in the 'police' section for conformed, exceeded and violated packets.

Router#sh policy int e 0/1
 Ethernet0/1

  Service-policy input: police-inbound-http-hacks

    Class-map: http-hacks (match-any)
      216 packets, 311964 bytes
      30 second offered rate 0 bps, drop rate 0 bps
      Match: protocol http url "*default.ida*"
        216 packets, 311964 bytes
        30 second rate 0 bps
      Match: protocol http url "*x.ida*"
        0 packets, 0 bytes
        30 second rate 0 bps
      Match: protocol http url "*.ida*"
        0 packets, 0 bytes
        30 second rate 0 bps
      Match: protocol http url "*cmd.exe*"
        0 packets, 0 bytes
        30 second rate 0 bps
      Match: protocol http url "*root.exe*"
        0 packets, 0 bytes
        30 second rate 0 bps
      police:
        8000 bps, 1500 limit, 1500 extended limit
        conformed 16 packets, 9264 bytes; action: drop
        exceeded 1 packets, 1414 bytes; action: drop
        violated 199 packets, 301286 bytes; action: drop
        conformed 0 bps, exceed 0 bps violate 0 bps

    Class-map: class-default (match-any)
      3952 packets, 2256722 bytes
      30 second offered rate 0 bps, drop rate 0 bps
      Match: any

Supported Platforms:

The technique specified in this advisory requires the class-based marking feature within IOS. Specifically, it is using a new feature within IOS called Network Based Application Revognition (NBAR). The ability to match on any part of an HTTP URL is utilizing the HTTP sub-port classification feature within NBAR. The supported platforms and minimum IOS requirements are summarized below. Consult Cisco's IOS Feature Navigator for more details.

Platform Minimum IOS
7200 12.1(5)T
7100 12.1(5)T
3660 12.1(5)T
3640 12.1(5)T
3620 12.1(5)T
2600 12.1(5)T
1700 12.2(2)T

Class-based marking and Distributed NBAR (dNBAR) are also available on the following platforms:

Platform Minimum IOS
7500 12.1(6)E
FlexWAN 12.1(6)E

Note that these are the MINIMUM required IOS verisions for the supported platforms. 12.1(5)T has actually been DEFERRED and 12.1(5)T7 is currently the latest ED relase available for most of the supported platforms. Consult the CCO Software Library for further guidance.

Credits:

Thanks to:
-Scott Frisby at Cisco for clearing up some of the technical details in this alert.
-Dan Hadsell at Cisco for the suggestion on the policing approach.
-Nathan Way at Datanode for pointing out some typos & omissions in the sample syntax.
-Antonio Vasconcelos for his comments and suggestions.

Issues:

[A] After using this solution for 2 days now, I have observed that not all Code Red GET requests are being blocked. Most, but not all, are being blocked. To quantify this, I have logged over 6,400 blocks using this method. Over the same interval, approximatley 25 Code Red GET requests have 'leaked' through. Working with Cisco TAC to see what's going on with this.

[B] The Code Red worm exploits a vulnerability on unpatched servers within IIS that uses the Microsoft Indexing Service. The Internet Data Administration script file (default.ida) is installed by default on all IIS servers. Code Red relies on the presence of this file to carry out the exploit. Most systems do not use this service so the blocking method provided in this advisory will be effective. However, it should be considered that some servers may be using this service within IIS. In this case, the blocking method proposed here could block legitimate requests to the IIS server.

Related topics:

Cisco's Official Version of Our Solution
Cisco "Code Red" Advisory
eEye "Code Red" Advisory
eEye "Code Red" Vulnerability Scanner
Microsoft Security Bulletin
Microsoft Patch Instructions
CERT Advisory
SANS Advisory
Symantec "CodeRed.v3/CodeRed.C" Advisory
Report: AT&T Shuts Down Port 80 to Block Code Red
The Real "Code Red"

Copyright (c) 2001 GNSI:

Permission is hereby granted for the redistribution of this alert electronically. It is not to be edited in any way without express consent of GNSI. If you wish to reprint the whole or any part of this alert in any other medium excluding electronic medium, please e-mail mailto:press@iponeverything.net?subject=CodeRed Re-print for permission.