WordPress Stored XSS vulnerability

31813257-bd05-49c5-b502-4ad222f8abbb

WordPress Critical Stored Cross-Site Scripting (XSS) Vulnerability

The new version of WordPress (WordPress 4.2) that was released just few days ago has already been scrutinized by white-hat hackers, just two days after it’s release, a critical security vulnerability was detected in the new version (which apply to older version as well): any website or blog, running WordPress 4.2 is susceptible to persistent cross site scripting attacks.

Breaking in down, it means that a crafted payload exploiting this vulnerability (i.e. entering a very long comment + JavaScript payload)  can result in the execution of arbitrary JavaScript code on the user’s browser. If the user viewing the comments has also admin privileges on the website, this scenario can result in complete website compromise.

Detailed analysis and recommendations:
The vulnerability is very similar to a one discovered more than a year ago (and patched around 10 days ago), and lies within the WordPress comments mechanism in which comments entered by the user are stored in a MySQL database.

As was discovered, triggering the MySQL truncation functionally on the entered comment  will result in a malformed HTML code when presented back to the user. While in the 4.2 version WordPress addressed one attack vector that triggers the truncation function (entering special characters, it was discovered that another vector – entering very long comments, which will also trigger the truncation – was not addressed, and is still available.  

We strongly recommend to update any website running under WordPress CMS to the newest WordPress version and install the latest patch.

Analysis and Demo:
http://klikki.fi/adv/wordpress2.html

Recommendations:
Wordpress has released a patch to solve the issue:
https://wordpress.org/news/2015/04/wordpress-4-2-1/
We highly recommend installing this patch.

 

Critical Windows Vulnerability

Capture

Critical Vulnerability in Windows http.sys allows attackers to perform Remote Code Execution

Following the “Patch Tuesday–Cyber Wednesday” tradition, a new security patch from Microsoft (released two days ago -14.04.15) exposed a critical vulnerability in most Windows versions (including Win7, Win 8, Win server 2008, Win server 2012 and more).
While full details are yet unavailable, it was revealed that attackers can execute arbitrary code – through unspecified http requests – on web servers (mainly IIS) that run on a Windows machine (and were not yet patched).

The issue has received the CVE code 2015-1635. From the moment of publication, a race began between hackers trying to reverse engineer the patch and create a working exploit, and organizations who must update millions of vulnerable servers.  

As of now, a partial exploit achieving a “blue-screen” denial of service has already being publicly discussed, and it is assumed that more sophisticated exploits allowing complete server takeover are already available in the wild. 

Technical details:

The vulnerability exists in Windows HTTP protocol stack (http.sys). It can be triggered by abusing the HTTP “range” header in a simple HTTP request (in the HTTP protocol,  a client can add a “range” element to his HTTP request, specifying the range of bytes he would like to receive in the requested resource).

As already published in hacking forums, adding a specific “range” value to an HTTP request (specifically – the value “Range: bytes=18-18446744073709551615″) will cause an un-patched IIS server to crash.  It is assumed that other payloads can allow the attacker to execute arbitrary code on the target machine. A proof of concept (POC) video of the attack is available later in this post.

Although at the moment it appears as the vulnerability is mostly exploitable through IIS (And specifically, the IIS kernel-caching system), it is safe to assume other application that utilize windows’s http.sys component are also vulnerable to the attack.

Recommendations:

1)  Install the relevant patch on all windows machines as soon as possible, where the first priority should bt the IIS servers. patches available here:
https://technet.microsoft.com/library/security/MS15-034


2) Another less recommended course of action is to disable IIS kernerl caching, which – as far as known at the time of writing – mitigates current payloads of the attack. Instructions here:

https://technet.microsoft.com/en-us/library/cc731903(v=ws.10).aspx
Microsoft’s official announcement
including:
1) List of vulnerable machines
2) Patch for all versions
3) Partial details about the issue

https://technet.microsoft.com/library/security/MS15-034

Proof of Concept Video: