More Than 162,000 WordPress Sites Used for Distributed Denial of Service Attack

We have been tracking the recent issue of “WordPress Sites Used for Distributed Denial of Service Attack” for a couple of days and the write up at Sucuri is very good explain the issues behind the latest Distributed Denial Of Service (DDOS) attack – basically ANY WordPress with the default install can be used to launch a DDOS attack against a specific target. What happens is that the “ping back” feature of WordPress is used to then bombard a third party with so much traffic it simply can’t handle it.

http://blog.sucuri.net/2014/03/more-than-162000-wordpress-sites-used-for-distributed-denial-of-service-attack.html
http://krebsonsecurity.com/2014/03/blogs-of-war-dont-be-cannon-fodder/

Sucuri has done a very good job in giving us a look into their logs of the recent attacks and I would recommend that ALL WordPress sites should be checked against the following service:

http://labs.sucuri.net/?is-my-wordpress-ddosing

If you do decide to disable PingBacks (which is NOT recommended if you do have comments on your Posts) then the best option is to disable the XML-RPC function that supports PingBack via the following plug-in: https://wordpress.org/plugins/disable-xml-rpc/

Note that this will also disable remote posting/editing (like is used in the iPad/Android WordPress platforms), so tread carefully with this change.

Also, you can do this yourself according to Brian Krebs:

As Sucuri notes, for the gearheads who don’t trust plugins, one easy way to block your WordPress blog from participating in these attacks is to create your own plugin that incorporates the following code:

add_filter( ‘xmlrpc_methods’, function( $methods ) {
unset( $methods['pingback.ping'] );
return $methods;
} );

Post Mortem of a Hack…

We had a call from a client recently that said that their site was hacked and it was serving up content not associated with them. We were a bit surprised by this as we monitor the site AND we also look for specific keywords to prevent this sort of hijack. Our immediate reaction was to investigate the cause of the hack but as the “redirected content” was of an adult nature, the client themselves rolled back the changes without keeping a copy of the hacked files. This left us a bit in the dark and with the monitoring software also “blind” to the change we had nothing to go on with.

What happened next was rather surprising: while trawling through the logs to see if we could find something of note, the hacker got in again and redid the hack. Quite nice of him/her to do that while we were watching as we then had a timeframe to work with (within 15 minutes) AND we could see the files that had changed.

Once we had that information we quarantined the changes, rolled them back and blocked the hacker’s IP address so we had stability and could investigate further.

What we found was a very sophisticated hack that targeted the .htaccess files on the server and setup a redirect that excluded MOST external monitoring solutions based on HTTP_USER_AGENT. The “polluted” .htaccess was quite extensive:

RewriteEngine On
RewriteCond %{HTTP_USER_AGENT} …467 browser agents listed!… [NC,OR]
…some other conditions applied…
RewriteRule ^(.*)$ <<site>> [L,R=302]

As our monitoring system uses their own “UserAgent” setting this was not recognised by the HTTP_USER_AGENT pattern and therefore did not see the change to the site – so we never got the alert that the site had been altered.

Digging a bit deeper we found the root cause of the hack: an out of date WordPress installation with a misconfigured theme that allowed upload of PHP files that could then be run. This went searching for web application folders that had files that could be overwritten. While the client had “secured” their WordPress files by executing a chmod -w * they had not also executed that on the .htaccess files (as these are not picked up by the “*” pattern match).

Remediation Steps:

  1. Upgrade WordPress, the Plugins and Themes to the latest version
  2. Secure the .htaccess files
  3. Ensure that the wp-uploads directory does not allow server execution ANY files

Result:
We learnt a valuable lesson here and will be applying some changes to our standard setup procedures across ALL clients (whether they use WordPress or not). We are also reviewing the logs of the attack with a third party to see if we can track back to the individual(s) concerned.

Email Attack on Vendor Set Up Breach at Target | Krebs on Security

A very good (and damning) investigation of the Target breach. Key items are:

The company’s primary method of detecting malicious software on its internal systems was the free version of Malwarebytes Anti-Malware.

“Target would have paid very little attention to vendors like Fazio, and I would be surprised if there was ever even a basic security assessment done of those types of vendors by Target.”

