Comments on: An analysis of the latest website hacks http://www.blogtips.org/analysis-of-the-latest-website-hacks/ Blogging and Social Media for Nonprofit Wed, 01 Feb 2012 23:25:48 +0000 hourly 1 http://wordpress.org/?v=3.2.1 By: World Gone Web hacked : World Gone Web http://www.blogtips.org/analysis-of-the-latest-website-hacks/comment-page-1/#comment-797 World Gone Web hacked : World Gone Web Sat, 08 Jan 2011 09:01:07 +0000 http://www.blogtips.org/?p=1001#comment-797 [...] 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 [...] [...] 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 [...]

]]> By: Neo http://www.blogtips.org/analysis-of-the-latest-website-hacks/comment-page-1/#comment-296 Neo Sun, 23 May 2010 08:05:37 +0000 http://www.blogtips.org/?p=1001#comment-296 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. 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.

]]> By: Peter http://www.blogtips.org/analysis-of-the-latest-website-hacks/comment-page-1/#comment-289 Peter Sat, 22 May 2010 23:27:03 +0000 http://www.blogtips.org/?p=1001#comment-289 @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? ;) @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? ;)

]]> By: Roy http://www.blogtips.org/analysis-of-the-latest-website-hacks/comment-page-1/#comment-277 Roy Sat, 22 May 2010 16:06:50 +0000 http://www.blogtips.org/?p=1001#comment-277 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. 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.

]]> By: Peter http://www.blogtips.org/analysis-of-the-latest-website-hacks/comment-page-1/#comment-276 Peter Sat, 22 May 2010 14:07:14 +0000 http://www.blogtips.org/?p=1001#comment-276 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 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

]]> By: Roy http://www.blogtips.org/analysis-of-the-latest-website-hacks/comment-page-1/#comment-275 Roy Sat, 22 May 2010 13:37:44 +0000 http://www.blogtips.org/?p=1001#comment-275 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. 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.

]]> By: Peter http://www.blogtips.org/analysis-of-the-latest-website-hacks/comment-page-1/#comment-269 Peter Fri, 21 May 2010 16:10:26 +0000 http://www.blogtips.org/?p=1001#comment-269 @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. @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.

]]> By: Mark http://www.blogtips.org/analysis-of-the-latest-website-hacks/comment-page-1/#comment-267 Mark Fri, 21 May 2010 15:53:19 +0000 http://www.blogtips.org/?p=1001#comment-267 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. 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.

]]>