LWN: Comments on "A new Adore root kit"

A new Adore root kit

X-Kernrootkit — 2007-02-04T10:16:23+00:00

I AM TRYING TO INSTALL adore-ng0.54 on fedora core6 its giving me lots of errors
such as
adore-ng-2.6.c:546: error: current undeclared (first use in this function)
adore-ng-2.6.c:550: error: dereferencing pointer to incomplete type
adore-ng-2.6.c:550: error: dereferencing pointer to incomplete type
adore-ng-2.6.c: In function patch_syslog:
adore-ng-2.6.c:565: warning: implicit declaration of function sock_create
adore-ng-2.6.c:568: error: dereferencing pointer to incomplete type
adore-ng-2.6.c:569: error: dereferencing pointer to incomplete type
adore-ng-2.6.c:570: error: dereferencing pointer to incomplete type
adore-ng-2.6.c:571: warning: implicit declaration of function sock_release
adore-ng-2.6.c: At top level:
adore-ng-2.6.c:583: error: expected =, ,, ;, asm or __attribute__
etc
please help

A new Adore root kit

duanjigang — 2006-05-23T07:14:49+00:00

like hacking technologies, thoughts more than codes, but codes are
the proof of what the author said Thank you!

A new Adore root kit

xian1990@yahoo.com — 2005-10-17T18:07:00+00:00

What version of Linux kernel does Adore affect?

Allowed modules list

jcm — 2004-10-25T00:44:51+00:00

Hi all,

It's worth noting that the issue of signed modules has recently cropped up in a debate on lkml. It looks as though something will eventually go mainstream - but what form it'll take is still subject to list wrangling.

Cheers,

Jon.

urgh

arafel — 2004-10-04T13:25:16+00:00

Give someone sufficient privileges to load a kernel module, and I can guarantee that, if they really want, it will be loaded one way or the other. Bear in mind that any code which you can write to check for an 'allowed' module list can simply be changed to always return 'yes, that module is okay'.

disabling /dev/mem

jhs — 2004-09-30T13:58:51+00:00

The workaround is, lsof is a troubleshooting tool, like tcpdump. It should not be on a production system. If you have a problem, use lsof on your test environment until you fix the bug.

A new Adore root kit

alterself — 2004-04-03T00:30:48+00:00

The idea is not that you bind to the port... but that you log attempts to open the port.

On a normal tcp/ip stack... the stack sends a request denied on attempts to open closed ports. I would imagine that if the module tied into the tcp/ip stack, it could monitor for attempts to open a specific set of ports...

A new Adore root kit

trolldbois — 2004-03-26T10:57:32+00:00

And why doesn't adore prevent kstat from reading useful information from /dev/kmem ? ;)

A new Adore root kit

Kstat — 2004-03-25T10:11:36+00:00

Sorry to kill the myth, but adore is very easy to detect (at least 3 differents ways). Of course, If the adore rk is sligly modified it will be more difficult to find :).

I let you goole on how to easyly find adore :)

Kstat <- check for this too, this is a good tool to detect adore :)

A new Adore root kit

jzbiciak — 2004-03-24T06:38:58+00:00

Won't it at least have to bind to the first port of the "knocking" sequence?

A new Adore root kit

shapr — 2004-03-21T01:07:58+00:00

You could put the trusted kernel on a bootable cdimage, and set the BIOS to boot from CDROM, where the trusted kernel would only start the system on the hard disk after all checks passed.

That would work for chkrootkit at least, and it would beat the "save to disk on shutdown" trick.

A new Adore root kit

xorbe — 2004-03-19T04:00:20+00:00

Not if the module doesn't bind to the port until it sees the secret knock goes by. That's the whole point...

Chkrootkit on Live system???

AnswerGuy — 2004-03-19T02:02:52+00:00

I will find this out for myself later, but I really wish the author had
reported whether chkrootkit detects this new Adore on a live/compromised
system.

