Exploiting Weaknesses in Intrusion Detection Systems
By: spoonfork
"Misdirection."
"What the fuck are you talking about?"
"Misdirection. What the eyes see and the ears hear, the mind believes."
-- dialog between Gabriel and Stan, Swordfish
1.) Introduction
This article attempts to provide a high level overview of a class of attacks
that can be used to defeat the implementation of signature-based network intrusion
detection. The attacks that I will be describing are not new. In fact they have been
used widely in the wild. However, the attacks are not on the IDS itself. I have made
no attempts to shut down the IDS through denial of service or Stick attack. Nor will
I explain IDS evasion techniques. What I am describing is a class of attacks that are a
known as "squeling attacks", "blinding the operator" and misdirection. In other words,
the attacks are performed against the security analyst sitting in front of the monitoring
console. These attacks requires patience. We will be facing invicible opponents, and we
can never be sure of the outcome of our attacks. This is a game of psychological wits
between the attacker and the security analyst.
This article will be divided into several section. The first section discuss some organizational issues in IDS implementation. This, coupled with other weaknesses in the
IDS system are the assumptions that I will base my attacks on. Weaknesses in IDS, such as
high false positives, undetected false negative and spoofing issues will be covered next.
I will also explain the steps needed to mount the three attacks - squeling, blinding the
operator, and misdirection. Finally, I will provide the reader with available tools for
the attacks.
2.) Intrusion Detection Primer
Before we begin, I will briefly introduce the different types of IDS. They are host
IDS and network IDS. Host IDS (HIDS) detect anomalies or malicious behavior on a host, while
Network IDS (NIDS) capture and examines packets that travels across a network for signs
of intrusions.
Both can be drilled down to raw IDS and smart IDS. Raw IDS is usually
signature based IDS, in which it captures packet, looks for patterns
in the header or payload with matches signatures in the rules files, and logs the event. An example of a raw IDS would be
Snort. Raw IDS implements logic that understands the target protocol. For example, raw IDS will parse requests and
perform pattern matching based on known rules pertaining to the
protocol. An example would be RealSecure.
In this article, I will use Snort as an example. The signatures are taken directly
from the Snort distribution.
3.) Organizational and Operational Issues in IDS Implementation
There are a number of good ID software out there, both commercial and freeware. One can
use NFR, or the Open Source Snort. Snort is by no means an ordinary lightweight network
IDS. Its pattern matching engine is robust enough to detect over 1500 attack signatures.
Not only that, it can detect DoS, fragmentation, and perform well in detecting small
packets (
How many companies in Malaysia have incident handling policies? If your company does, I'll
be happy to hear from you. The fact is, not many companies have dedicated information
security departments. Attacks sometimes go unnoticed. Even if they were, none will be
reported. Attempts would probably be made to patch the vulnerable servers, and that is it.
Are they well documented? Probably not. Would you expect the system administrator
to come up with incident reporting and handling methodologies? In most cases, no.
Secondly, how many hours are spent on investigating false positives? IDS systems are great
and cool when they can trigger alarms. As these alarms increase, the need to investigate
them are paramount - you don't want to have alarms scrolling by the console and not
knowing which are real or fake. But, does management allocate time for system administators
to investigate "all this"? Worst of all, you don't want an untrained security analyst
to sigh in dismay "Why the fuck is this thing squealing all the time?".
Even if a company has a dedicated information security department, they lack the skills
in advanced intrusion analysis. This is at least true here in Malaysia, and this is one
of the assumptions that I will base the attacks on. Intrusion and signatures analysis
are deep subjects. A company needs to send their infosec staff for training, and this
is not enough. Infosec analysts must have ample experience in intrusion detection as well.
Even if intrusion detection systems are mature enough to distinguish false alarms and
deal with spoofing, the deep knowlegde of security analysts is still important.
Ask yourself, how many system admins that you've had are able to read tcpdump logs?
4.) Weaknesses With the IDS Itself
These are not weaknesses in IDS design or implementation. These are what I will call
neccessary evils in every IDS: false positives, false negatives, and spoofing. But why is
this so? Signature based IDS works in one mode - the binary mode. It either detects
malicious packet or not. In other words, decisions are based on "I saw an attack" and
"I didn't see any attack". Because of this, IDS suffers the from the problems explained
below.
4.1 False Positives
False positives are events that appear to be harmful, but are actually quite harmless. Tuning an IDS
to reduce false positives takes time, months maybe, and no IDS can achieve zero false
positives. In fact, out of the 100% of alerts that an IDS detects, more than 70% will be false positives.
In addition, a security analyst needs to understand the nature of network under his control to supress false positives.
Signature-based IDS like Snort, tend to produce high rates of false positives.
One reason is due to small signatures. For example, "phf" in a Snort rule will trigger an alert
when the string was actually "phfudge" or "muphf" etc in the HTTP headers, no matter whether
they are legitimate or not. Web companies that provides online calendar and scheduling
probably require stricter pattern matching rules if they plan to use Snort as an IDS.
4.2 False Negatives
False negatives, on the other hand, are events that go undetected by the IDS because
the IDS "did not see any match". Examples are hexadecimal encoding of HTTP requests:
/cgi-bin/test.cgi
is encoded to
/cg%69-b%69n/t%65st.cg%69
If there is no "cg%69-b%69n/t%65st.cg%69" in the rules file, the attack will pass by
unnoticed. Just as supressing false positives requires time and knowledge, so does detecting
false negatives. Alerts from perimeter devices needs to be examined as well. Besides
that, logs from perimeter devices (firewalls, routers) and application servers
(web servers, ftp servers) needs to be carefully analyzed too.
4.3 Spoofing Attacks
Last but not least is spoofing attacks. This is when the IDS cannot determine whether the source IP is valid.
Nor does it attempts to verify the source. But what happens if an attacker used IPs that
belongs to the network where the IDS resides? What if the security analyst, upon
seeing that the IDS triggers a lot of false positives from IPs in his netblock, set his IDS
to ignore local traffic? Well, the attacker obviously wins here, because we win by false positives, we win by false negatives, and we win by spoofing.
These three scenarios are not the only weaknesses in an IDS. There are others... For example, IDSes are vulnerable to
denial of service attacks, they cannot deal with encrypted traffic, and attacks can also be designed to
overload buffers that the IDS uses to track TCP/IP sessions.
5.) Methods
Strategy 6 - Making a feint in the East but attack in the West
(sheng dong ji xi)
"In any battle the element of surprise can provide an overwhelming advantage.
Even when face to face with an enemy, surprise can still be employed by
attacking where she least expects it. To do this you must create an expectation
in the enemy's mind through the use of a feint."
Strategy 8 - Secretly utilize the Chen Chang passage (Pretend to take one path
while sneaking down the other.)
"Attack the enemy with two convergent forces. The first is the direct attack,
one that is obvious and for which the enemy prepares his defense. The second
is the indirect, the attack sinister, that the enemy does not expect and which
causes her to divide his forces at the last minute leading to confusion and
disaster."
-- The 36 Strategies of the Ancient Chinese
5.1 Covert Attack/Blinding the Operator
Blinding the operator is meant to confuse or distract the operator. In its simplest form,
an attacker can make it appear as if he is attacking host A, when in fact he is
attacking host B. There are a number of ways to achieve this attack.
1. Produce a large number of attacks of varying source IPs and destination IPs, with
various signature patterns. With a flurry of attacks coming from everywhere and to
everywhere, the security analyst is forced to investigate the events one by one.
On average, it will take around 5 minutes for the Security Analyst to investigate
an event. Injecting signatures that the analyst has never seen before will also slow
down his analysis, and give you more time to launch your real attack. Over time, the
Security Analyst might ignore the real attack, or miss it altogether.
2. Make it appear that one source IP is using all possible means of attack. In this case,
the attacker's IP is not hidden, but his real attack is hidden. This can be done by
sending random packets that will trigger all alarms. A signature can also be triggered
by sending more than 2 or 3 packets, but at different times.
There is one weakness though: The security analyst can simply block the IP at the
border router or firewall thus stopping the attack in its tracks.
3. Make it appear that various source IPs are trying to exploit one or two vulnerabilities.
When so many IPs are attempting to exploit a vulnerability, it is highly likely that
the analyst will pay more attention to it. It is also possible that he will ignore other
attacks. Another thing you can do is varying the payload that will trigger the same
alert. When a security analyst sees a certain alert for a signature is triggered, but
the payloads differ, he will begin to wonder which of the attacks are more serious.
Thus he will pay more attention to the attack. An example is the following (made
popular by CodeRed and Nimda):
/scripts/..%c1%1c../winnt/system32/cmd.exe?/c+dir
/msadc/..%255c../..%255c../..%255c/..%255c../winnt/system32/cmd.exe?/c+dir
/scripts/..%c1%1c../winnt/system32/cmd.exe?/c+dir
/scripts/..%c0%2f../winnt/system32/cmd.exe?/c+dir
/scripts/root.exe?/c+dir
or even:
/scripts/..%c0%af../winnt/system32/cmd.exe?/c+copy+email.eml+c:inetpubwwwroothacked.txt
in order to make the attack appear successful. When the security analyst is consumed with
investigation and analysis, you can mount your real attack.
5.2 Misdirection and Falsifying
Falsifying and misdirection can take many forms. Some are already covered in the technique
above, but I would like to clarify it further.
1. Falsifying the source of the attack. An attacker can make it appear that host B
is attacking host A, when it is not the case. This attack can be achieved by
carefully crafting packets and picking out spoofed IPs. The security analyst will spend
more time investigating the validity of the source, rather than the attack itself. This
can be made more difficult if the source IP is carefully selected by the attacker.
2. Falsifying the attack destination. An attacker can make it appear that host B in the
security analyst's network is under attack, when that is not the case. When this happen,
the security analyst will spend more time investigating and monitoring the host under
attack. This is analogous to having a sick child, where the parents will spend more
time taking care of the child, and the rest are left to fend for themselves.
In fact the best thing to do is to purposely attack critical servers, such as DNS
and e-mail servers. This will prompt the security analyst to spend more time protecting
the servers, and give them a false sense of security as well.
5.3 Conditioning Attack
This type of attack requires an enormous amount of patience and time. Conditioning attack
exploits the weaknesses of an IDS by triggering a lot of false positives for a particular
signature. The attack works like this:
1. An attacker can generate false positive (F) on a target host from source A.
2. The security analyst sees that it is a false positive, or he may let the IDS send an alert
when F is encountered.
3. Over time, the security analyst will get used to F, and flag it as false positive, and
won't bother with the alert. He may route the alerts to other mechanism, or place the
alert on the low severity level, or may ignore it altogether.
4. The attacker then can use this to exploit a vulnerability.
A good example is the Nimda and CodeRed worms. The worms keep on attacking a network,
even if there are no IIS servers, or the IIS servers are patched. Over time, most security
analyst will just ignore Nimda/codeRed-like activities.
6.) Attack Preparations
To mount this attack, an attacker must have the appropriate preparation. The details are
explained below.
6.1 Network identification and fingerprinting.
This is by far the most common preambles to an attack. Careful attackers however, will
preform reconnaisance in the stealthiest manner possible. One can also choose to use
available tools (such as Nmap) to identify hosts and open ports. Or one can also use
available services such as Netcraft. The point is, the more you know about the network,
the more options you'll have as how to attack it. It is also a fact that given the
large amount of scans that are performed everyday, security analysts tend to overlook
scanning activities. They will be more interested in attack activities. Trained and
experienced security analysts, however, will look beyond scanning logs. They will look
for patterns of scanning activities.
However, I have this general rule that I use when scanning a network.
1. Do not use any of -sX, -sS, -sF or -sX in Nmap
2. Use only -sT
3. For host fingerprinting, use Xprobe, instead of -O in Nmap.
4. Using a simple telnet target 80 will be enough to reveal the webserver.
5. Don't do ping sweeps
6. Don't ping broadcast address
7. Use APNIC, ARIN, etc to find IP blocks
8. Use hping and send RST packets to find live hosts that are behind firewall.
6.2 Identify signatures for packet creation.
Identifying signatures for packet creation requires a lot of experimentation. Besides
this, an attacker needs to be familiar with intrusion signatures. However,
these methods apply:
1. Look for small signatures, e.g "phf". This will trigger alerts if a HTTP payload
contains "fugdephf", "dephfunc", etc. Another example is"cmd.exe"
Both Snort rules and signatures look like this:
alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS 80 (msg:"WEB-CGI phf access";
flags: A+; uricontent:"/phf"; nocase; reference:bugtraq,629;
reference:arachnids,128; reference:cve,CVE-1999-0067;
classtype:attempted-recon; sid:886; rev:3;)
alert tcp $EXTERNAL_NET any -> $HTTP_SERVERS 80 (msg:"WEB-IIS cmd.exe access";
flags: A+; content:"cmd.exe"; nocase; classtype:web-application-attack;
sid:1002; rev:2;)
2. Use signatures that are usually triggered by content providers. These are mostly
ICMP signatures. An example is the "ICMP ping speedera".
alert icmp $EXTERNAL_NET any -> $HOME_NET any (msg:"ICMP PING speedera";
content: "|3839 3a3b 3c3d 3e3f|"; depth: 100; itype: 8; sid:480;
classtype:misc-activity; rev:2;)
Other types of ICMP signatures that area classified as "misc-activity" can also be
used.
3. Use signatures in the attack response rules. The attack responses signatures are
interesting, because once detected by the IDS, they usually indicate a successful
attack. However, false positives can be easily generated. An example is the
"ATTACK RESPONSES command error":
alert tcp $HTTP_SERVERS 80 -> $EXTERNAL_NET any (msg:"ATTACK RESPONSES
command error"; content:"Bad command or filename"; nocase; flags:A+;
classtype:bad-unknown; sid:495; rev:2;)
An attacker can create a bogus web page that contains the string "Bad command or
filename". These web page can be created to mimic a web-based technical mailing list
archive. Websites that hosts mailing list archives are a good candidates for this
kind of falsifying attack. They contain technical discussion, and strings such as
"bad command", "file not found", and "make error" are common.
4. Use signatures that are triggered by legitimate client software, such as
desktop email clients and Windows SSH clients. Some email clients can trigger
a "SMTP RCPT TO buffer overflow". This occurs when the IDS misinterpret the
packet, when in fact it is legitimate. The SSH Secure Shell client for Windows
triggers "EXPLOIT ssh CRC32 buffer overflow filler" when connecting to a SSH
server. All these are in most cases legitimate traffic.
5. Use signatures that are produced by load balancing servers.
These signatures, if triggered properly, are meant to "intrigue" the security
analyst. This is because the signatures are uncommon. They are quite difficult to
analyze as well. These types of signatures can be used as part of an armor for
conditioning attack.
These are only some of the examples that I can give. Experience and better understanding
of intrusion signature analysis will help the attacker to choose signatures for the
packet creation.
5.3 Select IPs to be used for spoofing.
Selecting IPs for use in spoofing can be an art in itself. Choosing IPs is like
selecting a restaurant for your dinner date. As a general rule, these are what I
always use:
1. IPs that belong to content providers (e.g akamai)
2. IPs that belong to public remailers
3. IPs that belong to anonymous proxies
4. IPs that belong to free shell providers
5. IPs that belong to universities
6. IPs that is part of the target network
7. Use the cyber cafe near you
When you are choosing IPs that belong to the target network, you must be familiar
with the network first. This includes knowing what kind of services are running,
and who the regular clients are. The results from Nmap TCP connect() scan and
Xprobe fingerprinting will provide you with a clue on the relationships between
hosts on the network.
Last but not least, if you don't want to be bothered picking out IPs, just go to
your favorite cyber cafe and mount your attack there.
Now, why do you want to use live IPs? The point is, when the security analyst detects
an attack from a certain IP, he will contact the owner of the IP. This way, you are
buying time away from the security analyst - he won't be able to do correlations
of other attacks. The problem will get more complicated for him if he sees two IPs
that mount the same attack, but the payloads are different. In this case, the
security analyst will really have to sit down and investigate the attacks further.
Intrusion analysis, as I've pointed out, is time consuming and requires deep
knowledge. If your spoofed packets are able to confuse, or better yet, "intrigue"
the analyst, you gain more time to mount your real attack. When you have all the above ready, it is time that you start crafting packets. Packet
creation is beyond the scope of this article, but there are a lot of tools that you can
use, for example libnet, Nemesis, Net::RawIP and SOCK_RAW.
When you have your tools ready, it is time to mount your attack. However, another issue
is still at hand. How long are we going to mount the false attacks? A quick answer is:
as long as it takes.
Covert and misdirection can be mounted as long as you want, with a little bit of the
real attack thrown in. If your real attack succeed, then the prize is yours.
Conditioning attacks however, requires more time. Just as it takes time to teach a dog
new tricks, so does conditioning. You may inject false packets for days, weeks, or
even months, with varying frequencies and durations per attack, and varying source and
destination.
7.) Summary
Organizational and operational issues are yet to be sorted out in IDS implementations.
Corporations lack the necessary resources to handle incidents and maintenance of an IDS is
still a big issue. Further to this, not many system administrators or network administrators are
capable of interpreting network traffic. Until data gathered from IDS alerts can be
automatically analyzed and interpreted by an adaptive alert presentation system, security
analysts have to rely on experience and intuition when investigating intrusion attempts.
Signature-based IDS also suffer from high false positives, and spoofing attacks can
render the IDS useless as more investigative work needs to be done by the security
analysts.
With these issues in mind, I have introduced a class of attacks that if
properly executed, can pass through the ID system and the security analyst undetected.
I am also trying to emphasize that ID systems cannot rely on an "I saw an attack, I
didn't see an attack" approach. Rather, IDSes should see each attack as a "problem", and
attempt to solve the problem using conventional problem solving methods. This
capability, however, is still a long way off.
8.) Tools
1. Snort [written by Martin Roesch] http://www.snort.org
2. Libnet [written by Mike Schiffman] http://www.packetfactory.net
3. SNOT [written by sniph] http://www.sec33/sniph
4. Stick [written by Coretez Giovanni] http://www.ini2.net/mel/tools/stick.tar.gz
5. Net::RawIP [written by ] http://search.cpan.org/search?mode=module&query=Net::RawIP
6. Nemesis [written by ] http://www.packetninja.net/nemesis
7. Nmap [written by Fyodor] http://www.insecure.org/nmap
8. Xprobe [written by Ofir Arkin & Fyodor Yorachkin] http://www.sys-security.org
9.) References
1. Roesch, Martin. Writing Snort Rules, Snort Documentation
http://www.snort.org
2. Giovanni, C. Fun With Packets: Designing a Stick
http://www.eurocompton.net/stick
3. Rain Forest Puppy. A Look at Whisker's Anti-IDS Tactics
http://www.wiretrip.net/rfp
4. Howard, Steve. Stick and Network Signature Based Intrusion Detection
http://www.sans.org/infosecFAQ/threats/stick.htm
5. Hugh, John et al. Intrusion Detection: Implementation and Operational Issues.
http://www.stsc.hill.af.mil/crosstalk/2001/jan/mchugh.asp
6. Patton, Samuel et al. An Achilles' Heel in Signature-Based IDS:
Squeling False Positive in SNORT. Preceeding of the 4th International Symposium
Recent Advances in Intrusion Detection(RAID), University of California-Davis, 2001.
7. spoonfork. An analysis of Nmap and Xprobe Fingerprinting Techniques.
http://www.ini2.net/mel/snort_trace/os_print.html
8. spoonfork. Defeating the Weary Security Analyst.
http://www.ini2.net/mel/p/ids_nimda.php
9. CH Wee, LL Lan. 36 Strategies of the Ancient Chinese: Adapting Ancient Chinese
Wisdom to the Business World. Addison Wesley. 1998.
10. Swordfish. VCDs still available at Section 17, SS2 or near your local mamak
stall, RM5.00 apiece.
1.) Old Posts don't die -- they get archived - Dinesh Nair
2.) Flawed Internal Setups By Example - presto
3.) An Interview with the Father of the Internet - L33tdawg
4.) Exploiting Weaknesses In Intrusion Detection Systems - spoonfork
5.) Snort for idiots (and cheap people like me) - presto
6.) A short commentary on script kiddies - Anateus
7.) SOTHA Returns! - madsaxon
8.) Cold Fusion Server Security - madirish
