HIR Issue 10: Flying Below The Radar
An introduction to not setting off IDS Alarms
By: Axon
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 usage 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, perserverance, 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 setting 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 that 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 favourite 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. Obviously it will be hard to know exactly what IDS they chose, or the configuration that was used. If you can discover 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 definitive 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 Advisory 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 unbelievable 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 advantage 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 restricted 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 should 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?
