HiR10			Flying Below The Radar			By: Axon
            An introduction to not setting off IDS Alarms

	So, you've done your hacking homework, and you're seeing that it's
getting harder and harder to find a good place to poke around and play,
because everyone and their CEO has hopped on the "Intrusion Detection
System (IDS)" Bandwagon.  These systems look for odd activity, or
"anomalies", as they are often called.  "IDS"'s have been around for a
dreadfully long time, it's just that they were never categorized as such
until recently (Just like there have been chevy blazers for a long time,
but the category "Sport Utility Vehicle" didn't exist until very recently,
so they just called it a truck until some better title came along).

	Intrusion Detection Systems go back to the days of portscan
loggers, and scripts that administrators would set up to look at system
logs for remote and local anomalies.  This could be anything from
excessive amounts of incorrect password guesses using "su", to having
pre-compiled software in their directories, or set-uid binaries laying
around where they shouldn't be.  Basically, any tool that looks for
bizarre patterns in system useage or network traffic can be called an IDS.
At this time, I will only be discussing the type that watches for network
traffic.

	Intrusion Detection Systems may or may not mean that there is a
firewall in place.  Some system administrators rely only on IDS methods,
whereas the smarter portion of them still use some method of a firewall.
If a firewall is in place, the IDS also may communicate with the firewall,
telling the firewall the attacker's IP Address and letting the firewall
take care of business.  (Please note that I'm speaking of "firewall" as
a concept, not a piece of hardware.  It's fully possible that IDS software
runs on a machine with packet filtering capability as well, and therefore
only interacts with control structures for the packet filtering subsystem)

	There are a few free Intrusion Detection System programs available
for UNIX, and plenty of rather inexpensive (but not free) ones as well,
for UNIX and Windows NT.  There are also plenty of VERY expensive
Intrusion Detection systems, too.  When you decide to "explore" a network
that doesn't belong to you, you have to do your homework.  This is a major
thing!  Remember that hacking is not a hobby, it is a way of life that
requires hard work, long hours, patience, perserverence, and a healthy
dose of reading up on your potential target.  The problem is this: most
IDS's will set off alarms if it sees typical "script kiddie research",
where most people go for tracerouting, portscans, and TCP OS
Fingerprinting.  This is not suitable when trying to keep the IDS from
immediately flagging you.

	The first thing you want to know is what OS they are running.