Krebs then goes on to explain how by downloading publicly available documents from one of the Target web sites you can get a fair idea of how the Target network is setup.

Email Attack on Vendor Set Up Breach at Target — Krebs on Security.

Protecting customer data from government snooping | The Official Microsoft Blog

Interesting to see that Microsoft is starting a push that as they say will take them to “the end of 2014” to secure all of their systems with encryption. It is rather curious though that they are going to “leave the choice to developers” when it comes to Windows Azure. It really should be a case of “one in, all in”.

Protecting customer data from government snooping – The Official Microsoft Blog – Site Home – TechNet Blogs.

Hacked Via RDP: Really Dumb Passwords | Krebs on Security

I have been reading this article about passwords and how easy it is to hack a server when you do not have secure passwords – Hacked Via RDP: Really Dumb Passwords — Krebs on Security.

One of the things that stands out is that the Local Security Policy on Windows is wrong in that “Password must meet complexity requirements” setting should always be set to “Yes”. The definition is quite clear cut:

This security setting determines whether passwords must meet complexity requirements.

If this policy is enabled, passwords must meet the following minimum requirements:

Not contain the user’s account name or parts of the user’s full name that exceed two consecutive characters
Be at least six characters in length
Contain characters from three of the following four categories:
English uppercase characters (A through Z)
English lowercase characters (a through z)
Base 10 digits (0 through 9)
Non-alphabetic characters (for example, !, $, #, %)
Complexity requirements are enforced when passwords are changed or created.

Default:

Enabled on domain controllers.
Disabled on stand-alone servers.

Note: By default, member computers follow the configuration of their domain controllers.

(Emphasis on the “user account name” part is mine). Where I believe the settings are incorrect is in the “Disabled on stand-alone servers”. If a computer is able to be reached remotely via RDP then it MUST have “Password must meet complexity requirements” set to “Yes”. This should be a requirement of enabling the Remote Desktop Protocol.

This would negate ALL the attacks in the Krebs article.

Also, we have found that MOST companies that store passwords in an encrypted manner use an unsalted MD5 hash. While this is a one-way encryption it is very easily defeated by rainbow tables. For example, let’s take a simple password and get it’s MD5 hash:

MD5(‘password’) = 5f4dcc3b5aa765d61d8327deb882cf99

Now, let’s use MD5 Online to “crack” this password by doing a simple reverse lookup:

Found : password (hash = 5f4dcc3b5aa765d61d8327deb882cf99)

Ok, so unsalted MD5 hashes are not a good idea with common words. What we suggest is that YOU take responsibilty for adding your own “salt“, eg:

MD5(‘$$password$$’) = 213a95dfa43321c74cf0b5c843afbe6e

using MD5 online again we find:

No result found in our database.

Obviously this is only as good as the “salt” that you choose – but make sure you have a number of different special characters in your password and DON’T DO letter substitution:

MD5(‘p@55w0rd’) = 39f13d60b3f6fbe0ba1636b0a9283c50

MD5 Online can easily find this password – even though it’s not a real word!

Rick.

Important Security Update for D-Link Routers | Krebs on Security

D-Link has released an important security update for some of its older Internet routers. The patch closes a backdoor in the devices that could let attackers seize remote control over vulnerable routers. On Nov. 28, D-Link released a series of updates to fix the problem. Updates are available for the following models: DI-524, DI-524UP, DIR-100, DIR-120

Heffner says based on his research, several other versions of D-Link routers may be vulnerable, including the DIR-624S, DI-604S, DI-604UP, DI-604+ and the TM-G5240. However, no updates were released by D-Link for these models.

via Important Security Update for D-Link Routers — Krebs on Security.

Anatomy of a password disaster – Adobe’s giant-sized cryptographic blunder | Naked Security

A very good read of how bad the Adobe breach was. It also answers the question as to how Facebook was able to determine what the passwords used on Adobe were the same as being used on Facebook (even though they do not store the password or even the encrypted password). It is also truly scary how easily you can determine passwords given a large enough sample size.

Anatomy of a password disaster – Adobe’s giant-sized cryptographic blunder | Naked Security.

Facebook engineer describes how they have used the Adobe breach to tighten general security | Krebs on Security