Mambo Exploit Blocked by SELinux

A real-world case where SELinux proved its worth.

The cback binary probably was created at 07:52 AM on May 4, corresponding to the wget command injection attack. That was the last time the file attributes were modified. Although UNIX does not allow you to retrieve the true creation time of a file, the status time often can stand in for that. The other times correspond to the times of my own initial investigations of the cback file. If I had been more careful, I could have done this ls command before reading the cback file at all, so that the atime, access and use times would have been those the attacker had set.

What Hit Me?

Because this looked like a worm attacking Mambo, a search on “mambo worm” on Google found references to the attack, including articles from ComputerWorld, Outpost24, F-Secure and Bugtraq (see Resources).

The Mitre Common Vulnerabilities and Exposures Project provides a dictionary of known vulnerabilities. It has a brief abstract of the characteristics of the vulnerability with references to security mailing lists and Web sites that confirm the problems. Searching for “mambo” on yielded a couple-dozen known vulnerabilities—one of which (CVS-2005-3738) relates to mosConfig_absolute_path, one of the seriously mangled variables in the request URL.

After reading up on recent malware activity surrounding Mambo, I saw that the attack vector probably was closely related to the Net-Worm.Linux.Mare.d worm strain described in the news reports and vulnerability databases. However, some of the names of executables in the attack that hit targetbox were slightly different from the attack executables named in the vulnerability reports.

Safety Precautions and Forensic Evidence

To run these security analysis tools in the safest way possible, you need to disconnect the computer in question from all networks and boot from known good media before attempting to analyze the intrusion. That way, any remaining attack programs will not be able to attack other machines on your network, and intruders will not interrupt your investigation by interacting with the machine. You won't be able to use the system while you analyze the intrusion, and it may take time to put together an analysis toolkit that will work on a rescue disk. Although this takes more time and preparation than running the analysis tools on a running system that might be compromised, it gives a higher level of assurance that a compromise will not spread to other machines on your network.

Making a backup copy of the entire disk to a removable drive also is a good idea. You could use a command such as this to do the job:

# dd if=/dev/hda1 of=/mnt/removable-drive/disk.img bs=512k

You then can mount and analyze the backup using the loop device (see “Disk Images under Linux” in the Resources section). It's probably faster and easier to analyze the original system, but it's nice to have this backup for forensic purposes.

In an ideal world, you could do this the moment you realize an attack has succeeded. However, sometimes you have to assess the severity of the compromise and balance that against the time and resources you have available.

Figuring Out the Damage Done

It looks like whoever broke in could have read or written to any file available to the apache user. This would include the PHP configuration file for Mambo that had a MySQL database user name and password in it. I changed that password just to be sure that the intruder could not use it to attempt further privilege escalation.

Fortunately for me, this was only a test installation, so to prevent future exploits, I removed the Mambo installation completely. I also could have attempted to upgrade the software to remove the vulnerability.

When a user account is compromised, you need to face the danger that the attacker could gain access to the superuser (root) account. If an attacker gets root, it can make it much more difficult to recover from an attack. Most of the time, you need to re-install the operating system from known good media and carefully and selectively audit and restore software configurations. Attackers who manage to get root access often install a rootkit—software that hides itself from casual inspection and offers a remote control back door or other malicious features. Fortunately, a program called chkrootkit (from can help scan for active rootkits. Listing 6 shows the output of chkrootkit in quiet mode on targetbox.



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



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:


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