Defending your right to defend:
Considerations of an automated strike-back technology
Timothy M. Mullen
9/10/2002
9/23/2002 Updated
10/28/2002 Updated

Ver 1.0.3


Introduction:

Over a year after Code Red and Nimda were launched on the Internet, the
worms continue to propagate.  On a daily basis, system administrators
around the world must wade through server logs and try to pick out important
transactions from the volume of “noise” these worms and their variants cause.

Many have attempted to contact the owners of these infected boxes, or the 
ISP’s with whom the owners are homed- most fail.  Of the host records that
contain any contact information at all, most are out of date or incorrect.
ISP’s, already strapped from economic losses, do not have the time, or the
inclination, to be of any service.  Some attempt to man the abuse 
mail-stations, but most submissions just get lost in the volume. 

On occasion, one gets lucky and actually makes contact with a human being
that is loosely affiliated with the infected systems; but unfortunately, our
attempts to notify personnel of the fact that they own a machine that is 
attacking adjacent machines on the Internet is met with disregard or even 
hostility.  At the end the day, all of the time and effort we put into trying 
to rid the Internet of malicious code inevitably turns out to be a complete 
waste of time. 

These efforts simply do not work.


These worms are more than just “nuisance” problems.  Bandwidth costs money.  
Servers cost money.  And personnel costs money too.  As more worms are 
released upon the Internet, the noise level will continue to rise, along with 
our costs for dealing with it.  Even if we attempt to simply ignore the 
traffic, this still costs money in bandwidth, router, and server utilization.

Black-holing, a measure where routers are configured to drop particular 
raffic at the external interface is an effective means of keeping the 
malicious traffic from reaching your server farm, but it does not address the 
bandwidth issue.  The traffic must still reach our interface in order for 
it to be analyzed and dropped.  It also requires constant rule updates to be 
effective, and equipment robust enough to handle the volume of rules.  Even 
if an automated system were in place to update rule-sets and block traffic, 
qualified personnel must be in place to monitor the systems and insure proper 
operation.  Properly configured co-lo equipment can indeed be maintained on 
the network side to further mitigate the issue, but this comes at a premium, 
if the ISP will offer the service at all. 

I say that we have the right to defend our systems from blatant worm attacks, 
and that we are within our rights to take measures to stop an attacking 
system from further infringing on our assets, consuming system resources and 
service availability, and from their ultimate attempt to compromise our 
systems.


Mission Statement:


Before talking about the specific technological ways in which a strike-back 
can be leveraged, I think it is important to state the goal of such a system. 
In this case, it is a fairly easy mission statement: “Stop the prorogation of 
global worms.”  To this degree, the term “strike-back” is not necessarily the 
best choice of word as it infers an aggressive stance; almost like retaliation
or some other offensive action.  Our stance is purely defensive, 
and to best illustrate that, I think we should begin using the term 
“neutralizing agent.”  That is exactly what we intend for this technology to 
do-- neutralize the attacking process.  

Note that our goal is to neutralize the *process* and not the system itself.  
In the methods that we will discuss in this paper, only the malicious process 
is stopped- the operation of the compromised host server is not affected, 
with the exception of specific caveats that we will discuss in detail 
shortly.  

We should also discuss what this technology should *not* be used for.  Immediately 
following the publication and demonstration of our neutralizing 
agent during Blackhat’s Las Vegas 2002 show, we read many posts and received 
many emails where people were concerned that any port scan, foreign ICMP 
packet, or SPAM email could qualify for and result in a “hack back” against 
the offending system.  This was never proposed, and indeed, is completely 
unacceptable. 

Additionally, people were concerned that user’s could “proxy” attacks through 
different machines in order for the presumed host to be “hacked backed,” and 
taken offline.  Others concocted multiple “spoof” situations where a malicious 
user would launch attacks against systems to create ping-pong style 
attack/counter-attack scenarios.  We will illustrate how these concerns are 
obviated. 




The Technology: Identifying the Attack