It can detect many of them. Of course a clean boot is far more dependable
but chkrootkit is cheap to run from cron (suitable obscured from the
cracker's scripts, of course).

Clean boot scans, chkrootkit, and RAID Hotswap For FIDS

AnswerGuy — 2004-03-19T01:59:05+00:00

Of course running chkrootkit and/or AIDE or other checksum scanners from
a clean boot will help find compromised files and *known* rootkits.

However, that impinges on uptime for 24x7 servers. There should be
scheduled downtime and such clean boot scanning should be routine during
those downtime windows.

It's possible, with hotswap capable mirror (RAID1) to yank a drive,
insert it into a scan system, force it to come up in degraded mode
as a mountable (non-system) drive and then scan that.

(Put in a spare on the production system and let it re-integrate to
preserve the array and performance).

If it's true hotswap hardware you can do this. If it's soft raid and
you try commands like raidsetfaulty, etc. then you risk the attacker
hooking into that and covering his traces.

I'm surprised I've never seen an article published on this technique,
I've been describing it for years and tested it a couple times. (I'm
not maintaining any production systems in this configuration).

JimD

LIDS, SELinux, etc

AnswerGuy — 2004-03-19T01:51:03+00:00

It's not quite true that root-compromised systems *have* to be
inherently, persistenly compromised. It's CLOSE to true; but
some features in LIDS and SELinux could protect a well configured system
even from a rogue root process. These patches work by limiting root's
power and imposing additional authentication/authorization measures for
some operations.

JimD

Signed modules, "Sealed" mode etc

AnswerGuy — 2004-03-19T01:46:52+00:00

There are various patches such as LIDS and (DSIGN?) that limit
allowed modules or "seal" the kernel after boot and refuse to let
modules load or do digital signature checks before linking into
loadable modules. (The capability bounding set is a coarse grained
measure in this direction --- but it's the only one in a stock
kernel).

