New Release of 'Unhide' (20080519) [LWN.net]

New Release of 'Unhide' (20080519)

Posted Jun 28, 2008 20:45 UTC (Sat) by zlynx (subscriber, #2285) [Link]

Many of the kernel rootkits miss things, like the "kill" syscall.  That's what is meant by
syscall probing.

Better than probing from userspace though, is to load a root-kit scanning module that will
examine the kernel memory structures directly and compare with /proc/ output.

New Release of 'Unhide' (20080519)

Posted Jun 29, 2008 1:19 UTC (Sun) by k8to (subscriber, #15413) [Link]

nmap probes ports in a brute force fashion from outside.  This attempts to open all possible
available ports to determine if there are any ports which are actually in use but not listed
in the tools.

From internal or external; they are both brute force

Posted Jun 29, 2008 11:05 UTC (Sun) by AnswerGuy (guest, #1256) [Link]

... however each has its pros and cons.  A local syscall scan trying to bind to each port (on
each interface as well as the catch-all *) uses not bandwidth and is not subject to any
interference by routers or switchgear.  It's likely to be faster.  However, it could miss some
particularly clever kernel level hacks (perhaps designed to allow the bind() and silently
insert itself as a man-in-the-middle?)  A scan from an external source will miss trojans that
use a portknocker (or similar) technique (it only temporarily opens the hidden port when a
"magic" sequence of apparently unrelated traffic has been sniffed).  An IDS (Snort, et al.)
may catch portknocked hidden traffic (if it's configured well enough and the traffic to/from
the hidden port isn't lost in the noise of other traffic, including the ever growing
"background radiation" of scanning and "doorknob twisting" that's inundating the public
Internet.

There's no magic bullet.  But unhide sounds like it can be a useful tool to be integrated into
chkrootkit and/or rkhunter (as well as being available on its own).

New Release of 'Unhide' (20080519)

Posted Jun 30, 2008 6:27 UTC (Mon) by drag (subscriber, #31333) [Link]

> Got nmap?

> When do I get my frontpage time?

Nmap ain't going to work. It used to be that people would setup a little telnet server or irc
server on a rooted system to provide remote control access in a automated fasion.

Nowadays they've gotten much more sophisticated. For example installing a trojan'd version of
apache that allows them to issue commands to and from the server using specially crafted
packets over the http or https protocol. thus making them very difficult to detect and able to
penetrate reverse proxies and such things.

But, ya, otherwise these 'rootkit detector' things are pretty much worthless in terms of true
security. I don't scoff at people working on them or using them.. it just adds that extra
level of difficulty on the part of the malware author. But nobody should depend on them. All
of them are quite able to be subverted by kernel-level rootkits. A person who trusts these
tools can have their trust used against them.

The only things that can work, at this point, is host-based and network-based IDS.

And of course they have to be used correctly. Having your snort system running the same
services and OS as the machines it's protecting is stupid... it shouldn't even by accessable
by the network it's monitoring. And things like tripwire need to be ran from read-only
bootable media or have the harddrive removed and tested in another (non-networked) machine.
(basically because you can't trust any software or checksum databases on a host machine..
including any IDS (or rpm or dpkg checksums for that matter)

In the future things like TPM should be able to be used to verify a system during a reboot or
something like that. As long as they are used correctly, also.

Confirmation vs. Assurance

Posted Jun 30, 2008 7:40 UTC (Mon) by AnswerGuy (guest, #1256) [Link]

When I use these or explain them to others (IDS tools, root kit detectors, anti-virus tools,
etc) I emphasize their limitations to my audience/custmers:

They can confirm that something *is* wrong and perhaps identify *some* of the issues.
However, they cannot offer any assurance that nothing is wrong.

When you see rpm -V checksum failures you know something has diddled with your file contents
(or you have a corrupted RPM/db). However the absence of these messages tells you nothing
about the integrity of the files (except that there hasn't been naive, ham-handed changes to
them). Ironically the complete absence of checksum and other flags from rpm -Va would be a
huge red flag for me (on a Red Hat system). An rpm -V immediately after a fresh install and
before any edits will, nonetheless, show a number of files, including some non-configuration,
which will be flagged as having deviant contents, permissions, etc. (When recommend creating
a baseline after imaging and before deployment; but usually I'm just rely on my own experience
and look at it heuristically --- since often people are calling on me to look at their systems
after they are already suspect).

Similar considerations apply to all manner of host integrity checking systems, anti-rootkit
modules and just about any other security feature. You can't *know* that it's not compromised
(did you install from CD or DVD? How can you be sure that it was not a clever forgery? Are
you absolutely sure of your vendor? Of your vendor's vendors? etc).

However, when you run chkrootkit or rkhunter and it identifies a specific root kit ... then
usually it's very easy to take that to management and convince them of the gravity of the
situation.