Given the way Code Red and Nimda work, our job is relatively easy here.  Both 
worms propagate over HTTP (though Nimda also uses other attack vectors) using 
TCP/IP, and both use un-patched vulnerabilities in Microsoft’s IIS server 
product. One should note that a default installation of Win2k server is 
immediately susceptible to both worms.  Since both worms attack over HTTP, a 
TCP 3-way handshake is required, which means the attacks can’t be spoofed 
(unless your network in compromised to the point that a MITM attack is 
possible, in which case you’ve got Much Bigger Problems).  The attack 
sequence of both worms, and each variation, can be definitively identified by 
its packet structure and attack pattern.

Basically, when we are attacked by a computer with Nimda or CR, we know what 
the attack is, and we know where it is coming from.  The data is definitive.  
This is not to say that all worms will require a 3-way handshake or even TCP 
for that matter.  For instance, if someone decided to write a worm based on 
the vulnerability discovered by David Litchfield involving MS SQL Server 
(listening on UDP 1434) it would be quite easy to do so, and to spoof the 
source address of the attacking box due to the nature of the vulnerability.  
In these cases, our technology would not be able to definitively identify the 
attacking box; we would therefore, quite simply, not deploy the 
neutralizing agent in a case such as this. 

However, since the most popular Internet TCP services require 3-way 
handshakes to work properly (HTTP, FTP, SMTP, POP3, etc) we can expect most 
future worms exploiting vulnerabilities in these services to be limited by 
this restriction (for the most part).  Again, this does not mean that they 
have to, but as we have seen with CR and Nimda, they probably will.  

[Addendum 09/23/2002] The Apache “Slapper” worm also falls into this 
category.  It too probes for vulnerable machines via a HTTP Get request to 
TCP port 80, at which point it will use the OpenSSL vulnerability to place 
code on the machine over TCP port 443.  And once infected, it announces its
presence to other peers over UDP ports such as 1978, 2002, and 4156.   Via 
the HTTP and subsequent SSL request, we can identify the true address of 
infected hosts.  In just a few days, over 30,000 systems were infected by his 
worm.  This is a perfect example of what our concerns are.  During a recent 
interview with a columnist from the IEEE industry magazine, I outlined a 
concern where a worm would exploit a vulnerability within a widely used 
product, and include within its payload remote DDoS capabilities.  I was, 
unfortunately, precisely correct in my prediction.  

3,000 units participating in a DDoS attack is enough cause substantial, 
sustained harm in an attack- Imagine what ten times that amount could do to 
the Internet root servers!  As predicted, worms are becoming more prevalent, 
and now hold the capacity for malicious use.  It will only get worse.  Had 
this technology been legally available at this time, we may have been able to 
thwart the spread of this worm. 

[Addendum 10/28/2002] Unfortunately, we were again correct in our fears.  
Just last week the root servers were indeed attacked in a massive DDoS attack 
against all 13 servers.  Though there has not been any conclusive evidence, 
many speculate that Slapper itself or other systems compromised by worms 
(that subsequently advertised their “own-ability” to the Internet) were used 
to remotely control the systems used in the attack.  Though our technology 
could not be used to counter such a DDoS attack (where spoofed SYN floods or 
other methods where the attacker could not be specifically identified), our 
technology could most certainly have mitigated Slapper’s propagation.  

This should be our wake-up call.  Would egress filtering and proper machine 
patching stop these threats?  Certainly.  Is this being done?  Obviously not. 
And there is no evidence that it will be addressed in the near future.  So 
much in the security world is theory and “what if’s.”  But here we have hard 
evidence that attackers are putting concentrated efforts into building tools 
that they can use to attack the core of the Internet; and they are using 
them.

The Technology: Neutralizing the Attack

The attacking worm process can be definitively identified, along with its 
host. Once we identify the worm, we know the attack vector the worm uses, and 
the mechanics of the worm itself. 

The neutralizing agent (NA from now on) software contains a database of known 
attack signatures and the corresponding vector information.  In addition, the 
NA database contains specific information on the code and process necessary 
to neutralize the attacking process.

