Notes:
|
|
|
|
Softpanorama |
May the source be with you, but remember the KISS principle ;-)
|
| Old News | See also | Recommeded Links | Rootkit Detectors | Humor | Etc |
Please note that practice had shown that checks done with the help of "all-encompassing" Tripwire rule-sets are usually ignored in a month or so even less after their creation. After this period Tripwire became just i useless ritual that is running but nobody is looking. I think that realistic limit for Tripwire policy is below a hundred files. A simple Perl script can help to solve the problem of non-existent files in the standard rulebase (input is the default policy source file on STDIN or as first argument, output on stdout is the new policy source file):
#! /usr/bin/perl
while (<>) {
if ($_ =~ /(\/[\w\-\.\/]+)/ && !($` =~ /#/)){
$_ = "#$_" if (! -e "$1");
}
print $_;
}
More flexible integrity checkers then Tripwire are based on scripting languages. See for example Afick: is a fast and portable intrusion detection and integrity monitoring system, designed to work on all platform (it only needs Perl and standard modules), including windows, Linux, UNIX. The configuration syntax is very close from tripwire/aide. Scripting language based integrity checkers have a better chances to provide real value in maintenance as you can adapt them to your needs (you you are strong C-programmer you can do the same with the Tripwire but generally I recommend spending your tie on other projects).
Recently Rootkit became one of the most popular Trojans sets used in remote network attacks. See for example the following CERT advisories:
Rootkit itself is a pretty primitive set of Trojans most probably inspired by PC viruses techniques. The early versions of Rootkit included (I have a pretty old one, but may be not the oldest ;-):
du.c - 4877 bytes (Mar 1 1994)
du5.c - 5588 bytes (Mar 1 1994)
es.c - 12503 bytes (Mar 1 1994)
fix.c - 3031 bytes (Mar 1 1994)
host.c - 1727 bytes (Mar 1 1994)
if.c - 8583 bytes (Mar 1 1994)
ifconfig.c - 21262 bytes (Mar 1 1994)
inet.c - 14505 bytes (Mar 1 1994)
ipintrq.c - 629 bytes (Mar 1 1994)
ls.c - 17661 bytes (Mar 1 1994)
ls5.c - 24450 bytes (Mar 1 1994)
main.c - 6660 bytes (Mar 1 1994)
mbuf.c - 7883 bytes (Mar 1 1994)
ns.c - 5975 bytes (Mar 1 1994)
ps.c - 36196 bytes (Mar 1 1994)
revarp.c - 11161 bytes (Mar 1 1994)
It was a pretty primitive toolset useful against completely incompetent sysadmins only and that's why it proved to be so effective ;-).
Recently loadable kernel modules gives Rootkit somewhat advanced capabilities, that are generally similar to those of stealth viruses. And they face a common problem -- more complex toolkits are more prone to crash and more affected by incompatibilities between different versions of the kernels. Much like file viruses writers of early nineties (remember Dark Avenger and his Eddy virus ;-) those guys are not capable of doing something really interesting, but some of them are pretty clever in their own perverted way. Here is listing of a more recent version of this crap from Devcon 2000:
AWESOME.C 08-Sep-2000 19:27 2k
B4B0.C 08-Sep-2000 19:27 3k
BDOOR.C 08-Sep-2000 19:27 4k
BJ.TXT 08-Sep-2000 19:27 1k
BOINFO.TXT 08-Sep-2000 19:27 6k
BOWZ4P.C 08-Sep-2000 19:27 3k
BUTTSNIFF_0_9_3.ZIP 08-Sep-2000 19:27 128k
CLOAK.C 08-Sep-2000 19:27 2k
CLOAK2.C 08-Sep-2000 19:27 11k
CWHO.C 08-Sep-2000 19:27 3k
DEAD.C 08-Sep-2000 19:27 1k
DEMONKIT_1_0.TGZ 08-Sep-2000 19:27 147k
DWARF.TGZ 08-Sep-2000 19:27 5k
FAKESYSLOG.C 08-Sep-2000 19:28 3k
FIX.C 08-Sep-2000 19:28 3k
FORCE.C 08-Sep-2000 19:28 2k
FWBACKDOOR.TXT 08-Sep-2000 19:28 27k
GENERIC_BUFFER.TGZ 08-Sep-2000 19:28 5k
HIDE.C 08-Sep-2000 19:28 3k
INV.C 08-Sep-2000 19:28 1k
INVIS.C 08-Sep-2000 19:28 1k
INVISIBL.C 08-Sep-2000 19:28 1k
LE.C 08-Sep-2000 19:28 2k
LOGIN.C 08-Sep-2000 19:28 19k
LRK4.TGZ 08-Sep-2000 19:28 879k
MARRYV11.C 08-Sep-2000 19:28 24k
MD5_TAR.Z 08-Sep-2000 19:28 34k
MME.C 08-Sep-2000 19:28 4k
NET/ 08-Sep-2000 19:27 -
NETB160.ZIP 08-Sep-2000 19:28 513k
NETBUS170.ZIP 08-Sep-2000 19:28 536k
PORTD.C 08-Sep-2000 19:28 26k
PORTMAP.C 08-Sep-2000 19:28 6k
REMOVE.C 08-Sep-2000 19:28 5k
RHCLEAN.C 08-Sep-2000 19:28 1k
ROOTKITLINUX.TGZ 08-Sep-2000 19:28 73k
ROOTKITSUNOS.TGZ 08-Sep-2000 19:28 68k
SCO_ZAP.C 08-Sep-2000 19:28 2k
SETTIME.C 08-Sep-2000 19:28 1k
SOCKET_DEMON13.ZIP 08-Sep-2000 19:28 21k
SPY.C 08-Sep-2000 19:28 3k
SSH_1_2_27_BD.DIFF 08-Sep-2000 19:28 17k
STEALTH.C 08-Sep-2000 19:28 1k
TCPB.C 08-Sep-2000 19:28 7k
TELNETD_HACKED.TGZ 08-Sep-2000 19:28 108k
TRANS.TBL 08-Sep-2000 19:28 1k
UCLOAK.C 08-Sep-2000 19:28 2k
UTMP2.PL 08-Sep-2000 19:28 1k
UTMPSPOOF.C 08-Sep-2000 19:28 2k
UTMPX.TXT 08-Sep-2000 19:28 4k
WIPE_1_00.TGZ 08-Sep-2000 19:28 4k
WZAP.C 08-Sep-2000 19:28 1k
ZAP.C 08-Sep-2000 19:28 2k
ZAPREC.C 08-Sep-2000 19:28 2k
Linux Rootkit IV comes with these Trojaned files and special utility programs
(taken from the README files):
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!
One typical oversight made by a lot of entry-level sysadmins is that after
installing and hardening their machines they fail to create a baseline of the
system configuration and burn a couple of CDs with vital directories. Althouth
you can use RPM for checking baselines, its not that convininet. You probably
would be much better off against intruders if you have a valid copy of major
/etc files (inted.conf is often trojanized, rc files are vulnerable too), /bin,
/usr/bin and a couple of other system directories. Create several HTML pages
with a typical usage of resources, ports and so. For example something as simple
as:
netstat -a -n > /root/Baseline/netstat-baseline
can give you a reference to latter check against and see if any additional ports are open.
But even if this is not the case, detecting rootkit it's not that difficult and DOS viruses experience can be quite helpful. As I mentioned before, those guys are not very original and mostly repeat tricks of the virus writers ten years later. And actually the more they try to hide the easier is to detect them as in more complex system something always go wrong even with a slightly different version of kernel.
The first thing to do is to get a normal bash. One way to do it is to mount
the CD-ROM with copy of /bin and /usr/bin tries and start a shell to work from.
For instance:
/mnt/cdrom/bin/bash -rcfile /mnt/cdrom/etc/bashrc
-noprofile -i
If you are lazy (I am ;-) you can just try to use tcsh as your shell instead of
bash (tcsh is not usually trojanized, but your mileage may vary).
After than you can try to use find from CD Rom detect suspicious files like "...". Please note that ls and find on the harddrive are usually trojanized.
There are a couple of free rootkit detectors. I recommend chkrootkit (http://www.chkrootkit.org/) -- a simple script that locally check for signs of a rootkit. It contains:
The following rootkits and worms are currently detected:
chkrootkit has been tested on: Linux 2.0.x, 2.2.x, FreeBSD 2.2.x, 3.x and 4.0, OpenBSD 2.6, 2.7 and 2.8, Solaris 2.5.1, 2.6 and 8.0. More details can be found on the chkrootkit's README.
There is also a useful little daemon called "rkdet" for Linux that monitors checksums for common Trojan targets (login, ls,netstat etc.)and can disable networking if triggered. Reporting is by email and syslog. See http://vancouver-webpages.com/rkdet/.
Normally in such cases it make sense to create a mirror installation on a separate box and burn a couple of CDs to verify the integrity of common directories. One machine then distribute binaries around the site. RPM has facilities for verifying that a package is not corrupt or has components missing. A program added or removed by a cracker will not match the original and RPM will generally report a verification failure. For example you can check if ps is Trojanized by using:
rpm -q -f /bin/ls/ -s | grep /bin/ls/
that assumes that RPM database (the files/var/lib/rpm/fileindex.rpm and /var/lib/rpm/packages.rpm) is intact.
If you are paranoid (I never saw a Trojan RPM executable but your mileage may vary) that it would be good to load rpm binary from CD or writeprotected floppy:
root# /mnt/cdrom/bin/rpm -Va
to verify each file on the system. Note that this will take a long time even of
a fast system: you definitely has can for a cup of coffee. Also the valiant
listed above is pretty verbose and probably you should redirect it to some file
and them analyze with grep. See the RPM man page,
as there are a few other options that can be included to make it less verbose. I
do not remember details,but you can find then on the WEB. Keep in mind that RPM
in this mode produces the following useful output fields:
You can try to get all "5" lines to see what modules were changed. Again if you are paranoid that every time a new RPM is added to the system, the RPM database needs to be burned on CD (the files/var/lib/rpm/fileindex.rpm and /var/lib/rpm/packages.rpm most likely won't fit on a single floppy. gzipped, each should fit on a separatefloppy) or re-archived. Also, keep in mind that it won't verify programs that RPM did not install. In future consider having this (as wellas the actual /bin/rpm executable) on a CD or a Zip cartridge.
There is also a bootable SuSe auditdisk with integrity checking tools and the checksums providing a very secure method to check for damage. It ships standard with SuSE and can easily be ported to other Linux distributions, and is GPL licensed. You can get SuSE auditdisk from: http://www.suse.de/~marc/.
Additional Information can be found in
Good luck !
P.S.
Dr. Nikolai Bezroukov
|
| 2007 | 2006 | 2005 | 2004 | 2003 |
About: Rootkit Hunter scans files and systems for known and unknown rootkits, backdoors, and sniffers. The package contains one shell script, a few text-based databases, and optional Perl modules. It should run on almost every Unix clone.
Changes: This release added support for RHEL WS/AS/ES 3 Taroon update 8, Fedora Core 5, and SuSE 10. Checks were added for packet capturing applications and processes using deleted files. The netstat check was enabled for AIX and the backdoor check was enabled for SunOS. Logfile specification and checks were added.
Trojans, rootkits, and DDoS agents are a sad reality. It's a little disheartening to think that software exists which, given a chance, can install unwanted files on your system, overwrite or destroy your own files, send your data or user input elsewhere, or use your computer to attack another system.The more advanced among you may be smiling and smugly thinking "that's why I run a Unix system". True, there are fewer nasties out there which target Unix systems, but they do exist. Further, as the Unix user base increases, so will the amount and frequency of exploits against Unix systems. Fortunately, as a FreeBSD user, there are many utilities available to you, as well as many good habits that you can teach yourself. The next two articles will discuss these utilities and habits.
RFC (Remote Filesystem Checker) is a set of scripts that aims to help system administrators run a filesystem checker (like tripwire, aide, etc.) from a "master-node" to several "slave-nodes" using ssh, scp, sudo, and few other common shell commands.
Cfg2html is a UNIX shell script that creates HTML and plain ASCII system documentation for software and hardware configurations. It supports HP-UX 10.xx/11.xx, SunOS/Solaris, AIX, SCO Open Server, Linux (SUSE, Debian, and RedHat), and NT4.0/Win2000 systems. Plugins for SAP R/3, Oracle, Informix, Samba and SWAT, ITO and NNM, XP48, XP256 & XP512, SureStore E, SuperDome, OLA/R, SCM, AutoRAID, FC60, Tip/X, MC/SG, and OmniBack are included.
radmind is a suite of Unix command-line tools and a server designed to remotely administer the file systems of multiple Unix machines. At its core, radmind operates as a tripwire. It is able to detect changes to any managed filesystem object, e.g. files, directories, links, etc. However, radmind goes further than just integrity checking: once a change is detected, radmind can optionally reverse the change. Each managed machine may have its own loadset composed of multiple, layered overloads. This allows, for example, the operating system to be described separately from applications. Loadsets are stored on a remote server. By updating a loadset on the server, changes can be pushed to managed machines.
As David O'Brian wrote in his paper Recognizing and Recovering from Rootkit Attacks
Installing Rootkit is one of the more popular activities of serious Internet intruders once they have obtained root privileges of a workstation running SunOS 4.x Unix or the Slackware Linux distribution. Rootkit's name suggests that it is a set of canned attack scripts for obtaining root access. However, Rootkit is really a collection of programs whose purpose is to allow an intruder to install and operate an Ethernet sniffer (a program that captures and decodes every packet on a network) on an unsuspecting SunOS 4.x or Solbourne host using /dev/nit or Linux host using the eth0 interface. With this sniffer, an intruder can obtain the userids and passwords, including root, to your most sensitive networked systems. In this article, I will discuss the various strains of Rootkit that I analyzed, how to recognize and detect an attacked machine, and how to recover from the attack.
O'Reilly Network Understanding Rootkits [Dec. 14, 2001]
check-ps home page The check-ps
program looks for rootkit versions of ps that cloak selected
processes. Hidden processes are a sure sign of intrusion, and check-ps
helps administrators detect an intrusion before too much damage is done. The
check-ps source code is available from:
http://checkps.alcom.co.uk/download.html
rkdet - rootkit detector for Linux
This program is a daemon intended to catch someone installing a rootkit or running a packet sniffer. It is designed to run continually with a small footprint under an innocuous name. When triggered, it sends email, appends to a logfile, and disables networking or halts the system. it is designed to install with the minimum of disruption to a normal multiuser system, and should not require rebuilding with each kernel change or system upgrade.
chkrootkit locally checks for signs of a rootkit. Includes ifpromisc.c to check and see if the interface is in promisc mode, chklastlog.c to check lastlog for deletions, and chkwtmp.c to check wtmp for deletions. Tested on Linux 2.0.x, 2.2.x and FreeBSD 2.2.x, 3.x and 4.0. Changes: lrk5 detection, Sun/Solaris support, and Red Hat fixes. Homepage:
rkscan Rootkit scanner for loadable kernel-module rootkits. Download
checkps. Development on checkps, a Linux rootkit detector, has recommenced. A new version is now available via CVS, containing a fix for a non-exploitable buffer overrun, in addition to other small fixes and features.
Also rootkit detector: The official url is: ftp://ftp.pangeia.com.br/pub/seg/pac/chkrootkit.tar.gz One variation for Demonkit (by daemon9|route) ftp://ftp.pangeia.com.br/pub/seg/pac/chkdemonkit.tar.gz
Copyright © 1996-2008 by Dr. Nikolai Bezroukov. www.softpanorama.org was created as a service to the UN Sustainable Development Networking Programme (SDNP) in the author free time. Submit comments This document is an industrial compilation designed and created exclusively for educational use and is placed under the copyright of the Open Content License(OPL). Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.
Standard disclaimer: The statements, views and opinions presented on this web page are those of the author and are not endorsed by, nor do they necessarily reflect, the opinions of the author present and former employers, SDNP or any other organization the author may be associated with. We do not warrant the correctness of the information provided or its fitness for any purpose.
Created: May 16, 1997; Last modified: June 05, 2008