On Sat, Jul 30, 2011 at 9:11 AM, Lisa Kachold <lisakachold@obnosis.com> wrote:

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.

Yes, I understood this but this is a nice succinct description I suspect may be very useful for a lot of folks. I hope you don't mind if I plagiarize it sometime. And it is handy to have it here is this thread. Thanks.

These legacy rootkit file tools like lsattr, chkrootkit, and rkhunter
are no longer that useful.

Nevertheless, I suspect they are not totally useless. My biggest gripe is that they give no indication of WHY they CONSIDER a particular item to be suspicious. In other words, people like you and Joseph and other probably understand the WHYs, but others do not. I would like to see the output from these and similar programs (such as those you list below) include something in their output to say what rule or tenet which causes them to consider a thing suspicious. For example, a statement or reference to documentation that says use of shared memory is a potential security risk.

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.

As is stated in the article I read about them. Again, I was not worried or looking for info on rootkits. It just happened to be mentioned in an article on a blog site I read frequently:
http://maketecheasier.com/check-for-rootkits-on-linux-bsd-and-osx/2011/07/28

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.

Probably true as do all antivirus programs and firewalls etc.

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.

Cool, I never heard of these things. I wonder how easy and reasonable it might be for them to get into general usage BEFORE we start seeing more attacks on Linux, OSx and the like. What would it take to get support from major distros and/or to do so securely? Like you say nothing is a guaranty, but why wait until we are bigger targets? I see Tripwire and systraq but not Labrador in the Ubuntu repositories. I don't plan to do any such things but it is certainly on the table to learn about.

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