1.

Intro

a)

   

Fingerprints

b)

   

False Positives

c)

   

The Scanner

2.

OK, so what is STICK

a)

   

The Big Picture

b)

   

Zooming in on the problem

c)

   

Bandwidth

d)

   

Will this affect my firewall?

e)

   

How hackers will use this tool

f)

   

Is there a remedy?

3.

My test using the STICK

a)

   

Packet captures

b)

   

Basic Statistics

c)

   

The readme file

4.

The Verdict

5.

References

Intro
Coretez Giovanni wrote a tool he  entitled "Stick".   The purpose of this tool was to stress test Intrusion  Detection Systems (IDS) in an effort to publicize the deficiencies of signature  based recognition within the software market.

This problem is not unique to the IDS field.   In fact I first discovered this  problem while dealing with antivirus software.   During the testing of different  vendors products against a myriad of viruses from subtly modified macro viruses  to worms to old boot sector virii I discovered the problems inherent in  signature based scanning.   It should only take one false positive virus incident  on a large scale to start the wheels in your head turn and prompt the desire to  figure out why and how the antivirus software really works.   Some antivirus  software company is going to quickly jump up and take this opportunity to try  and sell their product stating "Haven't you ever heard of Heuristic scanning?".    Yes I have, but this paper is not about heuristic algorithms.   We'll save that  discussion for later.   For now we will continue our discussion with  fingerprints.

Fingerprints
As the name implies, it is a  tangible object used to identify something.   I can discuss fingerprints  generically as they apply to data and narrow the scope shortly.   A fingerprint  in the context of this document is a string of code that matches another string  of code contained in a   database (a list somewhere will suffice as a database).    This fingerprint is usually quite small for performance reasons. If the strings  match, the particular object being compared is generally flagged in some manner,  either as reject, deny, ignore, forward, page the Primeminister or something to  this effect.   This can cause lots of problems.  

False Positives
The term false positive was  used earlier.   This is like the "Sheep that cried wolf".   It is the bane of  almost any service provider from firemen to computer security professionals.    Studies have been done on the negative effects of false positives in relation to  moral and responsiveness.   I am going by my memory but I remember something like  five false call-ins or pages and a system administrator will drop their  responsiveness levels by approximately 30%.   Don't dwell on the numbers, just  remember that this is a factor that while not readily seen is a silent  killer.

The Scanner
IDS's use fingerprints or  "signatures" to compare strings of network packets to a database of known  signatures.   This is the duty of the scanner.   If an packet is picked up by an  scanner and it matches one of these signatures the IDS is designed to do  something.   There are numerous discussions on what should be done and under what  circumstances.  

Denial of Service
The big drive behind the fervor  of these discussions is something called a "Denial of Service" attack or DoS.   I  won't get into it now suffice to point out probably the key to these  discussions.   If someone unwanted is trying to break into your network, you  could block or shun them when you detect it.   That sounds like a good plan until  you consider that perhaps it is someone trying to deny service to your site by  one of your business partners ($$$ rule).   If you deny the impostor who is  pretending to be your trusted business partner, you will be shooting yourself in  the buttocks and the attacker gets what they wanted.   Distributed Denial of  Service or DDoS attacks were much the discussion in the spring of 2000 when  numerous tools were written to aid in the automated attack and compromise of  servers for the use of turning them into zombies that would flood targets as  directed by an agent.   The agent was in turn controlled usually by a master.    One step removed from this master usually put you in direct contact with a  hacker using a compromised dial-up account login and password or some teenager  lurking on IRC channels just waiting to show the world how great their hacking  prowess is.

OK, so what is  STICK

The big  picture
This is a tool written under the pretense that people need to be  shown how infantile signature based scanning and intrusion detection is.   That  IDS's in their current state offer a false sense of security.   There are two  twists to this one.   Sure the author of Stick has a point and if he had not  brought it to the worlds attention, some one else surely would have eventually.    The problem is that it is destructive and now released to the public poses a  security risk that will affect magnitudes of people that would have otherwise  been oblivious to this arcane techno mumbo jumbo stuff.   It's kind of like  saying I released a deadly virus on the world to show you all how ill prepared  you are.   I give this reason a big "gee thanks" response.   Given the author  released the source code to vendors prior to its release to the public (either  through the author directly or a leak somewhere in the codes path), I don't  believe this is a problem that can be solved over night.

Zooming in on the  problem

Stick sends packets matching these hacker  signatures at a target with the intent of causing the signatures to trigger  alarms and events.   This is known as event driven response and I compare it to  corrective maintenance vice preventative maintenance.   What really happens is  the IDS will become consumed with generating alerts and logging the packets to  disk.   Depending on how lean the scanning engine of the IDS you are using is and  the size of it's signature database, the system will reach it's processing limit  and the scanning process will crash as it starves to death for resources, or it  will continue to process incoming packets at a crippled rate.   This is affected  by numerous items.