The NA’s job is to wait for connection requests.  It basically mimics the 
server types required to host the attacking worm.  When a connection is 
requested, the NA accepts the connection with a response indicative of an 
affirmative response based on server type.  In the case of Nimda and CR, this 
results in replying to the attack requests with an HTTP 200, or a success 
code.  As the attack proceeds, the pattern is analyzed, and matched to an 
attack sequence in the NA database.  Upon attack confirmation, the NA loads 
the appropriate vector information to use in order to get the neutralizing 
code on the attacking system.

It is important to note that the NA will only attempt to use the same attack 
vector that the original worm does; the same vector that the worm used to 
initially infect the now-attacking box.  In this way, we can ensure that the 
attacking unit is indeed infectable by the original worm.

In the rare case that an advanced spoof attack is made, or in the case that a 
compromised (or malicious attack) is behind a proxy of some sort, checking 
the availability of the original vector acts as a double-check to ensure that 
we are attempting to neutralize the “real” attacking box.

During a demonstration of the NA, we were asked to address a hypothetical 
situation of having an attack sourced from a host behind a proxy, where the 
proxy was infectable, but not net infected, and how we could justify taking 
action against such a unit.  Our honest answer was that if the box is on the 
Internet, and is infectable, then it would already have been infected.  But, 
while an extremely unlikely scenario, it is theoretically possible that is 
was not.  If it actually played out that way, then we would neutralize a box 
before its inevitable infestation. 

At this point, we have definitively identified the attack, and have 
identified the vector in which we will use to load code on the attacking 
system.  It is now time to load that code, and to neutralize the attacking 
process.  Our current NA tool has two ways of doing this- a “production” tool 
would of course have a number of different methods to choose from for any 
particular worm for which it has been programmed.  The particular code to use 
against a given worm is the “neutralizing code,” or NC.  So to summarize, the 
NA (the neutralizing agent) is the overall tool that runs specific NC’s 
(neutralizing code) that are individually used against a given worm attack. 


The two NC’s in our demo tool differ in functionally, and both have ssociated 
down-sides. 

