Landmining the Cracker's Playing Field
Amy Rich With the popularity of e-commerce and the Internet in general, the explosive growth in the number of script kiddies, and the shortage of qualified network and systems administrators, those of us manning the trenches require every possible tool to defend our networks and servers. The effectiveness of using detection devices to notify you when someone invades has been proven repeatedly in tactical warfare. Fear, uncertainty, and doubt, combined with the occasional nasty surprise, go a long way toward discouraging enemies from trying to poke holes in your perimeter. Many companies also utilize technology like infrared detection, laser tripwires, motion sensors, and pressure sensitive pads in home and corporate security to protect physical assets. IDS These same techniques can be implemented successfully in the electronic world as well as the physical. In the realm of computers, products known as intrusion detection systems (IDS) watch for attacks on machines and networks. Generally, these products scan packets, logs, and other information sources, analyzing traffic for any signs of attack. The typical IDS does nothing to protect networks and systems or to actually prevent intrusion attempts. The perfect IDS would accurately recognize 100% of attempted attacks, with zero false positives, and immediately notify the administrator. This fantasy IDS would probably also include a complete diagnosis of the attack with an audit trail, recommendations on how to fix the vulnerability (if one exists), and might even fix the vulnerability on its own. Unfortunately, software and hardware are not yet that far advanced and one must choose a balance between false positives and missing some possible attacks. IDS Paradigms Four main IDS paradigms exist: anomaly detection, misuse detection, burglar alarms, and a hybrid mixture. Some people also view honey pots, or sandboxes, as another paradigm, but most systems administrators, because of lack of time and staffing, are more interested in keeping the crackers off of their network than inviting them into play in a secured area. We'll briefly cover anomaly detection, misuse detection, and burglar alarms, concentrating mostly on what I like to call landmines, a subset of burglar alarms. Anomaly Detection Anomaly detection is an AI-based approach in which the program/box watches the system/network for a certain period of time to learn what constitutes ''normal'' activity and stores information in a database. After the learning period, the program/box applies a set of heuristics to all traffic and generates some sort of alert when an event occurs outside the accepted norm. Most current implementations and research using anomaly detection employ neural networks, keystroke monitoring, statistical analysis based on user profiles, or state transition analysis. Anomaly detection can detect unknown attacks, and it doesn't require constant updating of a vulnerability database. Unfortunately, anomaly detection techniques aren't overly specific about what they see wrong, just that something differs from the norm. Anomaly detection techniques are also still at the point where they generate quite a few false positives or, depending on how the administrator has tuned the percentage deviation allowed from the heuristic, do not catch attacks in progress. Misuse Detection In the case of misuse detection, attacks must be known ahead of time to catch them in a scan. Because all the attacks are known ahead of time, there are very few false positives, but the possibility for missing unknown attacks is much higher. Misuse detection often includes things like looking for certain strings or patterns on the network or during an interactive session. Misuse detection IDS are easy to install and deploy, but they must be updated frequently and are easier for a clever cracker to bypass. Burglar Alarms Burglar alarms are policy-based monitors that alert the administrator when a policy violation happens. A policy violation may not necessarily be a security violation (i.e., someone adds a new mail server without going through the proper channels). Burglar alarms detect activity that an attacker may perform after breaking in. Burglar alarms placed outside the network perimeter can also warn of attempted breakins (known as attack detection), but these are so frequent that the data isn't overly useful. Burglar alarms, because of their nature, generate very few false positives and can often detect previously unseen attacks. Since burglar alarms are policy driven, though, they require intimate knowledge and control of the network. Landmines Landmines are a wholly host-based type of burglar alarm, essentially a binary, library, or script purposely trojaned by the administrator. The objective of a landmine is to replace a program that a cracker would likely run in the process of compromising a system. The new program will send an alert when executed and will usually also perform the intended function of the replaced program. Landmines are truly the last line of notification when someone has already penetrated your perimeter and host security. Because landmines replace everyday binaries, they can detect misuse that goes unnoticed by firewalling, filtering, and other security measures. Landmines are most effectively used on machines with few shell users and limited root access. Modified landmines that only look at certain UIDs, while not as effective, can be used on heavily used shell machines instead. The key is to place the landmines effectively while avoiding a lot of false positives generated by your users or your fellow administrators. How to Lay a Landmine Implementing landmines is quite easy if you have a little C or scripting knowledge and can read a man page. The landmine can be planted in three general ways. The first and most thorough way is to completely replace the binary with a modified one. This method requires the source to the OS, though, so it is only possible on machines where the source code is free, you have a license for the source code (rare these days), or you have a piece of source code that is in the open source domain but that functions on your platform. The second method, also requiring source code, is to replace the binary but keep a copy of the old binary under a different name. The original binary can then still be used by those who know of it. The third method is to write a simple wrapper program, which is substituted for the real binary, and have it call the real (renamed and hidden) binary. The first method is most desired since, even after investigation, the cracker finds it difficult to differentiate the new trojan binary from the one it replaced. Digital signatures will be different, but the cracker may attribute that to the result of an upgrade or patch, especially in the case of open source OSs where certain programs can be easily upgraded without modifying others. Many binaries can be completely replaced as long as the systems people learn to use other programs on the machine to obtain the needed information (echo * instead of ls, top instead of ps, etc.), but there are some commands, or flags to certain commands that are difficult to live without. This is where the second method comes in. Replacing the binary but still keeping the old program around under a different name lets the cracker use the trojaned binary while the systems people who are in-the-know use the unmodified copy. The most undesirable effect of this method is that the cracker may find the original binary by searching through the filesystem for a particular digital signature associated with the binary that's distributed under that OS release. A clever idea, if you have source code, would be to slightly modify the "good" binary, so that the signature changes and nothing on the system matches the list of known signatures. If you don't have the source code, then you're pretty much stuck with the third method, writing a wrapper and having it call the renamed ''good'' binary that now resides under another name. First, make sure that your wrapper is a C binary and not just a shell or Perl script. It's much easier to spot a scripted wrapper by looking at the size or by doing a file or more (or any other paging utility) on the program. When writing a wrapper, also try to pad the binary with NULLs or some sort of garbage so it appears to be approximately the same size as the program you're replacing. If a cracker notices that a binary is significantly smaller than it should be, this is an immediate warning bell. Landmine Placement Now that you know how to lay a landmine, what programs do you pick to trojan for the optimal effect? This is where the administrator must put on his cracker hat and think like those trying to breach security. What's the cracker's motivation for breaking into this machine? What are the first things the cracker will do after breaking in? What are the programs the cracker is most likely to use? What programs can be replaced with the least amount of notice? The motivation of the cracker differs, of course, depending on whether it's a script kiddie or someone after your corporate data. Truly sophisticated crackers targeting a specific machine or company will be nearly impossible to stop because they will have studied the target and will bring their own set of statically linked tools for that particular OS. Less sophisticated crackers and the ever present script kiddies will just whack away at your machine with tools that are already available. They may compile a few things of their own or run some shell and Perl scripts. The truly pathetic script kiddies will try running DOS commands on your UNIX machine. So, for the most part, you cater to the lowest common, and most frequent, denominator. Let's imagine a fictitious cracker. This one actually knows some UNIX, but he's pretty paranoid and not overly bright. What programs can we expect him to use? He will most likely start off by trying to see who's on the system and what's running: w, who, finger, last, ps. He's verified that no one seems to be present; so it's time to look around: ping, traceroute, netstat, ifconfig, hostname, ls, find, more, cat, less, vi, diff, crontab. Maybe he'll make a few changes to leave himself another back door: su, chmod, chown, adduser/useradd, vipw, mv, cp. Time to pull over some script kiddie t00lz from another machine and use this as a base to crack more machines: ftp, telnet, tar, gcc, cc, ld, perl. And, lastly, do some cleanup: date, kill, inetd, format, newfs, mkfs, rm, unlink, shutdown. As you can see, there are plenty of places where our cracker can stick his foot and have everything blow up in his face, and these are just a few examples. Some of the network tools he tries to use can even be blocked by a router filter or a kernel filter like ipfilter, giving you an early warning. Try to catch him as soon as possible, but be creative about where you lay your landmines. For instance, modifying the exec() command in a shared library so that it logs all but a very defined set of commands can catch a lot of people. Don't use the same tactics on all of your machines. Also try to disguise your landmines so the cracker doesn't get suspicious before he trips one of them. The more difficult your landmines are to find, the more paranoid the crackers will be about violating your networks. Appropriate Actions So, your cracker has fallen on a landmine. How do you respond? That question can probably best be answered by seeing which landmine got tripped and checking your site policy. If he tripped your ls landmine, you probably want to log a message to a centralized syslog server, send the administrators a page or email, spawn an innocuously named program that monitors the system more closely, or some combination thereof. Make sure not to pigeonhole yourself into one form of notification since the cracker may have disabled one or more common notification routes like mail or syslog. You could do something clever and run your own little centralized syslogger under the name telnetd (assuming you don't actually use telnetd) and tcp wrap it so that no one can actually connect on port 23. Basic notification is probably good enough for a cracker exploring your system, but what if he trips your format or newfs landmine? This is a bit more serious because you know that he's determined to destroy your data. In this instance, perhaps the best course of action is to write out a log message, sync the filesystems, and shut down the machine before the cracker tries something more malicious when he sees the program fail. The automatic host/application monitoring mechanisms you have in place should report about the downed machine fairly quickly. Your system should have logged enough information on the cracker for you to start looking for the entrance hole on your machine or network. A Example Landmine: ls Let's say I want to be notified whenever anyone runs ls. You can get fancier than my example (see Listing 1) and log things like the username and current working directory, too, but I'll keep it fairly simple here. For this example, I've referenced (diff -wc) FreeBSD 3-stable source tree specifically, but the concepts and code ideas should be fairly extensible to all UNIX OS variants. So, you can do your own comparisons, the RCS id for this version of ls.c is:
"$Id: ls.c,v 1.23 1998/08/02 22:47:11 hoek Exp $"; When we run the following command:
ls -algFc ls.c Our output looks like the following in our logfile:
May 12 16:26:17 rugsucker ls: BOOM: 'ls -algFc ls.c' run by uid \ Basically, I've added the syslog.h include file and a couple new variables to deal with cramming argv into one nice printable variable. Once all the setup work is done, I write out the syslog entry and continue with the normal operation of ls. I purposely pick a syslog level that's not used by anything else, local5 in this case, so I can send things off the machine to a centralized syslog server. As well as compiling and installing the binary, I need to add an appropriate entry in /etc/syslog.conf and HUP my syslogd. On the syslog server, I'd have something like the program swatch watching the logs for anything that said "BOOM". From swatch, I can call any program when I see a certain regexp in the logfile. I can be mailed, paged, set off the klaxons in the office, or whatever I think appropriate. Conclusion Systems and network administrators need to use every available resource to keep intruders from the off-limit portions of their sites. IDS is a fairly new and interesting field of intrusion and attack detection that may lead the way for automated intelligent monitoring. The policy-based trojaned nature of landmines is especially useful for tripping up unwary attackers once they're on your machine. Resources Here are a few IDS resources:
The IDS mailing list: To join, send mail to majordomo@uow.edu.au with the body ''subscribe ids'' Archives are available at: http://www.geek-girl.com/ids/ COAST's IDS pages: http://www.cs.purdue.edu/coast/ids/ and http://www.cs.purdue.edu/coast/intrusion-detection/ NIST's IDS tools page: http://cs-www.ncsl.nist.gov/ \ USENIX sponsored and co-sponsored IDS tutorials: http://www.usenix.org/
About the AuthorAmy Rich, president of the Boston-based Oceanwave Consulting, Inc. (http://www.oceanwave.com), has been a UNIX systems administrator for more than five years. She received a BSCS at Worcester Polytechnic Institute, and can be reached at: arr@oceanwave.com. |