Bandwidth
The  smaller the data connection (pipe), the better position you are in to deal with  Stick.   This means that you will not drop packets or cease logging and your IDS  will continue to chirp, generating alarm after alarm for someone to try and  filter through.   It does mean that your pipe will become clogged with this  traffic and cause DoS conditions on you, but you will catch the golden packets  that the IDS is designed for when the time comes given that the IDS has a  signature for those specific packets.

Will this affect my  firewall?
You bet it will.   Your weakest link will be the collapsing  link.   Firewalls inspect packets too.   Application proxies will take the  greatest hit.   Your firewall may not handle the stress very well.

How hackers will use  this tool
This tool will be incorporated with other attacks, probably  using less sophisticated attacks to try and evade IDS's.   Generally speaking the  term given to hackers who will use this script is "Script Kiddie".   They will  find this tool, compile it for their operating system, and start using it.   It  generally takes little talent to do this and many of these Script Kiddies will  never even look at the source code or understand how it works.   They will  combine this attack with other scripts they have gathered and take down random  targets that are behind in having security patches applied.   The sophisticated  hacker will most likely not use this tool because it will set off blaring sirens  and flashing lights all over the targets organization.   Subtle probing and  undetected intrusion is the preference of those who have a real target in mind.    These attackers are already a needle in the haystack to find and would only use  a tool like Stick to create a diversion or lower moral of Intrusion analysts in  an attempt to create a more desirable psychological atmosphere in which to  attack.   Social engineering is a very large factor in gaining unauthorized  access to systems.   I cannot count how many times I have had conversations with  major ISP's and information has been passed on that would have enabled a  malicious user to walk right into the organization.   Don't take this previous  paragraph lightly.   Stick is still a very real tool that will be used for ill  intent all over the place and will create a great deal of stress testing for  vendors, security analysts, bandwidth, and patience.

Is there a  remedy?
There are some solutions to this problem, however none of them by  themselves is a silver bullet.   None are particularly easy to implement either.    A combination of all of these recommendations should mitigate the threat of  stick.

1.Send this list of recommendations to your  boss so that he/she understands the implications and authorizes the overtime or  signs off on the risk and you save your hinie for another day when the axe falls  in the aftermath of an attack.

2.Keep your Demilitarized Zone and Internet  accessible systems up to date with security patches. If you do get hit with a  stick, your armoured systems will be protected.

3.Limit the signatures you process or log on  your IDS to only those that you know you are vulnerable to.   If you get hit with  a stick, you will not have nearly as many logs to filter through, and will log  any packets that may have successfully affected your systems.

4.Modify your stateless filters (routers) ACL's  to drop much of the unnecessary traffic.   These devices are much much faster at  performing this action than a stateful filter or application proxy. (Firewall  talk).

5.Contact your IDS vendor and put pressure on  them to support their product and put emphasis on anomaly and heuristic  detection.

6.Write an Request for Comments (RFC) dealing  with router sanity checking and flagging of packets that arrive within X hops of  an original departure TTL at router that would be impossible to be at given X  hops (kinda like Split Horizon), while enroute to a destination.   Have a  response sent back to the originator and/or destination saying you are under  attack by impossible packets or something like this.

7.Configure your border routers to drop insane  packets (packets that originate your internal interface with a source address  that you do not own) and investigate the offenders by tracking them through your  internal routers.   You should have control over these!   If you don't your in a  world of hurt.   You will often find a backdoor into your network through laptops  etc. so don't discount what you figure is impossible when it happens upon you.    Find the offending MAC and investigate the machine. supports, as well as a  whitepaper from CISCO on or  CEF.

8.Track offenders through the co-operation of  other Service Providers using

9.Obtain a copy of Stick and prepare yourself  prior to someone else hitting you with a stick.   Induce some pain on yourself.    Then you will be prepared for what will happen when it really does  happen.

My Test of the  stick

The Stick is real and works.   I have decided  not to post this tool for the ethical reasons I hinted at previously in this  article.

Packet Captures
Below are a few packet  captures to give you a sample of what SNORT ver 1.6.3 picks up.

Initializing  Network Interface...

Decoding  Ethernet on interface eth0

-*>  Snort! <*-

Version  1.6

By  Martin Roesch (roesch@clark.net, www.clark.net/~roesch)

03/21-19:10:18.731141  208.10.49.55:2140 -> WWW.VICTIM.COM:0

UDP  TTL:235 TOS:0x0 ID:41083

Len:  0

00  00 00 00 00 10 00 00 00 00 00 00 00 00 00 00   ................

00  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................

48  6F 73 74 00 00 00 00 00 00 00 00 00 00 00 00   Host............

00  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................

00  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................

00  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................

00  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................

00  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................

00  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................

00  00 00 00 00 00 00 00 95 91 96 41                           ...........A

  

03/21-19:10:18.734184  156.134.123.56:21 -> WWW.VICTIM.COM:5400

TCP  TTL:240 TOS:0x0 ID:41632

*****PAU  Seq: 0x42F440     Ack: 0xXXXXXXXX     Win: 0x6271

00  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................

00  00 00 00 55 53 45 52 77 30 72 6D 0D 0A 00 00   ....USERw0rm....

00  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................