Method One (NC #1): Instantiate Named Mutex

NC #1 is particular to Nimda and CR II.  Upon analysis of the worm code, it 
was determined that Nimda and Code Red II both make use of a named Mutually 
Exclusive Object (called a “mutex”).  The nature of a “mutex” is that any 
named mutex object can only exist in memory in singularity- named mutexes 
must be unique.  i.e, If process 1 instantiates a mutex named “mut1”, no 
other process may set a handle to a mutex named “mut1.”   We use this to our 
advantage. 

Upon a Nimda attack, we use the worm vector (in this case, directory 
traversal and write permissions to the scripts directory) to place the NC on 
the attacking box.  We then call the NC in the URL. The NC escalates its 
privileges, and extracts a piece of executable code to the local drive 
(currently placed in the root directory for easy access). This tiny piece of 
code simply instantiates the exact same named mutexes that Nimda requires to 
load- that is all it does. 

Once the code is extracted, the NC then replaces Nimda’s load position in the 
boot process with that of our extracted mutex code.  The NC then removes 
itself from the hard drive (the main NC, not the extracted executable), and 
finally gracefully reboots the machine.  Obviously, the restart requirement 
of the machine is the downside of the mutex NC.  However, when the system 
comes back up, our code runs first, and prevents any Nimda process from 
executing: since we have already created an object of the same name that 
Nimda needs, it can’t create the object for its own use.  Even manual 
attempts to start Nimda will all fail.  All server services remain intact, 
and running.  Full system usability and service availability is restored.  
The drive contents are almost completely unaltered, and 99.9% of any 
subsequent forensic investigation can be performed without hindrance.  A 
console message is displayed giving detailed information on what occurred, 
and how to easily disable the mutex code.  In fact, simply closing the 
console application will remove the code from memory- Of course, the system 
would then begin attacking computers again as Nimda would then be able to 
execute. 

During this entire transaction, all connection traffic is logged.  Systems 
that have been neutralized, but that are subsequently put back on line (and 
attack us again) currently do not get re-neutralized.  This is just a 
setting, and further discussion should be had of its use. 

Method Two (NC #2) : IPSec Rule Injection

The concept of NC #2 is universally applicable to most attacking processes 
for multiple OS’s.  The analysis, identification and vector assignment works 
the same as with our first NC, except the process neutralization takes a 
different turn.  After determining the mounting vector, the NC is placed on 
the attacking system, and again called from the URL.  The NC escalates 
privileges, and injects an IPSec rule directly into process memory to block 
the outbound port that the worm needs to propagate.  The port block occurs 
immediately, and no reboot is needed- the attack simply stops.  The caveat 
here is that other services that require the outbound port for functionality 
will be affected.  However, in most server configurations (particularly HTTP 
vulnerabilities) proper operation does not require outbound access.  SMTP is 
an exception to this; in cases where the service itself requires outbound 
access, a method akin to NC #1 would be used. [Addendum: Some servers do 
indeed use outbound port 80 in order to download anti-virus updates and 
product updates.  However, in these cases, the system would not be
susceptible to the worm in the first place, so it is not much of an issue.]

Though our example here uses IPSec, which is available by default on Win2k 
and .Net servers, similar measures could be employed on other platforms such 
as IPChains. 

Post-Neutralization

Obviously, these examples do not actually address the worm infection 
itself—infected systems stay infected, and are still infectious- particularly 
in multiple-vector worms such as Nimda.  But our goal has been met:  the 
systems have stopped propagating the worm.  We could certainly have attempted 
to remove the worms, or even patch the original vector the worm used to 
infect the system, but we believe that is too much.  We are not without 
respect for the property of the owners of the infected systems- we just 
(rightfully) value our own property more.  To that degree, we want to cause 
the least possible alteration to the attacking system, and to leave it as 
close to its original configuration as possible.  We want to adhere not only 
to the concept of “reasonable force,” but to utilize “minimal force” where at 
all possible.  Our goal is not to “fix” everyone’s systems, and not to teach 
lax administrators a lesson.  Our goal is to stop the propagation of global 
worms. 

The Standards Body

In deploying this technology, some important questions must first be 
answered:  What is an attack?  What constitutes an attack where a NA should 
be employed?  What data and how much of it is required to positively identify 
the attacking process?  What is an acceptable neutralization method?  What 
happens if we make a mistake?

These questions should be answered by a standards body.  A consensus of 
security professionals, coding experts, government officials, and legal 
counsel should be formed to address these very important questions and to 
draft standards to help better reach intelligent conclusions of how, where, 
and when this technology should be used. 


Self-defense laws live in a similar environment.  There are situations and 
circumstances where the use of force in self-defense is justified, and there 
are those where it is not.  This is no different- if one chooses to act 
outside of the boundaries set by the standards body, then they are 
susceptible to the same consequences as any rouge attacker. 

One can also envision a credentialed third-party’s use of this technology.  
Managed Services and Monitoring Agents who have illustrated a specific level 
of expertise should also be able to deploy this technology on behalf of the 
clients they protect.  This is similar to the authority that private security 
guards have when acting to protect their employers. 


Conclusion

Internet worms are getting more and more complex, and more prevalent.  They 
exist for all of the most popular server platforms and services.  And as 
software continues to grow in stature of security, these worms will grow in 
their intelligence and destructive power.  The status quo is not working, and 
has no promise of working in the future.  We hope that this paper may 
contribute some alternate ideas as to a viable and workable solution to help 
us deal with this threat.

All comments and suggestions welcome.

Timothy M. Mullen

Many thanks to the following people who dedicated their time and efforts, and 
opinions to help with the project concept:

Ryan Russell (coding, worm analysis, testing)
JD Glaser (coding, escalation, sounding board) 
Jeremiah Grossman (NC #2 conceptualization, sounding board) 
Jennifer Granick (Legal opinions, sounding board) 
Scott Culp (sounding board)