>>>>> "jl" == Jamie Lawrence <jalat_private> writes: jl> I'm helping with a Solaris 8 box that was rooted. jl> The attacker replaced the /usr/bin/mc680*0 binaries, jl> so many of the usual administrative commands are jl> misbehaving. Is this from a rootkit anyone has seen jl> before? jl> This is a production box, and has to stay up for a while jl> yet (the usual bad sort of administrative neglect), so reinstalling jl> from scratch is not an approach I can take this minute. jl> I'm just looking for pointers on what I can expect, so I can jl> hopefully temporarily plug some holes until the box can jl> be rebuilt. If possible, shut the box down and either mirror the internal drive to an identical disk, or at least MD5 everything on the disk. This will keep downtime to a minimum. It is critical that you do this NOT booted off the compromised disk, but off CD or other trusted media. If even that minimal amount of downtime is unacceptable, dd the disk out to somewhere else, preferably across the network. Since this box is owned, and kernel modules can do just about anything they want to, anything is possible. However, it's much harder to hide things from programs that don't go through the filesystem. find, ls, etc all use the standard system calls (open(), readdir(), stat(), etc.) and are suspect. dd on the raw disk device will use these same system calls, but the data that you are interested in will come across as a chunk from a read() system call, not the return value of a stat() or readdir(). This is significantly more difficult (but not impossible) to trojan. dd across the network to avoid writing a large file to local disk, sucking up all your slack space, and making file undeletion more difficult later, when you can take the box down. Once you've got the image, check out lofiadm. This is a new facility in Solaris 8 which will allow you to mount the dd images as raw filesystems. Do this on a trusted box, and you can use find, grep and all your other favorite tools. Nmap the box from something else on the local network. Local root kits can lie to local admins, but an open port is open. I've found some bad solaris kernel module based rootkits that fail to properly hide themselves. Run modinfo and modinfo -c, and compare their output. If you've got something that shows up in modinfo -c, but not in modinfo, unload it. ericb -- Eric Brandwine | Natives who beat drums to drive off evil spirits are UUNetwork Security | objects of scorn to smart Americans who blow horns to ericbat_private | break up traffic jams. +1 703 886 6038 | - Mary Ellen Kelly Key fingerprint = 3A39 2C2F D5A0 FC7C 5F60 4118 A84A BD5D 59D7 4E3E ---------------------------------------------------------------------------- This list is provided by the SecurityFocus ARIS analyzer service. For more information on this free incident handling, management and tracking system please see: http://aris.securityfocus.com
This archive was generated by hypermail 2b30 : Mon Feb 25 2002 - 13:40:57 PST