Larry,
Let's define rootkit: The name for a kit of hacker utilities placed on
a UNIX machine after a successful compromise. A typical rootkit
includes: password sniffer log cleaners replacement binaries for
common programs on the system (e.g. inetd) backdoor programs
replacements to programs like ls and find so that they will not reveal
the presence of the rootkit files. Key point: A rootkit contains many
trojaned programs. These programs are used to allow the hacker entry
back into the system and to hide the presence of the hacker.
These legacy rootkit file tools like lsattr, chkrootkit, and rkhunter
are no longer that useful.
As a practical lab, it would be trivial to obtain and install [say on
a Vmware image] one of the packages listed below and run these tools
against it. We will find that they simply find false positives.
Why?
Since it's fairly easy to assemble linux binaries and add additional
functions and features, all files are suspect, even those that "look"
completely reasonable.
The rootkit hunters also seem to provide a false sense of security.
The CRC fie check tools like Tripwire and Labrador are still well
utilized. They require a base file check right after installation
before being placed into production on a network.
They take a CRC signature for all systems binaries and report from
later scans (scheduled from cron or manually kicked off) if something
has changed.
While it's not impossible to obtain source code and recompile a binary
with the same CRC signature, it's not easy. CRC changes are the most
comprehensive signs of hacked binaries or rootkits.
A great many other rootkits are actually created as modules:
http://alexids.googlecode.com/files/WRITING_A_SIMPLE_ROOTKIT_FOR_LINUX.pdf
Some use existing processes (syscall)
http://memset.wordpress.com/2010/12/28/syscall-hijacking-simple-rootkit-kernel-2-6-x/
Others infect the MBR of the system:
http://linuxpoison.blogspot.com/2008/03/most-dangerous-rootkit.html
These are difficult to find - since they require a low level file
system analysis.
If you use rsync or dd to create images or copy files, you will infect
your new systems unknowingly.
Other References:
http://lida.sourceforge.net/ Disassembler Tool
http://www.ossec.net/rootkits/studies/lrk5.txt Linux Rootkit IV 1998
http://www.ussrback.com/UNIX/penetration/rootkits/ Complete source for
a list of rootkits
On 7/29/11, Joseph Sinclair <
plug-discussion@stcaz.net> wrote:
> What you see below is false-positives.
> The files in /usr/lib are normal files used for things like initialization
> control (pymodules) and JDK selection (jvm).
> The files in /dev/shm are pulsaudio temporary device files, and like
> everything in /dev/shm will disappear on a reboot (/dev/shm is a filesystem
> interface to shared memory).
> The hidden directories are likewise normal (java, udev, initramfs) elements
> of the system.
>
> That's why these things are warnings; they *might* be a problem, but the
> software has no way to be sure (although it really should have exceptions
> built-in for things like pulseaudio, udev, and initramfs stuff).
>
> Then again, it's fundamentally impossible to know if a system is clean from
> within that system (since a rootkit could just intercept any call that would
> expose it's presence and return a false result).
> Usually these tools should be run against a chrooted/mounted filesystem from
> a known-good rescue CD.
>
> On 07/29/2011 08:48 AM, Dazed_75 wrote:
>> One of the blogs I read just had an article about finding rootkits in
>> Linux. While not worried about it, I thought it would be fun to check it
>> out. They talked about 3 commands; lsattr, chkrootkit, and rkhunter.
>>
>> lsattr didn't find anything of interest the few directories I tried it on
>> except that this line showed up for some files (I think they were all
>> links):
>>
>>> lsattr: Operation not supported While reading flags on /bin/bzegrep
>>>
>>
>> chkrootkit found
>>
>>> ROOTDIR is `/'
>>> Searching for suspicious files and dirs, it may take a while... The
>>> following suspicious files and directories were found:
>>> /usr/lib/xulrunner-1.9.2.18/.autoreg
>>> /usr/lib/firefox-3.6.18/.autoreg
>>> /usr/lib/pymodules/python2.6/.path
>>> /usr/lib/pymodules/python2.6/PyQt4/uic/widget-plugins/.noinit
>>> /usr/lib/jvm/.java-6-openjdk.jinfo
>>> /usr/lib/thunderbird-3.1.11/.autoreg
>>>
>>
>> those are mainly empty files and the ones that were not seemed reasonable
>> to
>> an uneducated eye. Problem is that they don't say what it is that is
>> considered suspicious
>>
>> rkhunter -c found
>>
>>> [08:27:47] Checking /dev for suspicious file types [ Warning ]
>>> [08:27:47] Warning: Suspicious file types found in /dev:
>>> [08:27:47] /dev/shm/pulse-shm-3633543672: data
>>> [08:27:47] /dev/shm/pulse-shm-2330444361: data
>>> [08:27:47] /dev/shm/pulse-shm-2759599877: data
>>> [08:27:48] /dev/shm/pulse-shm-2688255106: data
>>> [08:27:48] /dev/shm/pulse-shm-2964324177: data
>>> [08:27:48] /dev/shm/pulse-shm-878858236: data
>>> [08:27:48] Checking for hidden files and directories [ Warning ]
>>> [08:27:48] Warning: Hidden directory found: /etc/.java
>>> [08:27:48] Warning: Hidden directory found: /dev/.udev
>>> [08:27:48] Warning: Hidden directory found: /dev/.initramfs
>>>
>>
>> Similar comment. It is difficult to know what to check for. Again I am
>> not
>> worried, just curious.
>>
>>
>>
>> ---------------------------------------------------
>> PLUG-discuss mailing list - PLUG-discuss@lists.plug.phoenix.az.us
>> To subscribe, unsubscribe, or to change your mail settings:
>> http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
>
>
--
(602) 791-8002 Android
(623) 239-3392 Skype
(623) 688-3392 Google Voice
**
HomeSmartInternational.com <
http://www.homesmartinternational.com>
---------------------------------------------------
PLUG-discuss mailing list -
PLUG-discuss@lists.plug.phoenix.az.us
To subscribe, unsubscribe, or to change your mail settings:
http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss
(text/plain)