[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Long Exim break-in analysis



On Wed, Dec 22, 2010 at 2:06 PM, Bastian Blank <waldi@debian.org> wrote:
> This looks like the rootkit I found somewhere in the internet:
> | 137a3bbda16034d34307a9d686e6fdb45b3c8683  procps/free
> | 5db25350dd15d3f1e63a4ff44fa85b72c21df72d  procps/kill
> | eeab165a2cf06feb327fa996f35271c076e992bc  procps/pgrep
> | eeab165a2cf06feb327fa996f35271c076e992bc  procps/pkill
> | a6569d433351bba70ae55738b47267bf2514e27e  procps/pmap
> | 074896d923ec652046c60cdcd254ff01c497bee9  procps/ps
> | bbb33300c5d8f53a60fe472b6b879c9853b26c57  procps/pwdx
> | 5db25350dd15d3f1e63a4ff44fa85b72c21df72d  procps/skill
> | bd8e998354f28f5f7216688f3a4b6e4007170d63  procps/slabtop
> | 5db25350dd15d3f1e63a4ff44fa85b72c21df72d  procps/snice
> | bbf9b74494b4669c663c19cc53fd1fef9e585d2a  procps/sysctl
> | c32f4ed4efa1305a2e9876b640e90fb9836a9f05  procps/tload
> | 3c84c94470376612507d39fbe7a227465a516525  procps/top
> | eb17b3b64913e7fa0d4b43a467a2548f96670a2e  procps/uptime
> | 9815f97ed37553c7915e2e35dfaadab796aac864  procps/vmstat
> | f7754627d890a393f0a917eaebbffdf458b6ce4d  procps/w
> | c480eefa72eb62183fb6e26cd8d68c58fefc26e0  procps/watch
>
> The initial checks shows 32-bit static binaries, built on RHEL 4, update
> 7 and 8.

Mine's a little different, but its an exact match on the file names at
least. The files are hige, at least 400k. Might be unstripped, haven't
checked yet.

> Something left behind in /var/spool/exim4?

Yup. I found the rkit.tgz tarball and the setuid.c code in
/var/spool/exim. The setuid.c program drops to root and adds a key to
root's authorized_keys.

The rootkit includes something called mig, which seems to be a tool to
clean wtmp with. Possibly to avoid detection of the login with the
newly added key.

The rootkit has an install.sh that is actually very well put together.
It checks for the usual rc.local scripts and adds itself to those, and
failing that, it adds /etc/init.d/xfs3 and installs it with
update-rc.d. Nice touch. This init script simply starts the dropbear
process and opens the firewall by inserting a rule at line 1.

But there is one bit that gets me. It does this:

mkdir -p /usr/include/mysql
echo dropbear >> /usr/include/mysql/mysql.hh1

It never does anything with that file, and that file does not exist on
a real system, so its almost like its leaving behind its business
card?

Now that the adrenaline rush is over, time to get back to other income
generating activities :-)

Cheers,
Izak


Reply to: