New method for blocking Code Red and similar exploits that use HTTP GET

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 in the article). 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.....

Last Updated: 7 Aug 2001, 7:50PM 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.
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

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.

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: