24th of March 1999
Timo Aterma
Johannes Kleimola
Department of Computer
Science
Helsinki University of technology
[email protected]
[email protected]
4 Classification of tools used
7 Results
10 Summary
Appendices and experiments for UNIX
Appendices and experiments for Windows
The focus of this study is to evaluate publicly available software for hacking purposes. The aim is to assess the risks that the ready-to-use tools create and the effort that must be put to in their acquisition and use. Also, a glance is taken to the protective side.
This paper has basically been divided into two parts; UNIX and Windows (NT). Both of these operating systems have practically different kind of idealism and especially very different user groups. While children boot Windows where they learn to tie their shoes, UNIX still requires mediocre knowledge to use. Thus,
The UNIX sections throughout the document actually refers only to the Linux operating systems (free open-source version of UNIXes), but every other UNIX flavor is equally vulnerable to the concepts presented.
The document is aimed to find some features from a group of cases. Since both the services of target machines and attack programs should be used in all combinations - that is, using server software of different vendors and many same-purpose programs for attack - no assertions on "global" phenomena should be made.
The more or less valuable information retrieved from the case analysis will be an idea of the effort for UNIX rootkit migration, and NT tools usability.
Basic concepts and terminology
In Edward Amoroso's book Fundamentals of computer security technology [25]] the basic concepts are defined as follows:
"An attack on a computer system is some action taken by a malicious intruder that involves the exploitation of certain vulnerabilities in order to cause an existing threat to occur. " [25, p.2]
An attack taxonomy will be defined as any generalized categorization of potential attacks that might occur on a given computer system. Three factors are related to an attack taxonomy: its completeness, appropriateness and internal vs. external (security perimeter) threat categorization.
Terminology from Risks-based empirical taxonomy:
Examination of items marked with an 'X' are beyond the scope of this document, however, not necessarily all the other areas are covered either.
And about risk it is stated that:
"Risk estimates must be calculated for
all components of the architecture using estimated component priorities and
identified threats, vulnerabilities, and attacks as the main param eters in the
risk formula." [25, p.11]
"The estimated risk for a given component will increase with greater potential system damage and will decrease with increased difficulty for a malicious attacker." [25, p.11]
"A threat to a computer system will be defined as any potential occurrence, malicious or otherwise, that can have an undesirable effect on the assets and resources associated with a computer system." [25, p.2]
A Trojan horse is an "apparently useful program containing hidden functions that can exploit the privileges of the user [running the program], with a resulting security threat. A Trojan horse does things that the program user did not intend" (from CERT CA-99-02, [2])
"A vulnerability of a computer system is some unfortunate characteristic that makes it possible for a threat to potentially occur." [25, p.2]
A special isolated network was built to allow experimenting with various hacking related operations without disturbing outer networks. Several different machines and operating systems were installed to allow testing in various environments. Logically, the network operated as a bus. Thus, every machine was able to listen to all traffic. The firewall machine isolating internet was not used in any of the tests.
Computers and Their Operating Systems
The following table explains the machines installed in the environment.
| Machine | OS | Purpose | Attacked At? | Attacked From? |
|---|---|---|---|---|
| portinvartija: PC | Linux RedHat 4.2 | Firewall; Not used. | ||
| trubaduuri: SUN Sparc | Solaris 2.5 | SMTP, FTP, NFS | Yes | Yes |
| pappi: PC | Windows NT 4 | WWW-server, disk sharing | Yes | Yes |
| talonpoika: PC | FreeBSD 2.2.8 | SMTP, FTP, NFS, Telnet. | Yes | Yes |
| kuppari: SUN Sparc | Solaris 2.5 | SMTP, FTP, NFS | Yes | Yes |
| rikas: PC | Linux RedHat 5.2 | SMTP, FTP, NFS | Yes. | Yes |
| lukkari: PC | WIN NT 4 | SMTP, FTP, NFS | Yes | Yes |
| parittaja: PC | Linux RedHat 4.2 | SMTP, FTP, NFS | Yes | Yes |
| rakas: SUN SPARC | Solaris 2.6 | SMTP, FTP, NFS | Yes | Yes |
| rahaton: SUN SPARC | Solaris 2.6 | SMTP, FTP, NFS | Yes | Yes |
4 Classification of tools used
4.1 UNIX
In the UNIX/Linux environment we tested basically three
different categories of tools: rootkits, ethernet packet sniffers and
portscanners. Every one of these are downloadable from the Internet for free. As
countermeasures we mainly examined Tripwire. Tripwire is copyrighted by Tripwire
Security Systems, Inc. but the Tripwire 2.0 for Linux is free for non-commercial
(personal) use.
4.1.1 Rootkits
Rootkits are usually a bunch of trojaned versions of various system commands and programs. The programs are usually compiled from the same sources as the original one, with a small insert of some malicious code that gives some additional feature to the one who knows their existance. These features are commonly known as backdoors or trojan horses. As the name rootkit implies, many of these programs are intended to give a root shell when the additional code is invoked. In other words to give a non-priviledged user or an outsider superuser-priviledged rights to the system. The most common trojaned root-shell-giving-commands are login, rshd, inetd, passwd, chsh and chfn, but many others have been encountered. Some of the trojaned programs give other usefull funtionality, like hiding certain processes from process-listing programs (like top and ps), hiding certain sockets, connections and sniffering (netstat, ifconfig...), hiding files and wiping out marks from systems logs. Some of the trojans are invoked by typing a specific password in a right place. For example, the default password in Linux Rootkit IV programs is 'satori', but can be altered easily to anything you like. So when the system command asks for a login password, new shell to use, a name or whatever is specific to the command, typing the password gives you a rootshell or some other functionality.
Common to these trojaned programs are that they are post attack methods, that is, they require already existing root-priviledges to be able to install them. That means, a hacker must have already achieved root-priviledges some other way to the system and after that he can replace commands with his trojaned versions. The usual reason for installing these once you're "in" already is to cover your tracks, to leave a backdoor for further attacks in the future or to gain some other possibilities, e.g. to attack some other system.
Even though installing these programs usually requires root-priviledges, there are many other ways to do this, than just breaking into the system. One of the most common ways is to hide the trojans in some publicly distributed and well-known packages and updates. Just pick a tar-packet, .rpm or whatever, alter some installation scripts or even hide your code in somewhere and recreate the distribution version and watch people download and install it everywhere. It is not a joke that you should always check through the install-script before running it, to make sure you know what's being installed. How many of you out there really do that regularly?
An other common ways is to make a careless administrator to accidentally run the installation of trojaned programs (through hidden scripts, altered paths, "./ -this path"-concept and others like) so the hacker just has to wait. This usually requires that you alrady have user account on the machine but does not necessarily require any specific exploitation of some bug or breaking any security matter. Every user isn't that trustable.
Of course the easiest way to get trojans installed is if you had already managed to break into the system some other way. Unlocked terminals with root-logins and lousy or cracked passwords are maybe the easiest way to achieve this (and one of the most common ones).
If you have no integrity checking system guarding your system commands, these trojaned programs may be fatal to you system. Smart installers will alter modify times and other parameter to reflect the previous version, so finding out those trojaned programs may be impossible. And how do you know how long they've been there, so replacing those command from backups may not help. In the worst case you have to reinstall the whole system files, consuming up to days of manwork. Most of the trojan intallations are destructive, they do not take backups of the replaced files if not the hacker intends to put those original ones back some day to totally cover his tracks. But why would he care? So the actual damage to you system from those rootkits may vary from small harm and compromised security policy among users up to lost system files and every that damage a malicious hacker would ever wish to do with your system (information theft/destruction, disclosure, DoS...).
There are many rootkits available out there in the Internet for free. Some of them includes tens of different trojaned programs and others concentrate on just a couple. In the Appendix D several of them are listed as the result of searching in rootshell archives [9]. A couple of them are listed below.
Linux Rootkit IV [22] consists of several trojaned programs of various purposes. The packages includes the following (from README file):
bindshell port/shell type daemon! chfn Trojaned! User->r00t chsh Trojaned! User->r00t crontab Trojaned! Hidden Crontab Entries du Trojaned! Hide files find Trojaned! Hide files fix File fixer! ifconfig Trojaned! Hide sniffing inetd Trojaned! Remote access killall Trojaned! Wont kill hidden processes linsniffer Packet sniffer! login Trojaned! Remote access ls Trojaned! Hide files netstat Trojaned! Hide connections passwd Trojaned! User->r00t pidof Trojaned! Hide processes ps Trojaned! Hide processes rshd Trojaned! Remote access sniffchk Program to check if sniffer is up and running syslogd Trojaned! Hide logs tcpd Trojaned! Hide connections, avoid denies top Trojaned! Hide processes wted wtmp/utmp editor! z2 Zap2 utmp/wtmp/lastlog eraser!
Two other example rootkits includes only some programs. For example 'rootkit' [20] includes (from rootkit-README file)
z2: removes entries from utmp, wtmp, and lastlog. es: rokstar's ethernet sniffer for sun4 based kernels. fix: try to fake checksums, install with same dates/perms/u/g. The following programs will be patched and an attempt at spoofing the checksums of the files will be made. Also, these files will be installed with the same dates, permissions, owners, and groups of the originals. sl: become root via a magic password sent to login. ic: modified ifconfig to remove PROMISC flag from output. ps: ns: ls: du5: ls5:
An other, called 'rootkitLinux' [18] includes: login, ps and netstat.
As an example of a trojaned telnet daemon, telnetd-hacked [17] (from README file):
Modified telnet daemon (in.telnetd). This daemon function exactly the same way as normal in.telnetd would do, with a special function that if you telnet with with a special username, (in unix, you'd type something like 'telnet-l ') it'll get you directly into a root shell without getting logged (this seems to works fine on all kinda TERMs including xterm). The secret username is defined in unseen.h.
4.1.2 Sniffers
Sniffers are programs that capture the information
going over the network. On shared networks like ethernet, every packet of every
machine (on the same circuit) flows by every network card. Normally every card
picks up only those packets which header contains the proper address of the host
machine. But it is possible to put the card in a so called 'promiscous mode',
which means that the card accepts all packets, no matter what the header says.
With a proper program you can then analyze these packets and see the other hosts
connections and transmitted data. This process is called sniffing. Since a lot
of the network traffic still today is passed non-crypted (like telnet and ftp
sessions) it is very simple for a malicious intruder to put a host's (either
root-compromised or his own host on the same net) network card in promiscous
mode and by sniffing obtain other users login names and passwords. Ethernet
packet sniffers are the most common ones, but sniffers for other network types
and protocols do exist. [5]
"Sniffers is one of the main causes of mass break-ins on the Internet today." [5] But as sniffers can be used for hacking, they can also be used for administrative purposes. Many of the network failures, odd packets, wrong routing and other common communication problems can be tracked with a sniffer. That's why they are often used in many corporate and ISP networks. With a sniffer you can reliably answer the question whether some specific traffic is going in a specific place of the network. But since you see the packets, you also see their contents and every noncrypted texts (like commands, logins and passwords) can easily be read. The moral in using the sniffer for administrative purposes is debated every now and then, since seeing the contents (like email) can break individual privacy.
"Sniffing is one of the most popular forms of attack used by hackers." [5] One of the very first sniffers was Esniff [23] and most of the publicly available ethernet sniffers are more or less derivatives and improved versions of it. Sniffers have been ported to every UNIX flavors and there are several for MS-DOS and Windows also.
A statement about sniffers and trojans from CERT Summary CS-98.01 [8] says that: "In many cases, intruders have installed packet sniffers on compromised machines. These sniffers, used to collect account names and passwords, are frequently installed as part of a widely-available toolkit that also replaces common system files with Trojan horse programs. The Trojan horse binaries (du, ls, ifconfig, netstat, login, ps, etc.) hide the intruders' files and sniffer activity on the system on which they are installed. These packet sniffers also frequently hide their logs in system directories such as /usr/include or /dev/ptyxx."
Portscanners are used to find out what services are running in the target computer. Portscanners are usually small and simple perl- or c-programs, that tries to establish a connection to target IP-address and a specific port. If the target replies (connection is successfully established), they quickly drop it and move on to try some other port. Portscans are usually carried out systematically, starting from port number 1 and ending in either 1024 (highest of the so called well-known reserved ports) or some user defined upper limit (maximum is 65535 though). Most portscanners do TCP scans only by default, but they can usually be altered to make UDP scans also.
There are basically two kind of portscans, single host scan and network scan. Most of the portscanners can do single host scan to a remote host or local host and many let the user define which ports are scanned. Network scan takes usualy as parameters target C-class netid and the port to scan. The program then scans for that specific port with target IP-address consisting of the given netid and hostid ranging from 1 to 254. Scanning a single host takes up to tens of seconds and scanning a C-class network (one port only) about one second per host (that makes a couple of minutes). Some portscanners fetches the name of the found open port from local /etc/services -file, and prints a question mark or 'UNKNOWN' message for those ports it cannot find in that file. Some advanced portscanners asks the target system's identd daemon for the owner of the services found.
Since portscanning usually leaves sever marks in the target system logs and the scanners host IP-address is revealed, there have been developed various methods for avoiding this. One method is so called stealth-scanning, where the TCP-handshake (connection establishment) is not carried out completely and therefore the target syslog daemon won't report about an attempted connection. An other method is to spoof your (source) IP-address with some other's on the same network segment (Ethernet) and then sniff the answer packets from the network.
The search for tools was performed mainly by using Internet search engines [28], [29]
The keywords used were combinations of words such as 'hacking', 'NT', 'windows NT', 'cracks'.
Tools were retrieved from the following addresses:
The tools have been abbreviated with their file name (in most cases the package retrieved from the net). Open-written form for each tool exists in appendix.
Trojans are here considered as a subcontext of Amoroso's pest programs. There are thousands and thousands of ways to implement and/or create such a program, due to which trojans are not inspected here.
However, several pest programs are being evaluated. Slipping to trojan's side (that is, user himself has started the program and is aware of it) is avoided.
There are some UNIX password file crackers under inspection, but mainly for the side of their usability and ease of installation or use, since they relied on having a copy of the password file.
Some vendor-specific applications were present in the testing environment in the beginning, but generally no attack programs against specific application were meant to be analyzed. That is, programs attempting to crash a ftp daemon of any kind were tried, but those attacking some specific one were neglected.
5 Target systems
In the rootkit, sniffer and portscanner experiments
we used only Linux versions of the tools and the tests were done on either
RedHat 4.2, RedHat 5.2 or both. Even though all the "UNIX" parts of this
document actually referers to Linux, it doesn't mean the other flavors
(commercial and non-commercial) Unixes wouldn't be vulnerable as well. We tested
the rootkits made to Linux, but actually they are usually converted and ported
versions of older BSD UNIX commands and could therefore be easily changed back.
There do exist specific rootkits, sniffers and portscanners for other Unixes as
well, see Appendix
D for search results in Rootshell. RedHat 4.2 is based on the older
libc5-library and RedHat 5.2 on the newer glibc2 (libc6) library. The difference
is important when trying to compile the various packages and toolkits.
The services running in the various systems in the test environment can be seen from a portscan list in Appendix B.4.
Windows software is tested both on home computer and computers in the laboratory network. The aim is to commit all local break-in attempts with the highest level of security (that is, the most recent OS patches). For the computers at "lower levels of security", break-in attempts over network are examined.
There is a big variation in software, OS version and services running. As described in the introduction chapter, only a small fraction of variations between services and attacks can be investigated here. A list for both configurations are given in Appendices E.1 and E.2..
6.1.1 Rootkits
As an experiment we tested some rootkits especially
made or converted to Linux-systems. The victims were ordinary PC-computers
running either RedHat 4.2 or RedHat 5.2 (which was the newest and most common
distribution of Linux as by writing). As was mensioned in chapte 4.1.1,
installation requires root-priviledges, so in this experiment we already had all
the required rights to every computer.
The outlines of the experiment were as follows:
The first step is the easiest one. Using Altavista Internet search engine or visiting a couple of those well-known security-related sites ([1], [9], see search results in Appendix D) you can find anything you wish. We picked Linux Rootkit IV [22], rootkit [20] and rootkitLinux [19].
Unpacking these are trivial but compiling on a newer linux-system usually is not. Even though rootkits are meant to be almost "plug and play", depending on your system (and especially the target victims system!) compilation isn't always that easy. The problem is that most of them are created for libc5-based systems, the previous library-version Linuxes were built upon. Since almost every Linux distribution today is compiled with glibc2 (libc6), some of the libraries, names, functions etc. have changed and are not directly backward compatible. This results in compilation stopping in various errors and you have to manually modify the source, Makefile and/or headers. For some files this doesn't require very many changes and is certainly doable with moderate knowledge and skills, but many (especially those related with network operations and sockets) requires a whole lot of changing. For example Linux Rootkit IV compiles without problems on an old RedHat 4.2 -based system, but not very well on the newer systems. To put it simple: if you know nothing about compiling, c-programming and shell-scripting, you don't get very much out of these packages. However, after some 6 hours and up of examination, trying and source reading you get most compiled even on newer systems. But basically rootkits are meant to be as easy as typing: 'make all' and (be carefull, usually destructive!) 'make install'.
For a quick simple try on a RedHat5.2 you can comment out linsniffer compilation from Linux Rootkit IV-package main Makefile and do a 'make all' and you get chfn, chsh, ifconfig among some other usefull programs.
The 'make install' in Linux Rootkit IV is destructive by default. It uses a widely used replacing program (comes with many rootkits), called 'fix', that tries to set the original parameter for the trojaned version. 'Fix' takes the target command and replacing command as the required parameters and an optional third parameter that defines where to put a copy of the original one. You can add this third parameter to the install-part of the Makefile, if you just wish to try the trojans. On the other hand, you don't have to install them to try them, but some of the commands needs to be suid to work properly. If you install, run them as you would run the original ones.
6.1.2 Sniffers
Sniffit [15]
is one of the best ethernet packet sniffers for Linux systems. Sniffit uses the
'pcap'-library that isn't usually part of the Linux distributions but the
sniffit tar-packet contains the whole pcap-set, so everything is there. Setting
up sniffit is very easy. Even though you have to compile it by yourself, it is
carried out by giving two simple commands in the directory where you unpacked
it:
./configure
make
The first is an autoconfigure utility and it will produce the final Makefile for 'make' to run. It just couldn't be simpler. Sniffering requires root-priviledges, but it does not matter if you run sniffit on an own host in the same network or on a root-compromised computer. Sniffit comes with many command line options and an interactive ncurses (window-like environment with ascii-graphics) view to the ongoing connections.
Learning to really use sniffit effectively takes less than an hour and it can be used to capture every TCP/IP non-crypted traffic on the same ethernet segment.
Even though there are a several good sniffers out there for Linux, many of them are just short c-programs done with older libc5, which makes them very hard to compile on newer systems. But nevertheless, they do what you expect a sniffer to do, reveal the non-crypted traffic and also the ports and source & destination addresses (from crypted-traffic also). If you succeed to get those small c-programs to compile on the victim computer, they can be very effective and quickly used (and therefore very dangerous).
The problem with sniffers is that they usually leave the ethernet-card in 'promiscous'-mode and can therefore be either revealed in action or administers can later observe somebody has been sniffering. The 'PROMISC' -flag in interface reports can be removed with trojaned commands (like ifconfig) or you have to get a program that resets the card in its normal mode.
Portscanners like SS, Pscan, Ident-scan, tcpprobe etc. (see search results in Appendix D) are almost plug-and-play programs. They are usually very small and simple but since many of them are made for old libc5-based Linuxes, compiling them may require changes to the source code on newer glibc2-based systems. Portscanners can be found from the Internet, compiled and taken into use in just a couple of minutes and they really don't require much understanding to try them. If you wish to avoid beigh caught, you mush however know the socket concepts and technology well and start using some stealth- and spoof-scanners. Portscanners are kind of 'quick-and-dirty' tools, to just check whether some specific services of interest is running on the target host. See Appendix D for a list of portscanners with links to them.
There was an attempt to install each of the attack programs (when commiting local tests) and normal installation procedure when using Administrator rights (attack over network). Programs were run under same rights.
Services running on machines were not modified nor were file protection settings.
The results of the experiments we made can be found in Appendixes A.1 and B.1 for rootkits, A.2 and B.2 for sniffers and A.3 and B.3 for portscanners.
As the experiments show, using the programs is rather easy. Some of them requires mediocre knowledge in shell-scripting, c-programming and good understanding about the system, but basically, if you can use Linux, then you can get at least some of the packages available to work in just a couple of minutes. Learning to use them effectively in attacks requires lots and lots of experience and knowledge, and therefore time and patience.
7.2.1 Tool acquisition and startup
All the tools proved out to be installable by a beginner. The average time of creation of tools was 1997, thus only a small fracion of them was expected to work properly.
Contrary to hacker software for UNIXes, only few had their source code released with the program itself. As for documentation, the percentage was somewhat around 50%.
Their use, however, required various level of knowledge. Classification can be seen in appendices.
Most complex "to the eyes of beginning hacker" are command-line based tools that have no help page, giving no or only professionally written feedback upon use.
In the range of 1-5, 5 being the most simple, 3 indicating ready-to-run decompression or setup, 2 indicating need for configuration, and 1 indicating the need for source code alteration, the average simplicity of installation for all windows-based tools tested was 3.4 .
In the range of 1-5, 5 being the most convenient, the average usability of a tool was 3.3. 1 is considered here as a poor command-line -based program and 5 being a configurable GUI.
In the range of 1-5, 5 being the most flexible, the average possibility to configure the tool was 1.8 . Most of the software didn't provide any methods for scripting through command line arguments.
In the range of 1-5, 5 being the most powerful, the average "power" of a tool against a system was: 1.7. The "power" was here understood as the more the program managed to do what it promised, the higher the rating. Evidently the majority received very low numbers.
The term "power" should be understood here as an indication of percentage of programs "useful" or having any effect on target systems inspected. This does not scale to any other system or to same systems running different services.The results of break-in attempts are available in Appendix A.4
A general factor during installation for the programs was that they were able to operate only in the directory given. System directory (\WINNT\system32 by default) did not give change access for the files other than those belonging to the user.
System did not crash during the tests. Best effort of a malicious program for crashing was initiating a shutdown procedure using normal user rights.
System 1 is defined in Appendix E.1.
These tests were a repeatition of tests made in System 1, with the exception of network attacks being non-local.
Also the difference between most and less recent service packs became evident, as the System 2 leaked its LanMan passwords to the other machine. L0phtCrack cracked the Domain Administrator's password from hash just in few seconds.
System 2 is defined in Appendix E.2.
Since the tools vary in the attack taxonomy they exhibit, and they are even
aimed either for ill-doers or system administrators, it's hard to tell which
program to raise above others. And especially due to the reason that no target
system characteristics is known.
However the following two seemed to have least constraints for their
operation:
7.2.4 Most efficient picks
8 Countermeasures
As the experiments showed, trojan programs are dangerous, very dangerous. But as said earlier they are not immediately usable and requires at least some basic understanding of c-programming and shell-scripting as well as a lot of understanding about the underlying system and the trojaned program. It would be stupid to just throw in a trojan without care, you would cause more harm to yourself. There are many easy ways to at least partially defend against trojans and rootkits. However, a very well placed and well-planned and programmed trojan is one of the worst nightmares of a system administrator.
Absolutely number one way to detect and protect against trojans is by using a file integrity checking system. A regularly run integrity check against critical files immediately discloses any changes in binaries and configuration as well as modification, access etc. parameters. But there's a number of other simple ways to detect trojans. A very common feature in trojaned program is that they have changed in size. It wouldn't require much to make a shell-script that records just the sizes and modification times of certain files, and let it recheck them every now and then. However, you have to keep in mind, that a smart trojan is very hard to distinguish from the original, and that not every trojan is a replaced file. A trojan program may be a file of itself, usually hidden somewhere, or just a process in the memory, which might be gone after next reboot. A true problem with every integrity checker and likes is that they can be fooled or even compromised. If some has the root-priviledges to insert a trojan, he certainly has the capability to modify the integrity checking list/database/procedure. Any read-write log can be erased, and i.e. Linux Rootkit IV comes with a log entry "zapper", that removes last actions from syslog. That is why every important log should always be written on a write-once media (line printer, tape, cd-rom etc.) and same applies to integrity databases.
These rootkit types of trojans are very easily detected with integrity checking and even by inspecting the command files. If a file is suddenly pretty big, you may suspect it to be trojaned. If modification times or size is slighly changed and you haven't recenly installed a new version of it by yourself, it is a probably a trojan. If the command behaves strangely, you can suspect it to be a trojan. Odd logmarks may reveal a trojan, as well as odd user activity, odd login times and sources.
Tripwire is one well-known integrity checking program nowadays available for free (Linux) for personal non-commercial use (Tripwire 2.0 for Linux). [24] Commercial versions are available for other systems also. Tripwire is very configurable and can run several types of tests. Basically it counts various checksum values and verifies file permissions and attributes (size, last modified etc.). Tripwire includes several different checksum algorithms to choose from (MD-5, CRC-32 among others) and creates very comlete reports of incidents. Tripwire has some security vulnerabilities though. The database and executable should be put to a read-only media and the reports should not be send over network (the whole program should be run locally on servers only) or by email. But good points are that it contains a good choice of cryptographic hash functions, it has a simple, clean user interface and the documentation warns you of possible attacks against the mechanism. [26] See Appendix C for experiments with Tripwire.
If you have the capability, install some integrity checking system and make
it run often enough. If you can't, do it anyways. Only then you can be pretty
much sure that you have no trojans. Run suid and sgid -checking scripts or
programs. Before unpacking and installing a new package (tar-package, .rpm,
etc.) check them against a hopefully supplied digital signature and check the
install-script before you run them. An finally: know your system, learn the
commands, read the logs, try to achieve a sense about your system, that is you
know when it's running normally and when it is not.
8.2 Windows
As for global rules, countermeasures for both systems involve primarly running them through with diagnostics tools, such as ntis (see Appendix A.4).
Then, a log watcher along with port listener should be acquired. Implementing analyzers that in the future could discard packages coming from one subnet will serve as a partial - not necessarily correct - solution to a DOS problem.
As there are extremely many vulnerabilities, vendor, software version and configuration related (and vulnerabilities of mixing all of these wrong way), using as many analyzers as possible is a must.
As a default, latest versions of all software involved, OS and the server/client applications, work as basis for security.
8.3 Countermeasures by the OS - future aspects
Since practically all the pest programs for windows are delivered in binary format and due to the lack of compiler on many workstations, windows machines would be an ideal place for attack pattern recognition, that is: static attack programs causing same system call sequences could be easily detected. This would require access to the kernel source which is hardly to happen. The same approach is of course applicable on UNIX side. Since this area is more or less unexplored (at least by the writer ;-) ), there is no certainty on the malicious programs of being detected.
Another possibility is to classify system calls according to binary locations, allowing only some programs use some system calls. On UNIX side, this approach is quite fruitful.
For both platforms the idea of signed binaries sounds promising. Though, only configured UNIXs can provide this today.
Malicious hacking is very demanding, you must remember to cover all of your tracks. That's why almost every time a hacker leaves misstakenly some marks around. Shell history and syslogs are usually remembered, but very often there are (or at least should be!) other auditing mechanisms and hopefully some own system-specific mechanism the hacker may not know about. But with trojans, it is very common to find those programs far too late. The harm is already done. The hacker is gone by the wind. Depending on how often you do your regular integrity and other security checkings, it may take a long time before you notice something is wrong.
Even though getting rootkits, sniffers and portscanners from the Internet is very easy, they usually require mediocre knowledge about operating systems and programming. But learning the basics takes only days and underestimating the power of these packages is fatal. Hackers have plenty of time.
A good source about hacking and exploits can be found in hacking guides like Hacking Kit v2.0beta by Invisible Evil [6].
A true story about ignored security and its consequences can be read from an excellent article from bugtraq mailing list archives, see [7].
Using Windows workstations with shared accounts forms one of the main threats on this system. Programs providing strong ecryption may be causing a false sense of security, as there is a possibility to implant the malicious program on desktop level.
Despite the OS being used, every user should have an isolated workspace.
Results from the NT usability here - and such - is highly subjective. A survey on some 50-100 people using some of the tools listed would give very different results.
Most of the sites provide attack-oriented knowledge how to protect a certain attack. Yet, during this analysis, no sites were found to provide information how to set up sites for some specific purpose.
The majority sets up servers for some quite common purpose. E.g. to set up a WWW server with CGI-bins it would be helpful to know what OS/kernel version to choose, which server version and what setting to apply for the server.
Rootkits are packages with sources of trojaned versions of various system commands. Getting such packets from the Internet is as simple as a couple of mouse clicks, but compiling and installing is dependant of the target system. To use the rootkits in attacks you must get root-priviledges to the target host or have the local administrator accidentally install them for you. That's why they are usually used in already root-compromised systems to cover your tracks or leave backdoors for future attacks.
Sniffers are widely used in network management and administration to search out network problems, but they can be as easily used to gather non-crypted logins and passwords or to read other's emails. Commercial sniffers costs up to hundreds of thousands, but many good open-source versions can be found for almost every system.
Portscanners are small and simple programs that reveals what services are running on the target system. They do, however, usually leave clear marks in the system logs and the origin of the portscans can be traced. Several advanced portscanners try to prevent this by using stealth- and spoof-methods.
On a home-use computer, Windows-based applications pose little threat. Their targets remain on the server side, and today most recent versions of OSs and drivers have practically eliminated the chance for an external attack. Vulnerabilities remain more on the actions of people, programs they download and execute.
Windows-based binaries are practically all ready-to-run after download and decompression. The skill required for their use varies a lot, but all the more often these programs require less and less knowledge to operate.
Information sources
| [1] | Bugtraq mailing list archives, many writers. Bug reports and
discussion. [referred 09.02.1999] < http://www.geek-girl.com/bugtraq/> |
| [2] | CERT Advisory CA-99-02-Trojan-Horses, 05.02.1999 About Trojan horses,
how they are installed, and solutions against them. [referred 09.02.1999]
< http://www.cert.org/advisories/CA-99-02-Trojan-Horses.html> |
| [3] | Christopher Klaus, Backdoor Paper (article from bugtraq), some
replies, 16.08.1997. [referred 09.02.1999] < http://geek-girl.com/bugtraq/1997_3/0310.html> |
| [4] | Dejanews, the discussion network, many writers. Excellent internet
news search engine. [referred 09.02.1999] < http://www.dejanews.com/> |
| [5] | Internet Security Systems, Inc. Sniffer FAQ v1.7. 21.09.1996.
[referred 09.02.1999] < http://www.l0pht.com/pub/blackcrwl/hack/sniffer.txt> |
| [6] | Invisible Evil, Hacking Kit v2.0beta, March 1997, ASCII, 31.12.1997.
"A very detailed and well written guide for hackers. This document is also
fairly up to date and includes examples and source code." [referred
09.02.1999] < http://www.rootshell.com/docs/hackkit-2.0b.txt> |
| [7] | John E. Jasen, No Security is Bad Security (article from bugtraq),
many replies, 02.02.1999. A true story about ignored security and
therefore compromised system. [referred 09.02.1999] < http://geek-girl.com/bugtraq/1999_1/0433.html> |
| [8] | Phillip R. Jaenke, CERT Summary CS-98.01 (from bugtraq), 13.02.1998.
About Trojan horses & sniffers and links to further information.
[referred 09.02.1999] < http://geek-girl.com/bugtraq/1998_1/0212.html> |
| [9] | Rootshell archives, many writers. Rootshell archives includes
exploits, news and documentation about various security matters. [referred
09.02.1999] < http://www.rootshell.com/> |
| [10] | Security Hole list FAQ v7.0 21.09.1996 (quoting from the
comp.security.unix FAQ) [referred 09.02.1999] < http://www.l0pht.com/pub/blackcrwl/hack/holelist.txt> |
Some good hacker sites
| [11] | 2600 Magazine. [referred 09.02.1999] < http://www.2600.com/> |
| [12] | Hackers Layer. [referred 09.02.1999] < http://www.lordsomer.com/> |
| [13] | L0pth Magazine. [referred 09.02.1999] < http://www.l0pht.com/> |
| [14] | Phrack Magazine. [referred 09.02.1999] < http://www.phrack.com/> "Excellent indexes of Phrack magazines volumes 1-53 with links to them." Latest Phrack magazine during writing was Phrack 54. [referred 09.02.1999) < http://www.2600.com/phrack> |
Sources, tools and programs (UNIX)
| [15] | Brecht Claerhout, Sniffit. Ethernet Packet sniffer for Linux, SunOS,
Solaris, FreeBSD and IRIX. Sniffit v.0.3.5 - Last updated: Apr. 1997 Sniffit v.0.3.7.beta - Last updated: Jul 1998 [referred 09.02.1999] < http://reptile.rug.ac.be/~coder/sniffit/sniffit.html> |
| [16] | CERT(*) Coordination Center List of Security Tools. Version 1.2.
October 2, 1997. Info about various downloadable security tools with
ftp-addresses. [referred 09.02.1999] < http://www.cert.org/ftp/tech_tips/security_tools> |
| [17] | DrWizard, telnetd-hacked, Modified telnet daemon (in.telnetd).
[referred 09.02.1999] < http://www.rootshell.com/archive-j457nxiqi3gq59dv/199707/telnetd-hacked.tgz> |
| [18] | Example password sniffer sources for Linux from Rootshell. [referred
09.02.1999] < http://www.rootshell.com/archive-j457nxiqi3gq59dv/199804/linsniff.c.htm> |
| [19] | Example rootkit sources for Linux from Rootshell. [referred
09.02.1999] < http://www.rootshell.com/archive-j457nxiqi3gq59dv/199707/rootkitLinux.tgz> |
| [20] | Example rootkit sources for Linux from Rootshell. [referred
09.02.1999] < http://www.rootshell.com/archive-j457nxiqi3gq59dv/199707/rootkit.zip> |
| [21] | Fyodor, NMAP -- The Network Mapper (nmap version 2.07). Excellent
utility for remote port scanning and OS identification by TCP/IP
fingerprinting. [referred 09.02.1999] < http://www.insecure.org/nmap> |
| [22] | Lord Somer, Linux Rootkit IV, Released November 26, 1998. [referred
09.02.1999] < http://www.rootshell.com/archive-j457nxiqi3gq59dv/199812/lrk4.tgz> |
| [23] | The original Ethernet sniffer sources ( Straight out of Phrack ).
[referred 09.02.1999] < http://www.rootshell.com/archive-j457nxiqi3gq59dv/199707/Esniff.c> |
| [24] | Tripwire Security Systems Inc. Tripwire 2.0 for Linux. [referred
09.02.1999] < http://www.visualcomputing.com/> |
Books, papers
| [25] | Amoroso, E., Fundamentals of Computer Security Technology, Prentice-Hall PTR, Upper Saddle River, NJ 07458, 404 p. [referred 24.03.1999] |
| [26] | Bishop, M., UNIX Security Tools: Use and Comparison, University of California at Davis, Department of Computer Science, Davis, CA 95616-8562 [referred 23.03.1999] |
| [27] | Schneier, B., Applied Cryptography, 2nd edition, John Wiley & Sons Inc., 1996, ISBN 0-471-12845-7 [referred 18.03.1999] |
Search engines
| [28] | Altavista [referred 24.03.1999] < http://altavista.digital.com/> |
| [29] | Yahoo [referred 24.03.1999] < http://www.yahoo.com/> |
Windows NT resources
| [30] | Downloads [referenced 01.03.1999] < http://www.geocities.com/Tokyo/Garden/2389/down.html> |
| [31] | hacking Philez! [referenced 15.03.1999] < http://www.geocities.com/Paris/Rue/6354/hack2.htm> |
| [32] | Index of ~bryguy [referenced 24.03.1999] < http://www.digitalpla.net/~bryguy/dementia/archives/hpavc/> |
| [33] | Jonathan Feldman, SID Stalking: Cloning Windows NT [referenced
15.03.1999] < http://www.nwc.com/917/917ws1.html> |
| [34] | Nomad Mobile Research Centre [referenced 01.03.1999] < http://www.fastlane.net/~thegnome/files/snt/index.html> |
| [35] | Underground News [referenced 15.03.1999] < http://www.undergroundnews.com/> |