Sunday, September 30, 2007

Universal youtube mods XSS explained in 7 steps

Well, I want to explain first, this was not my idea, someone at 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:{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..
  6. Sixth, the redirection page inside youtube is
  7. Seventh, using step 4, 5 and 6 the exploit is like this: [youtube=1,1]../confirm_email?next=[/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)

List of SMF vulnerable mod's:

Not vulnerable:

Unsafe IPB youtube mod instalation:

Friday, September 28, 2007

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
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
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()){
setRequestHeader("Content-Type","application/atom+xml; charset=utf-8");
setRequestHeader("X-GData-Client","JavaScript-V1.0-Google Mashup Editor");

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

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).

Thursday, September 06, 2007

Allowing debug in a javascript library

Hi, some days ago I watched John Resig Tech Talk, about building a JavaScript library, where he pointed out some "good habits", when programming, and when doing js libraries, pretty interesting.

Any way, he mentioned that we shouldn't use try&catch because the coder "cant" debug his code, because we trap the error, and he is never able to see it.. so, I thought that an interesting way of letting the "error pass", but still have controll of the library is using setTimeout, to let the code run asynchronously.

The code I submitted to his blog, is:

setTimeout(function(){/*code here*/},0);

So, the error is reported to the user, and we dont loose the control of the code..

Some time after that I thought that, it could also be used for letting code runing in memory.. (but it's cancelled as soon as you leave the website).

Any way, as a programmer, I see this as a technique for running more than 1 process at one, as a security researcher, I see this as a technique for running XSS payloads in a more sigilous way.

Saturday, September 01, 2007

7 minutes to kill a monster.

Well, a response time of 1 week, is said to be good, Mozilla has 10 f***ing days, Google depending on the complexity of the vulnerability takes between 1 day to a few weeks to fix them, but Mario Heiderich, developer of the PHP-IDS, has an amazing 7 minutes time to pull a patch for a vuln.

A week ago, he talked me about a "call for hacking" to PHP-IDS, and I said it would be really difficult, because the last time, the filters where extremely enforced, so I started playing (before the call for hacking was published), and in an hour I found 3 vectors, and made a PoC, of 666 bytes (that's why it's a monster xD), 2 of them where based on Giorgio Maone vector.

So, I asked Mario, if I have to wait until the call for hacking was published, but he pulled the patch immediatelly.

A few minutes later, I found another HTML vector ("style="anything), that was fixed too.

So he decided to interview me, as a price for winning an unstarted contest :P.

The vectors where:

  • open(name)
  • eval(name)
  • (1?(1?{a:1?""[1?"ev\a\l":0](1?"\a\lert":0):0}:0).a:0)[1?"\c\a\l\l":0](content,1?"x\s\s":0)
I'm sure that Gareth Heyes, and Giorgio Maone will be the next to find some vectors :)