sirdarckcat

Here's a new version of the last post code for hijacking IE6 and IE7 iframes.

Aparently some versions of IE where fixed, (the code didnt worked for 40% of the people), so after downloading the newest IE7, I kept researching and found another issue.


Sample PoC Here.

This time the code will open a new window (hackademix.net), it will hijack one of the iframes, and capture keystrokes.

It's the same idea as last time, but bypassing a weird protection.

Greetz!!

Due to the news that there are a few ghost busters on the wild, and no one is willing to tell us exactly what's the ghost about, I've been doing some research to find out proof that those ghosts exist.

I'm talking about Manuel Caballero's talk A Resident in My Domain:


From one of the pictures it tells us that there's some relation to iframes.. and also from the description of the talk it tells us that it is able to capture non-domain-privileged DOM attributes and methods ( if we could steal cookies, then the description would be a lot more apocalyptic ).. and well, we also know it is cross-domain..

1. So, the first "fact" is that using the iframes on any website, you can capture top.location's and keystrokes (this is well known).
   
   
2. So, there's a way of modifying iframes on a window, on a domain is not ours.
   
   
3. So, we need a way of getting a reference to a window.

There are some ways of doing that:

• window.opener.window
• open().window
• frames[].window
• top
• parent
• [maybe others I don't know]

4. So, once we have that, we need a reference to the iframes.

There's 2 ways I know of doing that

• document.getElementsByTagName("iframe");
• window.frames[];

And, so.

• getElementsByTagName fails (IE6, IE7, FF2, FF3, Safari 3).
  
• window.frames[] doesnt fail (IE6, IE7, FF2, FF3, Safari 3);

So we will use window.frames[] to access the iframes.

Knowing that..

5. We will try to modify the location of such frames.

We have a few ways of doing that.

Via

• parent.open("new location","frame-name");
• frame.location="new location";
• frame.open("new location","_self");

The modification of location of iframe's location work on windows inside frames on IE6, IE7, FF2, FF3 (go here and then use this code) but we wont use a frame in a frame to get the reference to the window, since we cant detach a window from a frame, and so, it is not what the bug is about.

Anyway, none of the mentioned method work for windows gotten from window.opener and open() on FF2 or FF3, but it does work on IE7 on windows gotten from open() and from window.opener.

6. So so far, we have an exploit that only works on IE (6&7).

What do you say? is this the proton pack we were looking for?


For obvious reasons I wont disclose a IHE (Interactive Hacking Environment) as Caballero apparently has one, but I think this may be the bug, or some similar bug to the one he presented.

Greetings!!

PS. This doesn't work on IE8. thanks to thornmaker for testing.
PS2. There's a version that works on IE8 and all versions of IE7:
http://sirdarckcat.blogspot.com/2008/05/ghosts-for-ie8-and-ie75730.html

Well, after talking with David Ross about the last post (bypassing content-disposition), I found out that it's exploitation wasn't as easy as it appears since IE has done some updates on the last couple of months.. so well.. sorry about that.

Anyway, I guess it's time to say the world a little way of exploiting XSS vulnerabilities that echoes the value of a cookie.

This is based on majohn trick (setting headers via flash post), and well, I remembered about that when I saw kuza's talk.

This is done via flash:

class defconxss {
static function main(mc) {
  var req = new LoadVars();
  req.addRequestHeader("Cookie:bblastactivity=%3Cscript%3Ealert(document.cookie)%3C%2Fscript%3E", " ");
  req["1"]="1";
  req.send("https://pics.defcon.org/misc.php?action=cookies", "_self", "POST");
}
}

This is a PoC for a XSS at pics.defcon.org you can read more about it here: http://whk.h4ck1ng.net/2007-12.22/xss-en-defconorg/ but it's on spanish.

An important thing to say is that the cookies sent this way are not persistent by default, anyway, some codes make force them to be persistent.

So this works for me with the latest player: http://www.adobe.com/shockwave/download/

Anyway, internet explorer is not vulnerable.. damn..

You can download kuza's talk here: http://outpost.h3q.com/fnord/24c3-torrents/24c3-2212-en-unusual_web_bugs.mp4.torrent

Greetz!!

Well first of all I want to congrats my friend kuza55 because of his talk "Unusual Web Bugs" at 24c3, was a success.

I watched it on the stream, and even do it dropped every 2 minutes, the audio was sort of constant, so I was able to hear it.

So, it was awesome, and he used the stuff that was investigated and discovered lately, so that was a cutting edge talk.

Anyway, I tried to make kuza receive a message for the Q&A, that wasn't able to arrive, when you say that the header Content-Disposition: attachment is a restriction that no one has been able to bypass, well it's bypassable, and I dunno why I didn't told you about this.. anyway..

Suppose that http://www.victim.com/downloads.php?file=999 is a downloader that sends the header: Content-Disposition: attachment, then you can make IE to display the content as "the best guess", by caching it first, like this:

<script src="http://www.victim.com/downloads.php?file=999"></script>
<iframe src="http://www.victim.com/downloads.php?file=999"></iframe>

The iframe will load the cached source, and it will show the best guess IE can make.

I haven't tested this on firefox, sorry, but at least it works on IE 6 and 7.

So, that's mostly all, just wanted to say that..

Greetz!!

Well, the last couple of days I've been playing with hi5.

It's pretty cool, and I found a couple of XSS vulnerabilities.

I reported them to help@hi5.com, security@hi5.com, admin@hi5.com and all the e-mails I found on the domain hi5.com.

Well, they didn't responded.

So, there's a XSS Worm for hi5 on the wild.

The worm is on the following profile (if you visit it throught this domain you wont get infected, the problem lies if you visit it through www.hi5.com domain):

http://xssworm.hi5.com/

I'll alert you that the profile may be deleted by hi5 staff at any time.

I'll give an explanation on how this worm works as soon as it's controlled by the hi5 team, since it doesn't use XHR.. and some people asked me on the past if it is possible to do a worm without XHR.

To the hi5 team: there are a lot of vulnerabilities on your website, if you wish, I could help you with them, just respond the freaking e-mails.

cya!

UPDATE

I've finally been contacted by the hi5 team, we are working on solving the XSS & CSRF vulnerabilties.

This week, I've sort of improoved the CSK of Gareth Heyes, with a few more event handlers, and interoperability with Opera (and menus!!).

This new version is over here:
http://www.sirdarckcat.net/csk2.html

Anyway, with the research I did, I also found the bast world of possibilities implied on CSS.

Starting from the CSK2, I've developed a game made in CSS with no javascript (anyway, you can only play once).. which currently works on all browsers, except from IExplorer.

I also used this knowledge gathered, to make my final project on the university (it was just making a website.. haha): http://da-vinci.awardspace.com/ this works just on firefox (don't tell my teacher, :P)

On some other news, thornmaker and I, where trying to proof that CSS + HTML is Turing Complete, anyway, since we dont have a way to make real loops (evendo we had some ideas about including bindings that include themselves until a condition is made, that could work as recurtion), it "appears" that CSS+HTML is NOT Turing Complete.. anyway, I'll continue investigating to be sure.

Greetz!!

Well the research made for the exploit for the joke for rsnake is sort of interesting, so I'll try to explain what was needed (even do it was unsuccesfull).

This was made with the help of the research made by the members of sla.ckers like ascii, gareth heyes, rsnake, Jeremiah Grossman, thornmaker, Wisec, kuza55 and me.

It exploited a bug and a feature from ha.ckers.org:

• bug: http://ha.ckers.org/xss.swf
• feature: http://ha.ckers.org/blog/wp-admin/anything is protected to everyone besides rsnake and id IPs.

And a feature from Firefox:

• feature: XBL bindings.
  

Some bugs from NoScript:

• XBL Frame Injection to bypass NoScript IFrame protection.
• setter/name NoScript anti XSS filter bypass.

(this bugs have been patched since version 1.1.7.8 of NoScript)

You can read the comments from Robert Hansen, and Giorgio Maone about this exploit at ha.ckers.org and hackademix.net (oh jeremiah grossman also talked about this here and some others in langs that I dont understand).

The only thing the exploit required was that rsnake had ha.ckers.org white-listed on NoScript, but it didn't succeed for that and some other secret reasons.

For targeting the exploit just for rsnake, and hiding it from other persons, we did 3 things.

First we checked if rsnake had ha.ckers.org/blog/wp-admin/post-new.php on his history via CSS History check without javascript.

If this was unsuccesfull because of the "SafeHistory" plugin, or any other reason, we checked if his IP had access to ha.ckers.org/blog/wp-admin/wp-admin.css stylesheet, if he had, we would try to exploit it.

For doing that we played with display:block/display:none properties of iframes, but in the case that rsnake had NoScript iframe protection enabled, then the exploit would be unsuccesfull, so we added a -moz-binding, for detecting NoScript presence, and replacing it with a frameset/frame.

With that, we just redirected rsnake to the payload, the problem was that NoScript detects reflected XSS attacks, so we needed to find a way to bypass it, and we did.. (http://ha.ckers.org/xss.swf?a=0:0;a/**/setter=eval;b/**/setter=atob;a=b=name;)

That in un-obfuscated code is:

eval(atob(window.name)).

atob=decode base64.

The reason this bug works was a mistery at the begining, but after Wisec re-constructed the as2 bytecode he saw that there where some variables appending to the url, and then after some more research this is the reason this guys found out (explained by kuza55):

the Flash file looked like this:

getURL("javascript:('XSS')", "_self", "GET");
stop();

That third parameter turned out to be the key (though we only found this by an absolute fluke), initially we just assumed that the third parameter was just saying it should be a GET request, but the third argument does more actually:

[www.adobe.com]

getURL(url [, window [, "variables"]])

[snip]

variables: A GET or POST method for sending variables. If there are no variables, omit this parameter. The GET method appends the variables to the end of the URL, and is used for small numbers of variables. The POST method sends the variables in a separate HTTP header and is used for sending long strings of variables.

Now, seeing as in AS2, all variables which are passed on the URL are imported into the global scope (like register_globals), we get it sent with the request. Now seeing as there was no semi-colon at the end of the first argument, we were able to abuse the fact that the ? is not only the thing separating the variables in the URL from the file, but it is also the javascript ternary operator.

So we simply used this to finish off a valid statement using the ternary operator, and then specified our XSS.

The window.name trick doesn't require a javascript doing window.name="payload".. it required just a frame named as we wanted.. (< iframe name="payload">) since NoScript strips any char matching [^a-z0-9_\-] with space in window.name, then we needed to encode the payload in base64 and remove all the "+" and "/" chars of it via whitespacing where they where shown.

So, we posted a comment with a link that may attract the attention of rsnake when moderating the comments, and we only needed to wait..

Then, we saw the anti-climax.. the comment was aprooved, and the payload wasnt triggered.. lol (hey spammers)

So we did another post, now with a link that appeared to be spam, and we did..
http://owaspnj.blogspot.com.

Any way, that comment wasnt aprooved, and the exploit in there (that was clearly more hidden than the ultimatehxr.googlepages.com) was not necessary.

So you can see the exploit here (it's commented :D):

http://www.sirdarckcat.net/blah2.html

if you want to know what's blah1.html, it's just how we where trying to detect the wp-admin.css.

The last thing is to explain the functionment of the payload.

1.- via XMLHttpRequest, it asked for /post-new.php source code.
2.- it created an iframe, and writted inside that iframe the source code with a.. "< base target="/wp-admin">"
3.- Then he submited the first form modifying the title, content, and tags fields, and clicking on publish (yeah we wanted the payload to had tags).
4.- And that was all, no RegEx.match for finding nonces, and nothing :P..

You can see the content of the post as it would appear if the exploit suceeded here:
http://rsnakex.wordpress.com/

Greetz!!