WordPress 4.0.1 – Critical WordPress XSS Update| InfoSec Handlers Diary Blog

Today, WordPress 4.0.1 was released, which addresses a critical XSS vulnerability (among other vulnerabilities). [1]

The XSS vulnerability deserves a bit more attention, as it is an all too common problem, and often underestimated. First of all, why is XSS “Critical”? It doesn’t allow direct data access like SQL Injection, and it doesn’t allow code execution on the server. Or does it?

XSS does allow an attacker to modify the HTML of the site. With that, the attacker can easily modify form tags (think about the login form, changing the URL it submits it’s data to) or the attacker could use XMLHTTPRequest to conduct CSRF without being limited by same origin policy. The attacker will know what you type, and will be able to change what you type, so in short: The attacker is in full control. This is why XSS is happening.

The particular issue here was that WordPress allows some limited HTML tags in comments. This is always a very dangerous undertaking. The word press developers did attempt to implement the necessary safeguards. Only certain tags are allowed, and even for these tags, the code checked for unsafe attributes. Sadly, this check wasn’t done quite right. Remember that browsers will also parse somewhat malformed HTML just fine.

InfoSec Handlers Diary Blog – Critical WordPress XSS Update.

New Site Recovers Files Locked by Cryptolocker Ransomware — Krebs on Security

Great news for those affected by the CryptoLocker virus.

But early Wednesday morning, two security firms – Milpitas, Calf. based FireEye and Fox-IT in the Netherlands — launched decryptcryptolocker.com, a site that victims can use to recover their files. Victims need to provide an email address and upload just one of the encrypted files from their computer, and the service will email a link that victims can use to download a recovery program to decrypt all of their scrambled files.

The free decryption service was made possible because Fox-IT was somehow able to recover the private keys that the cybercriminals who were running the CryptoLocker scam used on their own (not free) decryption service. Neither company is disclosing much about how exactly those keys were recovered other than to say that the opportunity arose as the crooks were attempting to recover from Operation Tovar, an international effort in June that sought to dismantle the infrastructure that CryptoLocker used to infect PCs.


New Site Recovers Files Locked by Cryptolocker Ransomware — Krebs on Security.

Critical Update for Windows RT 8.1, Windows 8.1, and Windows Server 2012 R2 | Microsoft

Important All future security and nonsecurity updates for Windows RT 8.1, Windows 8.1, and Windows Server 2012 R2 require this update to be installed. We recommend that you install this update on your Windows RT 8.1, Windows 8.1, or Windows Server 2012 R2-based computer in order to receive continued future updates.

What this means is that unless you get this patch onto your client machines they will be unable to download and install security updates from May onwards… therefore you NEED TO GET THIS TESTED AND DEPLOYED OUT SOONER THAN LATER.

Windows RT 8.1, Windows 8.1, and Windows Server 2012 R2 Update April, 2014.

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.


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:


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

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.