This narrows down the choices of IDS they could be running.  We are going
to operate under the assumption that you have no clue if they have an IDS
setup, yet you are trying to remain as stealthy as possible, for safety's
sake.  Once you know what IDS software they are likely running, you will
have a better idea of what you can and cannot do.  

	TCP Fingerprinting (using things such an NMAP's OS Fingerprinter,
or "QueSO") sometimes works without seting off any alarms, but it
requires that you know an open port (NMAP doesn't require an open port,
but it DOES perform a portscan that WILL set off most IDS's). Usually a
TCP fingerprint test sends 6 STRANGE packets to an open port.  Certain
loggers can detect these bizarre patterns of packets, and some IDS's will
pick up a quick burst of packets as a Denial Of Service Attack, and you're
nailed.  That's Bad. Don't risk it.  If all else fails, try to setup as
many IDS's as possible, and see if QueSO sets it off.  More on this
later...  Even if a lot of the target's stuff is behind a firewall, the
Web creates an iris of opportunity, where you, the creative hacker, may be
able to get a little more info.   

	No normally configured IDS will pick up normal web surfing as an
"Intrusion" unless you try to access restricted pages.  This means to feel
free to surf around and look for stuff.  Abuse their "Search" website
feature, if available, and look for a brag session where the company CEO
puts a page up explaining how he's proud tha they just bought some new X
brand server running <Blah>, and how it's un-hackable.  If you're lucky
and they are stupid, they will even tell you what IDS they use, right
there on the webpage.  If this doesn't work, you may want to attempt
coaxing a version response out of their web server.  This is a chunk of
BASH Shell Script (originally called "httpdquery" that my pal Razathorn
Threw together for me, it picks out HTTPD Server Version numbers from
error messages.  Running this once against a system with a web server
running would normally not set off any alarms: it's syntax is:

httpdquery hostname.com	(port 80 is hardcoded into the script)

__________________________CUT HERE_________________________________

#!/bin/sh

NOTE=/tmp/.httpdquery-$$-$RANDOM

export NOTE
touch $NOTE

(echo -e "http / 1.1\n";while [ -f $NOTE ]; do sleep 1;done) | 
(telnet $* 80 2> /dev/null| grep '^Server:';rm $NOTE)

__________________________CUT HERE_________________________________

My Fairly basic RedHat 5.2 Workstation gives this response:

Server: Apache/1.2.6 Red Hat

That's kinda bad, Really.  You just got a close look at what OS is most
likely being run, just by using a standard http get.  This means that it's
most likely a linux system, or there's someone on the other end that wants
you to THINK it's a Linux system, and is rather intelligent about changing
Server Version Responses. There are other ways of trying to figure out
what OS they are using on the server you wish to play with.  These can
range from Social Engineering techniques to "Dumpster Diving", or any
other method you can think of.  Please note that not all web server
daemons will barf out a version response like this.

If all that fails, you may want to Social Engineer some info out of
employees or other people.

Once you find out what OS they are most likely using, go to your favorite
massive search engine (I prefer Dogpile.com and metacrawler.com, myself.  
These two search tons of different search engines at once), and look for
IDS software for that OS.  You need a test machine.  Try to set up a
machine with a similar configuration.  Obviousely it will be hard to know
exactly what IDS they chose, or the coniguration that was used.  If you
can disconver this information, your job just got easier.

Like I said before, you need to set up a test machine for your own evil
purposes.  Give all the IDS software packages a try, and see what features
it offers. Your goal is to see exactly how far you can push the IDS
without setting off any alarms.  Don't worry about logs yet.  Most admins
that use IDS software won't look at the logs unless the IDS pinpoints an
IP address as one that was attacking, and then they use system logs to see
exactly what was going on, a little closer.  You need to try portscanning
it, using QueSO and NMAP OS Detectors, Try different stealth portscanning
techniques, and anything else you can think of.  See how long of a delay
you can use between ports on a portscan, and randomize what ports you use.
Many people will scan just one port every 3 hours or so, in random order.
By the end of a day. you could have a difinitive answer about 4 or more 
different services. With a really paranoid sysadmin and the right IDS, 
even this kind of scan can lead to being scrutinized.

All things considered, once you know what OS they are running, a check on
just a few services will tell you an awful lot if you know what you're
doing. If you know it's solaris, then you look only for "buggy" solaris
services to try to exploit.  You don't go searching a solaris server for a
linux-specific exploit, do you?

This process is known in the Info-Sec business as a "slow scan", where a
would-be hacker is really taking their time.  This kind of scan is
becoming more and more popular, and the IDS industry probably is not far
behind.  I know some IDS systems can be set to look for slow scans, but
they only detect a slow scan if it can find a pattern (for instance every
2 hours and 42 minutes (roughly) it picks up a connection to a different
port from the same IP Address, and this happens for almost a whole day...
some IDS can be told to red-flag this type of activity)

There was just a CERT Advisiory released no long ago, about "Distributed
Scans".  These are relatively new.  Check out SecurityFocus.com, and
CERT.org for information regarding this type of scanning.  I do believe
that SecurityFocus's tool archive contains some cool programs for doing a
Distributed Scan.

Another Variation that sometimes throws off an IDS is using the
proof-of-concept scan and sniff approach, where you portscan someone with
a spoofed IP Address of a machine on your local segment.  if you are
sniffing, you will see the results of the portscan, even though they were
not destined back to you.  This shows up in system logs and to IDS systems
as if it were not your machine portscanning, but someone else's...
sometimes.  If executed properly, it's possible to spoof several machines
on your network, doing a slow scan, with (apparently to the IDS) different
IP Addresses.  This approach would normally be inconspicuous enough to fly
below the IDS' radar.  There is a tool out there that does this, but I
cannot remember the name.  I think I found it on packetstorm some time ago
(http://packetstorm.securify.com).

Another option, similar to the aforementioned one, is to use different
internet access methods.  If you have internet at work, scan one port from
work.  Once, that's all.  Go home, use your dialup account to do it again,
just one port.  Go to a friend's house if they use a different ISP, and do
it there, too.  If you take your time and execute this part very
carefully, there will be no (or very little) cause for alarm as far as
your target is concerned.  This can also be executed if you have friends
on the phone or in IRC, you can say "hey...check to see if port 25 is open
on yourmomma.com!"

Some things to look out for:

Sysadmins can be real bastards (trust me, I'm one of them!).  At times,
they do something so unheard-of and unbelieveable that you can't accept
the fact that you've been had.  One of these many things is setting up a
hacker trap, where a "trophy" is just laying there, waiting to be taken.
There are various names for such a setup, but one of the more popular
jargon terms is "Honey Pots", christened because of their likeness to pots
of honey that hikers would place far away from their sleeping area (but
close enough together that a bear would run into one of the honey pots
before it ran into the weary campers).  It would distract dangerous bears
from the camp area.  

Sysadmins (being sometimes the sadists that they are), will plop a 486 on
the network, and make it appear to be running buggy versions of certain
services.  While these may or may not really be running the services, the
would-be hacker sees this supposedly "easy rooting" and spends a fair
amount of time messing with this system, and while this is happening,
alarms are going off, and people are being e-mailed and paged.  The system
might be putting firewall rules into place to make sure you are denied
access to anything more important than the one lowly decoy, too.

Basically, There are only a few types of IDS systems:

Type of IDS  Functionality			     Software that does this:
-----------  ---------------------------------       ---------------------
Loggers	     (just keep track of scans, etc)	     tcplogger, scanlogd
Reactors     (takes action upon scanning, etc)       portsentry, NSW Dragon
Integrity    (checks integrity of system files)      tripwire

We're really looking at loggers and reactors here.  Once you've obtained
any access to the machine, the Integrity checkers and system logging
facilities will have you.  You must determine if these exist and how to
make sure your tracks aren't seen again.  That is outside the scope of
this document.  

On many UNIX systems, things like tcplogger and scanlogd are used rather
often.  These are capable of detecting and logging any portscans
(including stealth scans).  Their sensitivity can be easily modified, but
by default, these tools are both rather strict.  These tools might also
pick up certain types of scans that reactors such as Portsentry might
miss.

Portsentry is another UNIX portscanning detector, but it is meant to not
only log the scan, but it can be programmed to deny access to the local
machine by means of firewall utilities, or by dropping the route to the
offending IP Address.  It can also run a script that the sysadmin
configures.  This could be anything from a script that pages the admin, to
emailing information about the offender to an email address, or even
creating an automatic retaliation attack against the offender.  Portsentry
is written in perl and is very configurable.  Chances are with some
hacking, it would run on Windows NT, but I'm not sure.

All three above utilities are provided under the GNU General Public
License, so you're more than happy to pick up a free copy and look at or
modify it to your needs.  As a hacker, I would recommend that you use this
to your advantange and study these programs to the best of your ability,
and if you find a way to increase functionality in them, submit the
changes to the author.

Other IDS tools exist, that don't quite fit into any of these
categories.  These are ground-breaking programs such as L0pht's AntiSniff.
Currently, this only works on Windows NT, but they are working on a
command-line driven one for UNIX that will be open-source.  AntiSniff is
commercialware, and needs to be licensed after a trial period.  What
AntiSniff does, is looks for machines on it's local network that are
sniffing.  Sometimes if a machine is sniffing, it responds a little
differently to certain packets.  This is the theory behind A tool called
"Neped" (which encapsulates a broadcast tcp packet inside a
deformed Ethernet packet). The L0pht went a different direction, however.
AntiSniff places the machine it resides on in "promiscuous mode" as well,
turning the machine into a sniffer of sorts.  It then makes false requests
and phoney IP packets.  Normally, any computer that's not sniffing would
ignore it, but many sniffers try to resolve IP Addresses, or do other
things that make reference to the false packet that was sent out.
AntiSniff quickly determines that something fishy's going on, and flags
the IP and MAC Address of the sniffing machine.  

There are only three reasons that a machine on the local network would be
sniffing, and two of them are malevolent:

* Someone has compromised or otherwise obtained access to a port on the
  local network and is using their own hardware as a sniffer.

* Someone has "rooted", "0wn3d", or otherwise compromised security on a
  machine on the local network.  This could be a windows 95 machine with
  buttsniffer, a compromised UNIX server, or anything.  This is not
  restriced to being a server.  Anyone with point and click skills can
  setup a sniffer on almost any network-aware OS you can think of.

* Someone is doing legitimate network analysis.  This usually doesn't 
  happen very often unless the network is in shambles.

On BUGTRAQ, shortly after L0pht's AntiSniff Announcement, people were
already coming up with sniffers that sould make an attempt to foil
AntiSniff's efforts.  These sniffers were VERY minimalistic.  Check out
the archives, as there was some nice code exchanged.  The thread name was
something to the effect of: "The Anti AntiSniff Sniffer", and you thought
Recursive Acronyms (GNU's Not Unix, PINE is not Elm, etc) were bad...

This exchange took place quite a while ago, and the latest AntiSniff may
be a bit better at picking up the stealthier sniffers, but who knows.
That's up to you to figure out.

Just remember, when you know what your target's defenses are, you have a
better chance at being able to set up similar defenses for yourself and
play with it.

On the flip side, any system administrator that leaves something as
important as an IDS with the default values shouldn't be a sysadmin.
Unfortunately, there are way too many of these around.  Just a heads up.
If you stray away from the defaults when setting up an IDS system, you are
likely to catch more of the activity.  Your modified rule sets will more
than likely be stricter than default, and the people who think that
they're undercutting your mechanisms will succumb to the same fate as the
guy who portscanned you 20 times yesterday.  =]

If that alone isn't enough of a reason to modify your IDS, just consider
the rest of your machine.  Would you leave everything default?  I'd doubt
it.  You never leave things stock, so why give your IDS anything less?




