Mambo Exploit Blocked by SELinux

A real-world case where SELinux proved its worth.

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:

  • targetbox: 192.168.166.155—our server, running RHEL 4 and Mambo.

  • wormhole: 10.9.233.25—worm attack source.

  • zombieweb: 172.16.31.57—Web server hosting attack payload.

  • cbackbox: 10.200.238.39—target of stage 2 worm executable.

Defending Your System from 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.

Discovering the Incident

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

Analyzing the Executable for Clues

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).

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.

______________________

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Titanic movie rendered with Linux

bosch servisi's picture

bosch servisi, bosch servis

..

turkce's picture

Thanks..

radyo

radyo's picture

thank you very good

An alternate defense against this attack

Richard Bullington-McGuire's picture

Kyle Wilson recently wrote me regarding this article, and gave me permission to share his remarks with Linux Journal readers:
________________________________________________________

Richard,

Hi. I just finished reading your article about SELinux in this month's Linux Journal. I enjoyed it very much. I thought I'd share a tip with you which I use to protect my internet facing servers. I always edit my fstab file to include the nosuid and noexec mount options for my tmp file system. In the case of the Mambo exploit which you wrote about, having the noexec mount option on /tmp would have also prevented the exploit by preventing the execution of the cback binary which was placed in your /tmp file system. Here's the description of the options from the mount man page:

noexec - Do not allow execution of any binaries on the mounted file system. This option might be useful for a server that has file systems containing binaries for architectures other than its own.

nosuid - Do not allow set-user-identifier or set-group-identifier bits to take effect. (This seems safe, but is in fact rather unsafe if you have suidperl(1) installed.)

Kyle
________________________________________________________

Kyle has some good points about protecting filesystems using mount options. That is a solid and time-honored way of helping to secure a system, to be sure. I've seen some systems that have many filesystem mount points that are locked down with noexec and nosuid options.

Many systems today (including the one I wrote about) only have two file systems by default, that is a boot and / filesystems. This system was one of those. Locking down /tmp like that would also have protected from this specific attack, had SELinux not been activated:


# for /etc/fstab:
none /tmp tmpfs nosuid,noexec,rw,size=512m 0 0

However, other points of vulnerability also exist, such as /dev/shm, /var/tmp, and really, any writable file on your system. To be thorough about using nosuid and noexec options, you would need to ensure that these directories are also protected with these options. That is easy enough for /dev/shm, but not so easy for /var/tmp unless you dedicate a disk partition to it, or do funny tricks such as mounting a file on /var with the loop device and mounting that on /var/tmp. Even doing that is not proof against a determined attacker, as this shell code snippet illustrates:


# Try this out on your system to see how wide-open you could still be
echo "World-writable directories:"
find / -type d -perm +0002
echo "World-witable files:"
find / -type f -perm +0002

One of the nice things about the Red Hat / Fedora SELinux targeted policies is that it stops attacks on pretty much all of these locations with a default-deny rule.

Correction: sentence below Listing 4

Richard Bullington-McGuire's picture

The sentence below Listing 4 should read:

Lines showing further attacks similar to the trace on targetbox versus Mambo, xmlrpc.php, drupal and phpgroupware also appeared in this grep.

White Paper
Linux Management with Red Hat Satellite: Measuring Business Impact and ROI

Linux has become a key foundation for supporting today's rapidly growing IT environments. Linux is being used to deploy business applications and databases, trading on its reputation as a low-cost operating environment. For many IT organizations, Linux is a mainstay for deploying Web servers and has evolved from handling basic file, print, and utility workloads to running mission-critical applications and databases, physically, virtually, and in the cloud. As Linux grows in importance in terms of value to the business, managing Linux environments to high standards of service quality — availability, security, and performance — becomes an essential requirement for business success.

Learn More

Sponsored by Red Hat

White Paper
Private PaaS for the Agile Enterprise

If you already use virtualized infrastructure, you are well on your way to leveraging the power of the cloud. Virtualization offers the promise of limitless resources, but how do you manage that scalability when your DevOps team doesn’t scale? In today’s hypercompetitive markets, fast results can make a difference between leading the pack vs. obsolescence. Organizations need more benefits from cloud computing than just raw resources. They need agility, flexibility, convenience, ROI, and control.

Stackato private Platform-as-a-Service technology from ActiveState extends your private cloud infrastructure by creating a private PaaS to provide on-demand availability, flexibility, control, and ultimately, faster time-to-market for your enterprise.

Learn More

Sponsored by ActiveState