den4
先輩
- 15 Nov 2002
- 1,799
- 63
- 58
taken from cryptogram:
As the US gears up for internet surveillance, I think this topic is one that everybody should consider....
Counterattack
This must be an idea whose time has come, because I'm seeing it talked
about everywhere. The entertainment industry floated a bill that would
give it the ability to break into other people's computers if they are
suspected of copyright violation. Several articles have been written
on the notion of automated law enforcement, where both governments and
private companies use computers to automatically find and target
suspected criminals. And finally, Tim Mullen and other security
researchers start talking about "strike back," where the victim of a
computer assault automatically attacks back at the perpetrator.
The common theme here is vigilantism: citizens and companies taking the
law into their own hands and going after their assailants. Viscerally,
it's an appealing idea. But it's a horrible one, and one that society
after society has eschewed.
Our society does not give us the right of revenge, and wouldn't work
very well if it did. Our laws give us the right to justice, in either
the criminal or civil context. Justice is all we can expect if we want
to enjoy our constitutional freedoms, personal safety, and an orderly
society.
Anyone accused of a crime deserves a fair trial. He deserves the right
to defend himself, the right to face his accused, the right to an
attorney, and the right to be held innocent until proven guilty.
Vigilantism flies in the face of these rights. It punishes people
before they have been found guilty. Angry mobs lynching someone
suspected of murder is wrong, even if that person is actually
guilty. The MPAA disabling someone's computer because he's suspected
of copying a movie is wrong, even if the movie was copied. Revenge is
a basic human emotion, but revenge only becomes justice if carried out
by the State.
And the State has more motivation to be fair. The RIAA sent a
cease-and-desist letter to an ISP asking them to remove certain files
that were the copyrighted works of George Harrison. One of the files:
"Portrait of mrs. harrison Williams 1943.jpg." The RIAA simply Googled
for the string "harrison" and went after everyone who turned
up. Vigilantism is wrong because the vigilante could be wrong. The
goal of a State legal system is justice; the goal of the RIAA was
expediency.
Systems of strike back are much the same. The idea is that if a
computer is attacking you -- sending you viruses, acting as a DDoS
zombie, etc. -- you might be able to forcibly shut that computer down
or remotely install a patch. Again, a nice idea in theory but one
that's legally and morally wrong.
Imagine you're a homeowner, and your neighbor has some kind of device
on the outside of his house that makes noise. A lot of noise. All day
and all night. Enough noise that any reasonable person would claim it
to be a public nuisance. Even so, it is not legal for you to take
matters into your own hand and stop the noise.
Destroying property is not a recognized remedy for stopping a nuisance,
even if it is causing you real harm. Your remedies are to: 1) call the
police and ask them to turn it off, break it, or insist that the
neighbor turn it off; or 2) sue the neighbor and ask the court to
enjoin him from using that device unless it is repaired properly, and
to award you damages for your aggravation. Vigilante justice is simply
not an option, no matter how right you believe your cause to be.
This is law, not technology, so there are all sorts of shades of gray
to this issue. The interests at stake in the original attack, the
nature of the property, liberty or personal safety taken away by the
counterattack, the risk of being wrong, and the availability and
effectiveness of other measures are all factors that go into the
assessment of whether something is morally or legally right. The RIAA
bill is at one extreme because copyright is a limited property
interest, and there is a great risk of wrongful deprivation of use of
the computer, and of the user's privacy and security. A strikeback
that disables a dangerous Internet worm is less extreme. Clearly this
is something that the courts will have to sort out.
Way back in 1789, the Declaration of the Rights of Man and of the
Citizen said that: "No person shall be accused, arrested, or imprisoned
except in the cases and according to the forms prescribed by law. Any
one soliciting, transmitting, executing, or causing to be executed any
arbitrary order shall be punished." And also: "As all persons are held
innocent until they shall have been declared guilty, if arrest shall be
deemed indispensable, all harshness not essential to the securing of
the prisoner s person shall be severely repressed by law."
Neither the interests of sysadmins on the Internet, nor the interests
of companies like Disney, should be allowed to trump these rights.
Automated law enforcement:
Stop, in the Name of 'Bots | Fox News
Mullen's essay:
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)
Berman legislation:
counterpane.com/crypto-gram-0208.html#5 :emoji_astonished: :emoji_astonished:
As the US gears up for internet surveillance, I think this topic is one that everybody should consider....
Counterattack
This must be an idea whose time has come, because I'm seeing it talked
about everywhere. The entertainment industry floated a bill that would
give it the ability to break into other people's computers if they are
suspected of copyright violation. Several articles have been written
on the notion of automated law enforcement, where both governments and
private companies use computers to automatically find and target
suspected criminals. And finally, Tim Mullen and other security
researchers start talking about "strike back," where the victim of a
computer assault automatically attacks back at the perpetrator.
The common theme here is vigilantism: citizens and companies taking the
law into their own hands and going after their assailants. Viscerally,
it's an appealing idea. But it's a horrible one, and one that society
after society has eschewed.
Our society does not give us the right of revenge, and wouldn't work
very well if it did. Our laws give us the right to justice, in either
the criminal or civil context. Justice is all we can expect if we want
to enjoy our constitutional freedoms, personal safety, and an orderly
society.
Anyone accused of a crime deserves a fair trial. He deserves the right
to defend himself, the right to face his accused, the right to an
attorney, and the right to be held innocent until proven guilty.
Vigilantism flies in the face of these rights. It punishes people
before they have been found guilty. Angry mobs lynching someone
suspected of murder is wrong, even if that person is actually
guilty. The MPAA disabling someone's computer because he's suspected
of copying a movie is wrong, even if the movie was copied. Revenge is
a basic human emotion, but revenge only becomes justice if carried out
by the State.
And the State has more motivation to be fair. The RIAA sent a
cease-and-desist letter to an ISP asking them to remove certain files
that were the copyrighted works of George Harrison. One of the files:
"Portrait of mrs. harrison Williams 1943.jpg." The RIAA simply Googled
for the string "harrison" and went after everyone who turned
up. Vigilantism is wrong because the vigilante could be wrong. The
goal of a State legal system is justice; the goal of the RIAA was
expediency.
Systems of strike back are much the same. The idea is that if a
computer is attacking you -- sending you viruses, acting as a DDoS
zombie, etc. -- you might be able to forcibly shut that computer down
or remotely install a patch. Again, a nice idea in theory but one
that's legally and morally wrong.
Imagine you're a homeowner, and your neighbor has some kind of device
on the outside of his house that makes noise. A lot of noise. All day
and all night. Enough noise that any reasonable person would claim it
to be a public nuisance. Even so, it is not legal for you to take
matters into your own hand and stop the noise.
Destroying property is not a recognized remedy for stopping a nuisance,
even if it is causing you real harm. Your remedies are to: 1) call the
police and ask them to turn it off, break it, or insist that the
neighbor turn it off; or 2) sue the neighbor and ask the court to
enjoin him from using that device unless it is repaired properly, and
to award you damages for your aggravation. Vigilante justice is simply
not an option, no matter how right you believe your cause to be.
This is law, not technology, so there are all sorts of shades of gray
to this issue. The interests at stake in the original attack, the
nature of the property, liberty or personal safety taken away by the
counterattack, the risk of being wrong, and the availability and
effectiveness of other measures are all factors that go into the
assessment of whether something is morally or legally right. The RIAA
bill is at one extreme because copyright is a limited property
interest, and there is a great risk of wrongful deprivation of use of
the computer, and of the user's privacy and security. A strikeback
that disables a dangerous Internet worm is less extreme. Clearly this
is something that the courts will have to sort out.
Way back in 1789, the Declaration of the Rights of Man and of the
Citizen said that: "No person shall be accused, arrested, or imprisoned
except in the cases and according to the forms prescribed by law. Any
one soliciting, transmitting, executing, or causing to be executed any
arbitrary order shall be punished." And also: "As all persons are held
innocent until they shall have been declared guilty, if arrest shall be
deemed indispensable, all harshness not essential to the securing of
the prisoner s person shall be severely repressed by law."
Neither the interests of sysadmins on the Internet, nor the interests
of companies like Disney, should be allowed to trump these rights.
Automated law enforcement:
Stop, in the Name of 'Bots | Fox News
Mullen's essay:
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)
Berman legislation:
counterpane.com/crypto-gram-0208.html#5 :emoji_astonished: :emoji_astonished: