Follow BlogTips via RSS Get BlogTips updates via Email Follow @SM4NP - Social Media for NonProfit

An analysis of the latest website hacks

Posted on May 21st, 2010 by
Vesalius

If Vesalius were a blogger...

After the latest spree of hacks on thousands of websites, it is time to look at some of the commonalities and ways to security our sites better. Given that the security holes are clearly at the level of the website hosting companies, and it is their duty to close those holes, nothing stops us from securing our own sites better. That is what our next series will be about: how to secure our self hosted blogs.

Godaddy published more background information on their blog:

This is a complex attack with many components. Here is a high-level overview of how they occur:

  1. The attacker is coordinating attacks against three different hosting providers for this to work.
    • At Hosting Provider ‘A’ – A malicious file is placed on hosting accounts at this provider. No two files have the same name.
    • At Hosting Provider ‘B’ – A file is uploaded listing the infected domain names and unique file names from provider ‘A.’
    • At Hosting Provider ‘C’ – A malicious “scareware” site is placed on compromised accounts
  2. After the attackers put their files in place, they use Hosting Provider ‘B’ to trigger the malicious files on Hosting Provider ‘A.’ When triggered, the malicious file:
    • Scans the hosting account for any php file
    • Injects malicious content, installing malware that directs to Hosting Provider ‘C’
    • Removes any trace of itself from ‘Hosting Provider B’
  3. The attack is complete when an infected website receives a visitor. The visitor, if not adequately protected, will have malware installed on their machine.
  4. The malware will alert the infected computer to purchase fake anti-virus software, located at Hosting Provider ‘C.’

The common factors of all the recent hacks are:

  1. The affected sites were all .PHP based CMS’s (Content Management Systems): WordPress, Drupal, Joomla, phpBB…
  2. A .php file was put on the root directory of the website, executed a few hours later, and then deleted (more).
  3. While executing, the .php file inserted malicious code in all .php files of your site which redirected visitors to a site which infected the visitor’s computer with a virus. (more)

So the basic questions are:

  1. How can we avoid .php file being dropped on our site?
  2. If a .php file is dropped through a hosting provider’s security hole, how can we detect it fast, before it executes?
  3. If our .php files are infected, how do we cure them easily?

Again, while we can not close the security hole of the hosting providers, we sure can take some measures to either tighten the hole ourselves, or at least monitor the changes happening on our sites?

Some solutions:
In this post, I suggest a solution to monitor for file changes and uploads on your selfhosted WordPress blog.
In this post, I described how to cure infested files.
Here, I describe how to protect login information being read from our WordPress blog.

Safe blogging!

Picture courtesy WikiMedia




8 Comments to “An analysis of the latest website hacks”

  1. Mark says:

    I am not sure, every case I’ve seen that matches what you say here, had security holes at the application level.

    It is true though that in some cases the server , db, or programming language had problems and patches had to be installed, but the majority of holes are coming either from applications or bad management, owners do, with their sites or browsers.

    Now the page you link to in gd, mentions about a number of sites that were compromised. If I read it right it talks about sites hosted that were compromised not the entire hosts. Because if it was the entire host it will been a different story. The reason I mentioned application level.

    So if say a popular CMS has a security hole (and the info does get published by the vendor in many cases) an attacker can utilize the information on unpatched sites and the rest is history.

    The other case is with browsers. The vast majority of people surf with js enabled, this means now their systems are open for a variety of attacks with the primary target being their router. So again site owners may have their systems compromised because of this. In other words, you surf with js enabled on every site, you hit a bad one (iframe+js -> router config attempt), you know the usual tactics, that can be totally untraceable.

    • Peter says:

      @Mark

      Tnx for your remarks.. Your observations are totally correct, however on this particular attack:

      1/ all PHP based CMSes (I know of WP, Joomla, Drupal, PHPbb,..) were attacked which makes me feel it was CMS independent, but rather a loophole in the PHP/SQL config combined with a hosting issue.

      2/ With the active community around WP/Drupal, I would also think now that the literally thousands of sites were attacked at the same moment, a security patch would come out real fast… Which also makes me think the attack was at the host level, not at the level of the individual sites, as the attack was that wide spread… I know.. that is an assumption and I am open to stand corrected…! ;)

      Meanwhile, I am have a plugin to monitor any changes on my WordPress sites, so whatever happens, I will know about it..
      Will write about it in my next post..

      P.

  2. Roy says:

    I caught the file before it executed on my site (WP File Monitor plugin emailed me). I have all of the standard security measures in place (htaccess protections, file permissions, Bad Behavior plugin, fresh passwords, etc.), so at least in my case, I’m fairly certain the exploit is a server configuration issue.

    • Peter says:

      Hi Roy,
      – A coincidence: I am writing about WP File Monitor right now, as one of the follow-up posts…!
      I have put in a couple of measures myself on .htaccess changes, access to wp-config, tightening the drop file loophole, …

      If you have any other tips, let me know.

      Peter

  3. Roy says:

    I found your post on Drupal about the drop file loophole – I just added that – thanks! The attempt on my site was not with a multi-extension file, though.

    I see you are running WP File Monitor – one undocumented feature is that you can set the scan interval to zero, which will remove the calling of wordpress-file-monitor.php (saves a bit of load time), but you will still get email notifications on any file change. It works for me, anyway.

  4. Peter says:

    @Roy

    That is strange, as “zero” should mean “manual scans only”, meaning if it is not calling wordpress-file-monitor.php, I don’t understand how it can be scanning…

    Mystery of life? ;)

  5. Neo says:

    Our site was one of the sites hit by the .php exploits. When it happened I was in the Mojave Desert (literally) with no internet and received a text from one of our content builders. Because it was zero day, Godaddy refused to accept that it was located on their servers. An embarrassing week later, when I returned to HI they removed the malicious code free of charge and we were back to normal. The funny thing is, it was detected as Trojan.FakeAlert on our test system and kept rejuvenating itself despite reinstalling the entire site from backup.

  6. [...] Here is a detailed explanation of the attack 2. I downloaded and modified Peter’s fixfiles.php script in order to clean my PHP code of the [...]

Leave a Comment

*