I’ve been sitting on this one for about two years now, and I still haven’t done anything with it, nor do I think it can really work in the way I originally came up with, but I thought it might be better to throw it out to the public in case anyone else has something ingenious in their heads. Several years back when I was first working on cross domain leakage I realized that Java has access to images pulled from remote sites. You can see this with fun things like waves in images or whatever. Flash pretty much took over where Java left off, so not a lot of people went beyond that for animation (what’s the point when Flash makes it so easy?).

But herein lies the information disclosure. The image itself is read by Java and it is linked to from another domain. If Java can parse apart the pixels and perform actions on them (log them to a remote host via form submission), that means it has access to read information from other domains. Now that’s not particularly sexy unless there is some sensitive information in an image (think bill pay services that scan bills in). But what I was really going after is some way for Java to read each pixel of a page (probably an iframe). Sort of a pixel by pixel scan of the underlying page.

Sure the output wouldn’t be text, but an image representation of cross domain information could be almost as valuable (or could be fed through a image to text conversion tool). Like I said, this isn’t proven, and I don’t even know if it would ever be possible, but I’ve also not put a ton of thought into it, nor have I sliced and diced a lot of Java programs looking for ways to do this. The obvious trains of thought were using transparent images, calling a page an image, using embeds or other similar things. No, I have no proof that any of this would work, it’s just a theory that I wanted to throw out there in case anyone could think of anything spectacularly ingenious. Take it or leave it.

It’s true, because Firefox tells me so! I didn’t even realize it myself until my browser so nicely informed me that my post about extortion was potentially phishing for my password. And here I thought my site was working for me. All this time it was trying to steal my password! Thank god my browser is there to help me, cuz otherwise I would have… uhm… put my password in… somewhere… no, wait… maybe… uhm… on the page… uhm… I guess… hmmm… nothing here says password anywhere… maybe in that box that says comments… cuz that looks like it could steal stuff from me. I suppose you can sense my sarcasm, but really, come on. How is ha.ckers.org possibly anything like a phishing site? Click here to see what I saw this morning. As of the time of this blog post it’s still not fixed.

If there is anyone on earth who should be whitelisted, it’s this site, given the fact that there is zero chance I’d ever put a phishing site up on this website (if I wanted to be a bad guy, I sure as hell wouldn’t do it on my own site). Hell, I used to work on anti-phishing software. But this strikes me as strange. What is the vetting process involved in putting something on a suspected bad site anyway (clearly it’s not working)? From what I can tell there’s not much going on under the hood because there’s not a single thing on that page that looks anything like a phishing site.

If I had been running a big commercial site, this could have had severe impact on my ability to do business, and my reputation with my consumers. I don’t think most people realize how bad this kind of thing is. Ha.ckers.org is one of the few sites that really is not impacted at all by this sort of thing, but I know I’d feel differently if I were running an e-commerce site. Time to re-vamp the heuristics and the process boys. Color this security guy unimpressed.

Update: Apparently I am also put on the MSFT anti-phishing list as well Click here for a photo of that as well. So it looks like this isn’t heuristics based after all. Someone actually manually added me to the phishing list. Because that extortion post really looks scary. Nicely done guys.

Ever since Microsoft posted a rather well-thought out comment on sla.ckers.org asking that people use responsible disclosure methods and talk directly with Microsoft, there has been a bit of a debate raging about disclosure compensation. It seems fairly split that people feel that they should or should not be allowed to request compensation or some sort of monetary remuneration for finding exploits in a website and disclosing it responsibly.

Half seems split feeling that if it’s not the company who pays it will be some other group of malicious people who will pay for it. This flies in the face with the concept of responsible disclosure, as the company would have to get close or beat the asking price of the malicious groups who would want the exploit in the first place, making it economically difficult for companies to justify buying them (not that they would, but even if they wanted to). So it is a case of free market economy or being the nice guy? Anyway, it’s an interesting read.

Behind in email again, I’m finally getting around to some older email (don’t be hurt if I don’t respond right away, my inbox is the bane of my existence). Gianni Amato sent me an interesting email the other day showing how Yahoo’s login redirection can be abused to steal the real name, the Yahoo email address and the email address used to register the account through a simple redirection:

Click here so you can see the string (if you aren’t already logged into Yahoo it will request that you do). After going through the Yahoo script the string “.data” is appended, which is a base 64 encoded string which you can decode here. Inside that string, as you can see, is the email addresses associated with the user, as well as the username of the victim. This would be particularly useful if the user is already logged into Yahoo (where they don’t have to log in). Just set up an iframe through an XSS vuln on any site, and steal user’s information.

This is a classic case where a simple mis-used redirection can be used for something far more nefarious. Redirects are just never a good idea. Anyway, great find by Gianni!

This is a mostly non-technical post where I wanted to talk about the concept of application original sin. Every application has original sin, meaning it was conceived. Any application had to start somewhere. It started with a single line of code, to be precise. Or maybe it started before that with touching a file in a directory. That user had to have file permissions to write the file, the file itself took test data, wrote into test databases, and so on. On and on the application development went until it was complete with its very first version. But that’s very rarely where it stops. Often you can find an application living well into future years, being molded and expanded upon. But all the while it stemmed from that original sin, making it very hard to change beyond what it was originally intended to do.

