Security Archive – Case Study: phpbb.com Compromised

Security Archive: It is important to remember past security incidents to make sure we don’t commit the same mistakes over and over again. The idea is to learn from our mistakes.

You can read other case studies from our security archive here:

Jan 31st, 2009: The website for the popular open source bulletin board, phpbb.com, was compromised and the user list was posted online. That was scary news for anyone using phpBB as they were unsure what was going on. If we are not mistaken (it has been a few years), phpbb.com was actually offline for many days while their team investigated the issue.

Read More

Perl.com hacked – Security archive case study

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.

Jan 17th, 2008. Every person who visited the site of the famous programming language Perl (perl.com), got redirected to a porn site hosted at grepblogs.net. Uh-oh, when was it hacked? Did anyone compromised the source code from Perl? What about the accounts at perl.com, where they stolen?

During these incidents, people tend to overreact and think of the worst. However, what happened was very simple… That was the official explanation:

We at O’Reilly just got bit on perl.com, which redirected to a porn site courtesy a piece of remotely-included Javascript. One of our advertisers was using an ads system that required our pages to load Javascript from their site. It only took three things to turn perl.com into porn.com: (1) the advertiser’s domain lapsed, (2) the porn company bought it, (3) they replaced the Javascript that we were loading with a small chunk that redirected to the porn site (note that nothing on or about perl.com changed).

Very interesting.. The Perl.com servers weren’t hacked at all (or even touched). A simple remote javascript got modified and their site became a “porn” paradise.

What mistakes they did:

  1. They included javascript from remote sites. This is a common thing nowadays (specially if you run ads), but you have to choose your sources wisely. Google is a good one, but grepblogs doesn’t sound very authoritative.
  2. The grepblogs.net domain expired, the javascript was not loading and nobody noticed. That means that they were not monitoring the site as they should.

What to learn from it and how to protect ourselves?

  1. Limit the amount of external content you embed on your site. If you need ads, choose a reputable company that will not go away and will take security seriously.
  2. Monitor the content of what you include on your site. If you have to use scripts from remote locations, regularly check if they are still in business, check if the script is still responding properly and if they didn’t get compromised.
  3. That’s the best advice: whenever possible, store your content locally where you can control.

What do you think? What additional steps we can take to avoid issues like that?

Apache.org defaced – Security archive case study

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:

  1. 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.
  2. Their FTP allowed anonymous access
  3. They had a world writable directory inside that FTP server
  4. They didn’t have a deny-all policy in their firewall
  5. 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?

  1. 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?
  2. 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
  3. Your web_root should be different from your ftp_root. I see lot of servers where the /home/[site] is both!
  4. Remove anonymous FTP access! If you need this functionality, configure a separate server for that. Anonymous write-access? Never!
  5. 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