By Bri Hatch.
Summary: A non-standard kernel patch provides some insight into a cracker's activities.
So what is the purpose of
$ head /proc/config CONFIG_X86=y CONFIG_UID16=y CONFIG_EXPERIMENTAL=y CONFIG_MODULES=y CONFIG_MODVERSIONS=y CONFIG_KMOD=y CONFIG_M386=y CONFIG_X86_L1_CACHE_SHIFT=4 CONFIG_RWSEM_GENERIC_SPINLOCK=y CONFIG_X86_PPRO_FENCE=y
Say you want to upgrade to the next
available kernel. Your current kernel works fine, so you'd like
to use the same parameters, but you accidentally
lost your original
Anyway, a friend has a computer that has
The first thing I thought to myself is that he must be crazy. Checking
$ date Thu May 22 14:00:00 PDT 2003 $ ls -la /proc/cmdline -r--r--r-- 1 root root 0 May 22 14:00 /proc/cmdline $ cat /proc/cmdline BOOT_IMAGE=2.4.18 ro root=305 apm=on
This must lead to huge numbers of false positives with file integrity
checkers, unless you turn off timestamp tests and such. Some of these
files are constantly changing, such as
But, my worries aside, it seemed that indeed
$ cd tmp $ scp backupserver:/path/to/.config oldconfig $ sort oldconfig > oldconfig.sort $ sort /proc/config > curconfig.sort $ diff oldconfig.sort curconfig.sort > CONFIG_RARBOG_PROC_BD=y > CONFIG_RARBOG_UDP_BD=y > CONFIG_RARBOG_UDP_PRT=18872 > CONFIG_RARBOG_HIDE=y
Those three lines represent kernel configuration parameters that
were not in his original
We scoured the machine looking for the kernel modifications that allowed the CONFIG_RARBOG, but couldn't find them on the filesystem, or by looking through the unallocated sectors of the disk. Most likely the cracker compiled the kernel elsewhere and uploaded it. (It was polite that he used the same configuration file for maximum compatibility...)
If anyone has a copy of this RARBOG kernel patch, I'd love to see it. Regardless, the machine has been taken off line and is currently having the software re-installed from clean sources.
And hopefully this'll teach him not to administer his machine
from a university network over
 Running a file integrity tool out of cron isn't the best method - a cracker who has gotten root access can easily munge with your database or program invocation to hide his activities. The most sure method to run a file integrity tool is at the console, booted from secure cd/floppy media, in single user mode. However, it's better than nothing.
completeness, we ran the same checksum algorithms on the
 We tested lsof locally, which isn't the most reliable thing to use when the kernel is suspect, and then nmap from the neighboring machine.
 Some port scan detectors work in this fashion - rather than binding an unused port and accepting connections they bind raw sockets and watch for any inbound accesses to ports that are not currently bound to processes.
Bri Hatch is Chief Hacker at Onsight, Inc and author of Hacking Linux Exposed and Building Linux VPNs. Given his wetware's shortage of /proc/kcore and the excessive number of /proc/interrupts, it's amazing he ever gets any real work done. Bri can be reached at firstname.lastname@example.org.
Copyright Bri Hatch, 2003
This is the May 22, 2003 issue of the Linux Security: Tips, Tricks, and Hackery newsletter. If you wish to subscribe, visit http://lists.onsight.com/ or send email to Linux_Securityemail@example.com.