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