Last night Jeremiah and I spent a good long while on the phone talking about cross site request forgeries. The short of it is that we are all pretty screwed. The internet is so incredibly flawed that there is essentially no hope at the moment. But what would it take to fix it? The first thing that popped into my head was Wordpress and how they created nonces for certain tasks. Sure, that’s nice and all, but the amount of websites that are vulnerable only because they run Wordpress is pretty small. Any open source package has got a higher chance of fixing these flaws (if anyone ever got around to fixing them all and releasing a new package). But even that is pretty unlikely.

Then you start thinking about all the other applications that are completely proprietary. Each one of them would need to be modified, not just to stop CSRF, but also XSS since XSS can often read nonces. Ouch! Given that a huge percentage suffer from both of those attacks, I don’t see this happening anytime in the near future. So what do we do? Are we really and truly that screwed?

Mozilla contacted Jeremiah, Billy Hoffman and I to look at the new cross domain XMLHTTPRequest standard they are thinking about building into Firefox. There was only one small new hole introduced by creating something that I think would make most security people wince. Why’s that? Because it’s already so broken! Adding another function that allows you to break security in another way doesn’t change your actual attack surface area by much. Sure there will be downstream dumb things that are created with the applications that are built off the technology itself, but it’s not like this is mind blowingly bad security - at least it’s not much worse than how browsers currently function. Not to pick on Firefox in particular, because every major browser company is at fault here (that I’m aware of).

I got this message from a friend today, “seriously seriously? I’ve got to surf around with Javascript AND CSS turned off?” He didn’t even mention Java, VBScript, Flash, ActiveX and a host of other things. I’m afraid due to cross site request forgeries it’s far worse than that even. Every image, every included style, every iframe and frame, everything that’s embedded in any way, can cause CSRF. It’s the “holy crap that’s bad” vulnerability that affects nearly every site out there. The only trick is getting the right person to perform the action and that’s really not as hard as it may sound. Not to mention all of the insane amount of information leakage found on the internet. I’ll have to write a paper on this topic sometime. It’s ridiculous how much information you can get from a single hit to a webpage, it really is.

Ultimately, the point here is what I think we all feared. The Internet just was never designed to be secure. It’s suffering from it’s original sin - it was conceived and built with ease of use in mind, not security. And due to new technologies being built on top of it all the time, we can’t even retrofit at the pace that the technology is evolving. When the experts in the field are telling browser companies, “It’s so messed up anyway, there’s no sense in worrying about creating equally insecure functions at this point” you know you’ve got problems.

Well, just as I predicted the technique I talked about the other day to do CSS history hacking without JavaScript can be ported over to do port scanning as well in Firefox. Using forced browsing in Firefox you can open a series of iframes that will report back to the parent page in real time that the user has visited the page in question. If the page doesn’t exist Firefox marks it as not visited. Hong built a proof of concept that he talks about here.

Unlike Jeremiah’s technique this does not use a timing attack, however it is pretty limited since it is slow (due to the extremely long timeouts associated with servers that aren’t there) and the fact you can’t make decisions based on the results you get from the attack since the page isn’t dynamic. Very interesting stuff though. Nice job, Hong!

And before I forget Sid Stamm alerted me to another place on the web that mentioned using CSS as a history stealing attack as early as in 2002 (where was I)? Anyway, I just wanted to make right on that. Not that I stole the idea, but I certainly didn’t come up with it first.

It took me several days to get around to looking at this but indeed, it is definitely worth posting for all you MySpace hackers or people who encounter the allowscriptaccess=”never” flag in Embeds. Yes, it can be subverted - by using PDF XSS:

Hi,

I recently exploited a website with a vector which is not on your website.. you can use embed with the pdf xss.. the fun thing about this, is that even if the <embed tag has allowscriptaccess set to never, it still executes!

<embed src=”http://www.younggunsdesign.nl/haxorz/hack.php”
allowscriptaccess=”never”>

Indeed, just as he says, I was able to test this in IE7.0 and get it working (my Firefox install has been severely crippled after the UXSS in PDFs fiasco we saw last month). So I was unable to verify in Firefox, but I’m sure someone else will chime in. Anyway, very nice find by Huib!

Click fraud is a big deal (Google claims it’s as low as a few percent but other leading industry experts disagree and put it much higher). I was actually fairly impressed that Google not only acknowledged the problem but is actually taking steps to prevent it that are visible to the consumer. Google announced a blacklist for domains that advertisers feel are highly likely to commit fraud. I kinda like this concept but like everything the devil is in the details.

Firstly, is an advertiser going to be able to block specific URLs, specific domains, specific URLs with keywords, or is going to be ultra high level like a “by category” type system. And how will the bad guys subvert that? I think we all know how poor blacklisting works even with something as fine grained as HTML, let alone entire classes of sites of the Internet. Also, what will happen with an advertiser who blacklists a domain while other people are visiting that exact domain? Will the banner magically disappear? I think not, so what happens if someone clicks on that link? Has the website taken a risk that the advertiser can turn off the link at will and refuse to pay (allowing for advertising fraud), or will Google force them to pay regardless?

Ultimately, I don’t think the solution to Google’s click fraud numbers has anything to do with blacklisting. It’s a neat consumer feature, and may give them some small clout with advertisers who ask for this sort of thing all the time, but really, it’ll make next to no dent in the overall fraud numbers that Google sees (at least that’s my prediction).