00  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................

00  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................

00  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................

00  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................

00  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................

00  00 00 00 00 00 00 00 00 00 00 00 95 91 96 41   ...............A

  

03/21-19:10:18.734579  16.253.209.50:46181 -> WWW.VICTIM.COM:19507

TCP  TTL:250 TOS:0x0 ID:50756

*****PA*  Seq: 0x4785CEE8     Ack: 0xXXXXXXXX     Win: 0x840F

00  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................

00  00 00 00 77 65 62 70 6C 75 73 2E 63 67 69 3F   ....webplus.cgi?

53  63 72 69 70 74 3D 2F 77 65 62 70 6C 75 73 2F   Script=/webplus/

77  65 62 70 69 6E 67 2F 77 65 62 70 69 6E 67 2E   webping/webping.

77  6D 6C 00 00 00 00 00 00 00 00 00 00 00 00 00   wml.............

00  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................

00  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................

00  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................

00  00 00 00 00 00 00 00 00 00 00 00 95 91 96 41   ...............A

  

03/21-19:10:18.734993  7.179.199.50:23972 -> WWW.VICTIM.COM:38883

TCP  TTL:242 TOS:0x0 ID:63761

*****PAU  Seq: 0xB62E9EE     Ack: 0xXXXXXXXX     Win: 0xB938

00  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................

00  00 00 00 52 46 42 20 30 30 33 2E 30 30 33 00   ....RFB 003.003.

00  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................

00  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................

00  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................

00  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................

00  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................

00  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................

00  00 00 00 00 00 00 00 00 00 00 00 95 91 96 41   ...............A

  

03/21-19:10:18.735296  198.127.6.38:8566 -> WWW.VICTIM.COM:0

UDP  TTL:222 TOS:0x0 ID:61938

Len:  0

XX  XX XX XX 50 38 B9 38 1E E9 00 00 00 00 00 00   .p..P8.8........

00  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................

01  03 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................

00  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................

00  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................

00  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................

00  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................

00  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................

00  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00   ................

00  00 00 00 00 00 00 00 95 91 96 41                           ...........A

Basic Statistics
Here are some more  statistics on the tool.

1.The victim machine was running Slackware 7.0  on a 550MHz AMD with 160MB RAM.
2.The attacker machine was running Slackware  7.1 on a 700MHz PentIII with 320MB RAM.
3.Both machines are operating as  servers (low end).
4.Victim machine logged 69503903 bytes within 60 seconds  on a 100MBit ethernet connection.
5.Victim machine logged 99842 packets in 60  seconds.
6.Attacker sent 156600 packets in 60 seconds.
7.The victim  dropped approximately 36.24% of the packets.

The code is volatile enough that it may be modified easily to produce  different fingerprints and thus is kind of useless, besides, we just talked  about fingerprints and a few of the downfalls of using them.

The readme file
I have included a portion of the  readme file to give those reading this some deeper insight into what the author  was thinking.

THIS  SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR
IMPLIED WARRANTIES,  INCLUDING. WITHOUT LIMITATION, THE IMPLIED
WARRANTIES OF MERCHANTABLILITY AND  FITNESS FOR A PARTICULAR PURPOSE.

THIS  SOFTWARE IS FOR THE ANALYSIS OF INTRUSION DETECTION.   IT
IS TO BE USED IN A  CONTROLLED ENVIRONMENT.  

Now...

This is really crappy code.   I am  not a C coder or pretend to be
one.   This code can be used for many  things:

     o   Stress testing
                 of processor or alarm storage  for example.
     o   Detemination of IDS' capability to validate state
     o    Firewall Rule testing
     o   IDS rule testing

This program should not  be connected to the Internet when running.
This code was originally written  over a year ago.   The state of IDS
has not really changed since then.
This is really crappy code,
it was written to work only on a Linux x86  platform, though
with proper libraries it runs on any *NIX little endian  platform.
Big endian would be an easy change, but I'll probably just  use
libnet on a re-write if I ever get the energy.
To  create:

<<<OMITTED AS IT CONTAINS BAD  JIU-JIU>>>

This is really crappy code, I don't really know C  very well but
I use to be an Ada programmer.   Ada is pretty dead ...
In a  month, all IDS vendors will be saying, "Oh, 'stick' doesn't
affect out  product."
I hope their right.

Coretez

Verdict
Stick is real and a threat.   I tested  this tool against a few other IDS's too and was not very happy with their  performance. It will be used in the wild and will be modified so that real  attacks may be injected into the stream from the same host with little effort.    This will become a tool used predominantly by Script Kiddies but will also find  a niche with professional hackers as well.   Take time prior to its wide spread  use to beef up your security posture.

Jamie French
GCIA

References:

http://www.eurocompton.net/stick/
ftp://ftp.isi.edu/in-notes/rfc2827.txt
http://www.cymru.com/~robt/Docs/Articles/tracking-spoofed.html


Non-Active Sitemap

Copyright © 2000-2014 Whitehats.ca
Contact Information 519.221.9132 : Web Contact webmaster@whitehats.ca