Security Archive: Remembering security incidents to make sure we don’t commit the same mistakes over and over again.
Want to read more stories like this one? Follow @sucuri_security on twitter or subscribe to our RSS feed. Interested in a web site security monitoring solution? Visit sucuri.net.
May 5th, 2000. It was almost ten years ago that news came out. The web site for the most popular web server got defaced. Yes, Apache.org was hacked. The funny part is that the attackers were “nice” and only modified the page to add a Microsoft banner (“Powered by Microsoft BackOffice”).
How Embarrassing. They were “white hats” (according to Apache itself) and did nothing more than to add that funny banner. However, people were worried about what else they could have done or what else might be compromised. Was the Apache source code safe? Did anyone add a backdoor there? Even worse, how they got in? Was it caused by a 0-day on Apache itself?
The attackers itself explained how they got in and it was caused by a few configuration mistakes made by the Apache team.
Mistakes:
- Their HTTP root directory (www_root) was the same as their FTP root directory (ftp_root). So visiting http://apache.org was using a directory inside ftp://apache.org.
- Their FTP allowed anonymous access
- They had a world writable directory inside that FTP server
- They didn’t have a deny-all policy in their firewall
- MySQL was running as root
None of these are big issues by itself, but when merged together, they gave the attackers full access to the Apache server.
How they got in?
They added a PHP file inside that FTP world-writable directory and executed it via the HTTP site. After that they pushed a remote shell (to listen on port 65533) and got shell access! They looked around, found the database password inside the bugzilla configuration file, created a test database and exported it as a root executable file (remember, mysql was running as root – SELECT.. INTO OUTFILE) and after a few more tricks they owned everything…
What to learn from it and protect ourselves?
- Set up a default-deny policy on your firewall. If they had that (only allowing port 80 for example), their remote shell would not have worked. How is your firewall configured?
- The HTTP files should be owned by root, not the apache user itself. The apache user only need read access and maybe a write access to one or two directories
- Your web_root should be different from your ftp_root. I see lot of servers where the /home/[site] is both!
- Remove anonymous FTP access! If you need this functionality, configure a separate server for that. Anonymous write-access? Never!
- Don’t run your services as root! They only got root because mysql was running as root! Always use privilege-separated users
Want to see the full story? It is very entertaining. Check out: http://www.dataloss.net/papers/how.defaced.apache.org.txt
4 comments
Actually, there are plenty of ways to control a computer over port 80 – search for "php shell". One could also argue that updating the web site shouldn't need root.
Joachim: I agree, it doesn't have to be root, but any user other then the apache one.
As far as a php shell, they can be useful yes, but that doesn't take from the fact that you should have a deny all policy. If you see what they did in the text, they opened two different ports in LISTEN mode to do what they wanted.
Plus, if you have a restricted php configuration, even a php shell can be hard to pull it off.
In May 2000, how many PHP shells existed? In March 2010, I believe that number is a bit higher.
Thanks for sharing your info. I really appreciate your efforts and I will be waiting for your further write ups thanks once again.
html5 player| html5 video player
Comments are closed.