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:
- 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.
- 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?
- 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.
- 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.
- 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?
