Loading
Mambo Exploit Blocked by SELinux
A real-world case where SELinux proved its worth.
The chkrootkit program checks for and analyzes various files that rootkits and worms commonly leave behind. It warns about hidden files in unexpected places and services running on ports that malware often uses. A quick inspection revealed that the hidden files this listed were all harmless. The INFECTED warning on port 465 was a false alarm, because this computer was running a Web server that listens for https on port 465. In this case, analyzing the chkrootkit output did not reveal a real rootkit problem. Running chkrootkit can give you some extra peace of mind when you know an attacker has penetrated your defenses, even though its checks are not conclusive.
The server ran SELinux using the targeted policy at the time of the attack. The audit log message that originally sounded the alarm that all was not well was an access denied message. The Web server error log provided more detail in the form of the output of the injected shell code, including the wget session and the access denied message resulting from the attempted execution of wget, as shown in Listing 7.
SELinux prevented the cback executable from running, saving targetbox from the next stage of the worm.
Newer versions of Mambo close the hole that the attacker exploited, so I could install a new version without being vulnerable to the same exploit.
Many of the tools required to analyze an attack are already a core part of all modern Linux distributions. Combined with the power of modern search engines and the public disclosure of known vulnerabilities, you can often determine a good deal of information about the nature of an attack.
Installing something from source code to test it out, then leaving it on a publicly available computer made the system vulnerable. That this test installation lived in the document root of the main virtual host on the Web server made it even more exposed and vulnerable to discovery by worms.
Many PHP-powered systems have installation instructions that essentially tell you to unarchive the software somewhere inside the document root of a Web server, then modify some configuration files. You often cannot use the same type of clean operating-system-wide packaging for PHP systems, as each installation uses a distinct set of PHP templates. It took about 11 months between installing Mambo and the attack, during which time I did not update the software at all.
Using yum or apt-get to update Mambo would help keep it up to date. When I started investigating Mambo, I could not find RPM packaging for it, though third parties have created RPMs for Mambo since then. Operating system vendors and software authors need to work on better mechanisms for automatic software maintenance of Web systems.
SELinux really saved the day, preventing the exploit program from running. Without the protection of SELinux, this easily could have turned into a root compromise requiring a much more extensive analysis and recovery effort.
______________________
White Paper
Fabric-Based Computing Enables Optimized Hyperscale Data Centers
Today’s modular x86 servers are compute-centric, designed as a least common denominator to support a wide range of IT workloads. Those generic, virtualized IT workloads have much different resource optimization requirements than hyperscale and cloud applications. They have resulted in a “one size fits all” enterprise IT architecture that is not optimized for a specific set of IT workloads, and especially not emerging hyperscale workloads, such as web applications, big data, and object storage. In this report, you will learn how shifting the focus from traditional compute-centric IT architectures to an innovative disaggregated fabric-based architecture can optimize and scale your data center.
Sponsored by AMD
White Paper
Red Hat White Paper: Using an Open Source Framework to Catch the Bad Guy
Built-in forensics, incident response, and security with Red Hat Enterprise Linux 6
Every security policy provides guidance and requirements for ensuring adequate protection of information and data, as well as high-level technical and administrative security requirements for a system in a given environment. Traditionally, providing security for a system focuses on the confidentiality of the information on it. However, protecting the data integrity and system and data availability is just as important. For example, when processing United States intelligence information, there are three attributes that require protection: confidentiality, integrity, and availability.
Learn more about catching the bad guy in this free white paper.
Sponsored by DLT Solutions
- RSS Feeds
- New Products
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Drupal Is a Framework: Why Everyone Needs to Understand This
- A Topic for Discussion - Open Source Feature-Richness?
- Home, My Backup Data Center
- Developer Poll
- Dart: a New Web Programming Experience
- May 2013 Issue of Linux Journal: Raspberry Pi
- What's the tweeting protocol?
- Reply to comment | Linux Journal
2 hours 14 min ago - Reply to comment | Linux Journal
3 hours 1 min ago - Web Hosting IQ
4 hours 35 min ago - Thanks for taking the time to
6 hours 11 min ago - Linux is good
8 hours 9 min ago - Reply to comment | Linux Journal
8 hours 26 min ago - Web Hosting IQ
8 hours 56 min ago - Web Hosting IQ
8 hours 57 min ago - Web Hosting IQ
8 hours 58 min ago - Reply to comment | Linux Journal
11 hours 58 min ago
Free Webinar: Linux Backup and Recovery
Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.
In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.
Comments
Titanic movie rendered with Linux
bosch servisi, bosch servis
..
Thanks..
radyo
thank you very good
An alternate defense against this attack
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
bootand/filesystems. This system was one of those. Locking down/tmplike 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/tmpunless you dedicate a disk partition to it, or do funny tricks such as mounting a file on/varwith 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
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.