There are many countermeasures to each of the steps that any
rootkit takes. Of course they must be deployed before the
compromise! :(

SNORT or Prelude NIDS

AnswerGuy — 2004-03-19T01:42:07+00:00

I hate to respond to my own post but I forgot something that I'd
intended to say (hit the preview/submit buttons a little too quick)

This is one of the best reasons to run a tight SNORT Prelude
configuration. The default NIDS code is sort of like virus scanners
in that they only tell you about KNOWN attack signatures. However,
you can make a SNORT configuration that's more like a checksum
integrity tool (like Tripwire, AIDE or Samhain, only for net traffic).

Basically you have to be able to characterize, in detail the proper
and expected behavior of the protected system(s). A profile
of everything it should be allowed to do on the net. For example a
web server might need:

Inbound:
dst port 80 or 443 from anywhere,
dst port NTP from (list of three to give NTP peers),
dst port SSH from (list of two or three sysadmin workstations
and/or staging servers)
dst port SNMP from (list of NMS systems)
Outbound:
dst port any from port 80 or 443 (http and https)
dst port CVS (perhap for automated checkout of new changes
which are checked in by webmasters, web authors, programmers, etc.
dst port DNS to (list of internal name servers) (for reverse lookup?)

... and so on.

Once done properly ANY traffic that doesn't fit these rules will
be an alert on the NIDS (network intrusion detection system).
(Unless it also exploits a bug in your NIDS, which is hopefully
pretty hard to do these days).

Of course this sort of Draconian/totalitarian configuration is only
suitable for highly specialized servers. The more services running
on a machine the harder it is to characterize it's traffic. For most
client systems (workstations) ... FORGET IT!

I hope its clear why this works better than looking for bad traffic.
Here we look for "not good traffic." (Similarly one of the first
rules of secure and robust programming for parsers is that it's better
to suppy a list of known innocuous characters, tokens whatever, then
to attempt to filter out a list of "suspects").

JimD

Allowed modules list

giraffedata — 2004-03-19T01:40:39+00:00

A list of allowed modules won't help much if a user has root privileges.

It would if you implemented the rest of the proposal, which was to make the kernel not allow updating of this list by anyone. It was, of course, left vague how you might design something like that.

With any *nix once root is obtained the system is completely compromised.

That's very on-point. It's why the best reaction to this type of threat is to make it harder to "obtain root," by making "root" far less pervasive in a system.

Linux took steps toward this long ago by replacing the traditional Unix concept of superuser/not superuser with a set of fine grained capabilities. As has been pointed out, if you had every one except CAP_SYS_MODULE, you would not be able to install Adore. And if only processes that needed CAP_SYS_MODULE had CAP_SYS_MODULE, it would be next to impossible for the cracker to find one that he can trick into loading Adore.

It isn't customary on Linux systems to manipulate individual capabilities, but it should be.

For that matter, there's still a whole lot of code running with full capabilities that doesn't need any of them at all. I.e. it should "drop root."

One thing I don't know the status of: capabilities assigned to executables. Last I saw, if you need a privileged program, you have to make it setuid/owner 0 and then whoever executes it gets ALL capabilities. We need to do better than that.

Port knocking

AnswerGuy — 2004-03-19T01:24:03+00:00

If the attacker wants to run a custom service (not some commodity like a warez FTP or IRC node) then he can use a "port knocker" to obscure it from scanning. Basically the ports appear closed but some magic sequence of packets (could be anything that the port knocker module will see, including DNS response packets from a magic source address, think of an ipchains rule that logs such packets and a tail -f script that monitors the logs for them, then opens the port for a limited time and possibly to a limited address. --- now just hide that a little better. Presto! port knocker!)

Of course they can run any service on any port using this technique, it's
just that the clients have to have the right "knocker client" script (generally just something for netcat, socat, or perl's net libraries). They have to know the "secret knock" (Shave and a haircut ...)

A new Adore root kit

rjamestaylor — 2004-03-18T23:17:54+00:00

Is something wrong with this article? I tried to read it, and as soon as the browser window opened, it closed again. I tried using wget to get the source, and it gave me a weird error. Then I tried googling for "adore rootkit" and it came up empty. I tried emailing someone about it, and as soon as I typed "Adore", my email client crashed.

Help, please. I have no idea what's going on!

Warning! You must act quickly! Someone has surruptiously installed Microsoft Windows on your computer!

Allowed modules list

LogicG8 — 2004-03-18T22:24:50+00:00

A list of allowed modules won't help much if
a user has root privileges. With any *nix once
root is obtained the system is completely
comprimised.

For those interested in patching the kernel w/o LKM
http://www.phrack.org/phrack/58/p58-0x07

A new Adore root kit

RobSeace — 2004-03-18T17:28:18+00:00

I loved your idea so much, I whipped up just such a thing as a quick Perl script: http://www.magrathea.com/~ras/misc/rpscan... ;-)

Perl isn't my strongest language (I usually write pure C code), but it seemed like the best bet for such a quick and dirty task... But, any strong Perl coders, forgive any obvious mistakes on my part... ;-)

A new Adore root kit

freethinker — 2004-03-18T14:09:03+00:00

Help, please. I have no idea what's going on!

;)

What protection does module versioning provide?

rankincj — 2004-03-18T13:21:38+00:00

How would the attacker arrange for the module to get silently reloaded after a reboot? Wouldn't they need to hook something into your init scripts somehow? And what happens when you upgrade or recompile your kernel? You may be able to force an insmod of Adore's modules, but there's no guarantee that they would still work.

A new Adore root kit

fergal — 2004-03-18T11:56:04+00:00

What would be needed is a "reverse port scanner". Something that runs on the machine and attempts to bind to address:port for every address and port on the machine. The secret port will show up as already in use.

A new Adore root kit

copsewood — 2004-03-18T11:53:01+00:00

Presumably hidden files would show up if the system is booted using a trusted kernel and the file system scanned with a scanner that knows where to look for them and what to look for ? I seem to remember having to do this reliably to detect MSDOS infection by certain viruses a few years ago. The problems with this approach are a bit of routine downtime while you run this kind of thing, maintaining separation between the potentially compromised and trusted scanning environments, and keeping malware scanning software up to date. Alternatively if the evidence is on the disk and the same disk can be simultaneously mounted read-only using another otherwise isolated system a similar security scan could be done without downtime. This will probably be followed by versions which remove themselves from disk when they load themselves into memory, and resave themselves to disk when the systems shut down.

So I guess other defences might have to involve virtualising the environment and running this within a sandbox continually monitored for known attack signatures.

These precautions all put up the cost of running computing environments which retain similar levels of reasonable trust prior to discovery of this kind of technique.

Allowed modules list

nix — 2004-03-18T11:31:29+00:00

Anyway, this solution is not quite feasible for most ordinary users: configuring the kernel with its hundreds of options is tedious, and I have found it can be difficult to decide what drivers or features can be disabled safely. The result is also less flexible when new hardware is installed. So I do not think the statical kernel a very practical solution for most users.

This may well be true for general-purpose systems (although I haven't found it so), but firewalls, at least, can run with module support removed (no matter what their hardware: if necessary, run the firewall as a UML instance with no module support. UML's not *quite* secure, and won't be until lcall syscalls can be virtualized, but it's damned close.)

disabling /dev/mem

ballombe — 2004-03-18T10:24:10+00:00

One of the caveats of disabling /dev/mem was that lsof
did not work anymore. Is there any workaround available ?

Allowed modules list

eru — 2004-03-18T09:22:52+00:00

If you're really concerned, a better solution is to link everything you need into your kernel and disallow modules altogether.

But I recall that some time ago LWN (or possibly some other Linux web page, not sure) reported discussions among kernel developers about deprecating the making of statical kernels altogether. Did that already happen with 2.6? Is it likely to happen?

Anyway, this solution is not quite feasible for most ordinary users: configuring the kernel with its hundreds of options is tedious, and I have found it can be difficult to decide what drivers or features can be disabled safely. The result is also less flexible when new hardware is installed. So I do not think the statical kernel a very practical solution for most users. Other alternatives are needed for securing against rootkit modules..

Allowed modules list

sweikart — 2004-03-18T07:01:46+00:00

>In either case, however, you must contend with the fact that it is still 
>possible to patch code into the kernel without loading a module via /dev/mem.

To block access through /dev/mem, just drop the sys_rawio capability.  [You
might even be able to drop sys_rawio after starting X; I've only dropped it 
on servers.]

Some good references are:
   http://lwn.net/1999/1202/kernel.php3
   http://lwn.net/2000/0629/backpage.php3  # Subject: disabling module loading

Allowed modules list

mebrown — 2004-03-18T04:19:01+00:00

Compile out support for /dev/mem?

or,

Arjan has patches for 2.6 in the RH kernel that allow access through /dev/mem to only the first 1MB of memory (for tools that look at BIOS info, eg SMBIOS), and non-RAM memory (X drives PCI cards using IO through /dev/mem).

Allowed modules list

mattdm — 2004-03-18T04:12:09+00:00

Hmmm, yeah, I vaguely remember reading about that.

So, is some sort of hardware-based code signing really the only thing that can be done? Other than "don't let bad people get root", of course.

Allowed modules list

corbet — 2004-03-18T03:32:10+00:00

If you're really concerned, a better solution is to link everything you need into your kernel and disallow modules altogether. A weaker alternative is to load your modules at boot time, then disable module loading via the capability bounding set.

In either case, however, you must contend with the fact that it is still possible to patch code into the kernel without loading a module via /dev/mem.

urgh

mattdm — 2004-03-18T03:27:22+00:00

I'm no kernel hacker, but it seems like something like this would be a good thing:

In /etc somewhere, have a file containing checksums of modules which are allowed to be loaded in the kernel. Then, some kernel mechanism to read this file _once_ -- and once read, make it impossible to add to the list without a reboot.

This would be far from perfect protection, but seems like it'd provide another layer of protection -- the attacker would have to reboot the system, which is at least noticable.

It'd also be kind of a pain for third-party drivers, but....

A new Adore root kit

mikeraz — 2004-03-18T02:13:58+00:00

What can we look forward to? It seems the only way to detect an Adore compromised system would be through a Nessus, or other port scanning tool, port scan detecting open ports. But if the Adore designers were to implement port knocking they could hide from that detection method also. Detection of a compromise would be very difficult then.