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?

Good bye securityfocus

I just read the sad announcement that SecurityFocus is going to be shut down (or phased out to sound more nice). The mailing lists will remain for a while, but all the rest will be moved to the Symantec web site…

Take a look: http://www.securityfocus.com/news/11582:

Beginning March 15, 2010 SecurityFocus will begin a transition of its content to Symantec Connect. As part of its continued commitment to the community, all of SecurityFocus’ mailing lists including Bugtraq and its Vulnerability Database will remain online at www.securityfocus.com There will not be any changes to any of the list charters or policies and the same teams who have moderated list traffic will continue to do so. The vulnerability database will continue to be updated and made available as it is currently. DeepSight and other security intelligence related offerings will remain unchanged while Infocus articles, whitepapers, and other SecurityFocus content will be available off of the main Symantec website in the coming months.

While the news portal section of SecurityFocus will no longer be offered, we think our readers will be better served by this change as we combine our efforts with Symantec Connect and continue to provide a valuable service to the community. As always, if you have any questions or concerns you can reach us at editor-at-securityfocus-dot-com.

Security Focus was a good site while it last and served its purpose very well.

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