Mambo Exploit Blocked by SELinux

If you operate Internet-connected servers, chances are you eventually will have to deal with a successful attack. Last year, I discovered that despite the multilayered defenses in place on a test Web server (targetbox), an attacker had managed to use an exploit in a partially successful attempt to gain access. This server was running Red Hat Enterprise Linux 4 (RHEL 4) and the Mambo content management system. It had multiple defenses in place, including Security-Enhanced Linux (SELinux). SELinux prevented the attacker from executing the second stage of the attack, possibly preventing a root compromise.

This article presents a case study of the intrusion response, explaining how I discovered the intrusion, what steps I took to identify the exploit, how I recovered from the attack and what lessons I learned regarding system security. I've changed machine names and IP addresses for privacy reasons.

Computers involved in the attack:

Today, prudent system administrators defend their machines with a layered security approach, using firewalls, automated patch management systems, log analysis tools and, recently, SELinux. SELinux provides additional access controls beyond those traditionally provided in the UNIX security model. Recent Red Hat Enterprise Linux and Fedora Core releases have an SELinux policy implementation called the targeted policy. It aims to restrict the privileges of programs in multiple packages to the minimum that they require for correct operation. This can blunt an attack that depends on having read, write or execute access to certain files or directories.

At approximately 8:00 AM on Saturday, May 6, 2006, I was auditing the logs on targetbox when I noticed an odd SELinux enforcement message in /var/log/messages:

May  4 07:52:27 targetbox kernel: audit(1146743547.060:2277): 
avc:  denied  { execute_no_trans } for  pid=9401 comm="sh" 
name="cback" dev=dm-0 ino=852100 
scontext=user_u:system_r:httpd_sys_script_t 
tcontext=user_u:object_r:httpd_sys_script_rw_t tclass=file

I used locate to try to identify cback quickly:

# locate cback
/tmp/cback
/usr/share/pixmaps/gnome-ccbackground.png
/usr/lib/libartscbackend.la
/usr/lib/libartscbackend.so.0.0.0
/usr/lib/libartscbackend.so.0

The file command revealed the executable file type of cback:

# file /tmp/cback
/tmp/cback: ELF 32-bit LSB executable, Intel 80386, 
version 1 (SYSV), for GNU/Linux 2.2.0, dynamically 
linked (uses shared libs), not stripped

The user apache owned that file, but it had a date a few months before the initial operating system installation on targetbox:

# ls -i /tmp/cback
852100 /tmp/cback
[root@targetbox ~]# ls -lZ /tmp/cback
-rwxr--r--  apache   apache   
user_u:object_r:httpd_sys_script_rw_t /tmp/cback
[root@targetbox ~]# ls -lai /tmp/cback 
852100 -rwxr--r--  1 apache apache 13901 
Feb 15  2005 /tmp/cback

This confirmed the identity of cback as the file in the audit message, because it had the inode number 852100.

If locate had not found the file, I could have used find to try to identify the file by inode:

# find / -inum 852100 2>/dev/null
/tmp/cback

Given the name of the script, maybe it was intended as a callback program. Because the apache user owned the file, I checked the Web server log files for evidence.

Because the attack program was in /tmp, I saved a copy of it for posterity:

# cp -a cback /root

The attack program seemed to do something with sockets, judging from the strings within (Listing 1).

# strings cback
/lib/ld-linux.so.2
libc.so.6
printf
connect
strerror
execl
dup2
sleep
socket
inet_addr
wait
fork
htons
__errno_location
exit
atoi
_IO_stdin_used
__libc_start_main
close
__gmon_start__
GLIBC_2.0
PTRh
[^_]
%s <host> <port>
cannot create socket, retrying in 5 seconds
socket ok
error: %s
retting in 5 seconds
/bin/sh
fork error, retry in 5 seconds

The Web server log file had many suspicious requests, some attacking Mambo using command injection and wget, some attacking other CMS systems. I copied all the lines containing php or wget using grep and put them in /root/exploit.log. Listing 2 contains a trace of the most recent attempt.