Matan, Jeremiah and I have been chatting a bit lately around the CSS history stealing hack that Jeremiah came up with and presented at his Blackhat talk a few weeks ago. One of the ideas Matan came up with I think is worth posting, because it really does show a rather interesting application for CSS history stealing that I hadn’t thought about before.

In its simplest form, once a user visits a certain web page an attacker could choose a random unique id for the user and then force him to visit a URL (through a hidden iframe) containing that unique ID. Then on a subsequent visit the attacker can make the user iterate through all the unique ids that it ever generated and see if the user visited any of them. If he did, then the attacker can know the user has already been to his site. Furthermore, the URL with the unique id can point to a script that stores and retrieves the data the attacker would like to save for the user.
Of course, in the real world this wouldn’t work well because as the number of visitors increases, so do the number of URLs a user would have to iterate through. When it comes to thousands or millions of users this could take quite a while. To solve this, an attacker can use a hierarchy of folders (or most likely virtual folders that don’t even exist). So let’s say you have a special folder /spy/ on the web server. This folder contains numbered subfolders 0-9. Each of these folders would contain 0-9 more subfolders. The nesting of the folders could be around 10 folders deep which means the site can hold 10^10 unique ids. Then the attacker can generate a random path for the user and force him to visit each of the folders in the path (so the final path would look like /spy/3/6/8/1/7/2/3/4/8/9). In this example it would take 10 URL accesses to reach the end of the path. So once a user enters the site again he would have to iterate through a maximum of 10 * 10 links in a worst case scenario. Of course, security-wise for the attacking site this is bad as random users would be able to impersonate other random users and mangle their stored data. But this can be overcome by generating valid paths using an algorithm only the website knows and most complete paths will lead to a dead end.
Do you think this could work?

Yes, yes, it very easily could. This is actually an interesting way to get around some of the issues really large sites have with companies like AOL that have massive super proxies with upwards of 30k people behind a single IP address. You can “cookie” them in this way with a relatively small footprint compared to an actual cookie (which is often killed anyway by security products or turned off entirely by paranoid/malicious users) and upon a user repeat visit you can detect them once again. It’ll be interesting to see how this attack evolves over time, as I am sure there are dozens of other interesting ways to use these attacks. Special thanks to Matan!

In the same vein as the IE specific res:// URLs that can help you detect Internet Explorer, I’ve taken that detection one step further in Firefox. After discovering the issue with IETab where a user can be maliciously forced into the Internet Explorer rendering engine it got me thinking about ways to even detect that that is possible. How do you know your target is running what, and how to do you take advantage of that information. Taking advantage of it is a huge ball of wax and it completely depends on the browser plugin in question. In this case, the IETabs issue was pretty straight forward, but others may not be so straight forward, and will take a lot more time to analyze (by probably many more people than me alone).

But while messing around with WebDeveloper’s DOM “generated source” utility I happend upon one of my plugins’ information being written into the DOM. In tracking down the chrome element, I realized that it too has a similar issue to Internet Explorer where items can be mapped if they are registered. Specifically, images of all things. Now the naming convention isn’t standard, so you can’t just write one that works for everything but I took the time to map out each of the ones I could find so you wouldn’t have to dig.

In Firefox (with JavaScript turned on) click on this URL to show some of the plugins you may have. Sorry for the popup, but it does have some weird interactivity, which I haven’t diagnosed fully.

Knowing what your target has installed is both a way to fingerprint the user as well as a way to bypass whatever security settings they may have (knowing what they have installed can help you figure out ways around it, or use it to your advantage as we saw with IEView). I’ve always thought the plugins would be Firefox’s major security flaw. Looks like we’re getting closer to proving that fact.

Well it’s official and no longer just conjecture. Google’s redirection hole is now being used as a phishing redirector. I don’t know how anyone could reasonablly argue that this isn’t a problem now. It’s not me just spouting what could be or what might be, this is actually happening. Redirection without some way to whitelist is dangerous for your brand, and it’s bad for your consumers when they trust your link and go to a phishing site.

http://www.google.com/url?q=http://66.207.71.141/signin.ebay.com/Members_Log-in.htm

It was bad enough when it was simply being used for spam, but now we are talking about user’s accounts being compromised. I understand this is a very complex issue to fix, having dealt with these issues in the past myself. Understanding it is no excuse for not fixing it though. It’s been about six months since I first reported many of these issues.

While following a thread on the sla.ckers.org web application security forum about browser plugins for FireFox I remembered a project I had worked on briefly to exploit a small issue in one of Firefox’s extentions. The problem is around how IE Tab has built in sites to always render in IE Tab. The two default websites are http://*update.microsoft.com/ and http://www.windowsupdate.com/ for obvious reasons.

When I was first playing with this, I was thinking about it in context of DNS tricks, but then it occured to me yesterday that that star operator really felt exploitable (I love when people don’t really understand regex). Anyway, so in playing around with it, I realized if you just append “update.microsoft.com/” to the end of any URL string (you can use a query string or a variable that doesn’t exist in an existing query string) you can begin running Internet Explorer in your browser window without even so much as a prompt.

If you have IE Tab installed click here to see a demo: launch IE in your browser.

Oh, but it gets better, if you ever find an XSS vulnerability in any website and you append that string to the end of the URL (CSRF) you can now run your vectors in IE space instead of Firefox, allowing you to run VB Script, ActiveX controls, and whatever else you want, without the restrictions of Firefox. Let’s take it one step further. You can actually launch XSS attacks against the target who has IE Tab with IE specific XSS vectors and since they will automatically switch into IE mode, you can get them to run on a single redirection. Tricky, eh?

I’ve always thought that browser plugins are one of the major security flaws in FireFox but this is a weird turn of events where it’s actually a cross between FireFox, a plugin and Internet Explorer. I think the major saving grace is that only 10-20% (estimated) run FireFox and far fewer run IE Tab. Why is this any different than just running Internet Explorer outright? Well because if you are a die hard FireFox user you probably spend far less time trying to harden IE than die hard IE users. I’m pretty browser agnostic, so I harden everything, but most people won’t - or don’t know how. I think I’ll uninstall IE Tab anyway.

One of the most annoying things for many users is filling in form fields on websites. It’s tedious for them to type the same information over and over again, especially when it’s something a simple as a their personal information like name, phone number, address, credit card number, expiration date, and the like. Unfortunately this can spell trouble for many users who use websites that are vulnerable to XSS.

Some (not all) automated input automation tools do so blindly. That is, they don’t ask for user input when they input data. In fact they don’t really do much validation at all, except the names of the common form fields. So what does the attacker do? They create a form submission inside their XSS script with all the common field names that they are interested in. Once the automated input box enters all that information it captures it and logs it.

The best part is the form submission does not have to be visible. In fact, it probably works better if it’s not, because then it is highly unlikely to raise suspicions. It’s really not phishing, as it doesn’t actually require the user to believe anything, as the social engineering portion of the attack is not there (assuming the XSS itself doesn’t require it). As such you can steal user information through any page, as long as the automatic form submission requires no user input to fill the form.

While I was playing around with some very odd security issues in Internet Explorer and Forefox, I ran accross an interesting thing that Internet Explorer exposes when it is giving certain error messages. Internet Explorer exposes a few images that allow you to see if the browser
is in fact Internet Explorer regardless of things like User-Agent spoofing. Click here to run the detection (you need JavaScript enabled).

Of course there are dozens of ways to do this but this is one I hadn’t seen before. There is another document other than res://shdoclc.dll/refresh.gif like res://shdoclc.dll/search.gif, res://shdoclc.dll/pagerror.gif, res://shdoclc.dll/back.gif and others, but you get the point. Any of them could be used to detect that the browser is Internet Explorer for targeted attacks or for simply knowing more information about the user beyond their user agent. This is yet another reason why I think users spoofing their user agent as Google to catch blackhat SEO is pretty ridiculous.

There’s a fairly in depth article at BusinessWeek that goes into click fraud and what is being done about it. Once upon a time I used to work for one of the very first banner advertizers on the web, so I am personally very familiar with how click fraud works and how to stop it. In fact, when I started, we were seeing numbers in the 10-20% range of fraud and when I left, we saw less than 1% fraud. Still, if you consider that that could account for millions of impressions and hundreds of thousands of clicks it’s still a huge number that advertisers don’t want to shoulder in expense.

First of all, let me get my rant out of the way. Banner advertizing (not text based, just the images) is highly flawed. The advertizers will ask you to create a banner that his highly attractive to consumers (like hit the monkey) the problem with that is that they create a huge amount of clickthroughs which is great for the banner advertizing companies, but it’s terrible for the advertizers because they don’t make any money off of it. Unqualified leads aren’t worth anything. It is really in your best interest to make the most ugly banner possible, that no one would ever want to click on unless they knew for a fact that money would immediately be withdrawn from their account. Anyway, sorry for the rant.

Okay, so how do banner advertizers catch you? Well without disclosing everything, there are a few key things to remember. First of all is ratios. If your ratios get extremely out of whack (over 1% clickthroughs/impressions) it’s highly likely that you are fraudulent.

Second, you are exposing only what your browser exposes (referring URLs, user agents, etc…). So if you expose the same thing over and over, or fail to do so, your ratios are off in that way too.

Third is cookies. For repeat users, you probably should have a series of cookies. Chances are you have had a cookie set by one of the banner advertizers. If for some reason none of your traffic ever send a valid cookie twice, that looks bad. Then there is the inifinite monkey thing, where they set up fake advertizers with free contests. If they never see anyone click on the free contest to win a plasma TV then they know your traffic is fake (in an infinite monkey with infinite typewriters situation). Think about click fraud detection as anomaly detection.

Of course, with the advent of Flash and JavaScript as a delivery mechanism instead of just images, now you have a lot more insight into the page the image is located at and the user who is viewing it. All the things in my tracking post below are possible candidate, plus all the JavaScript environmental variables like screen resolution etc… are exposed. Click on the environmental variables page to see what I’m talking about (with JavaScript turned on). In this way the advertizers have access to a lot of personal information about you that cannot be forged by simply changing an IP address.

So what does this mean for modern click fraud? Well most of this stuff has been known by me and a few others for almost a decade now, but it hasn’t trickled to some of the bigger advertizing companies yet - plus it is non-trivial to build in some cases. You can view the JavaScript source of Overture or Adwords to see what they are logging (if you can decipher their JavaScript), but the flash movies are a touch harder, as they are really truely dynamic. The nice thing about JavaScript and Flash as a delivery mechanism is that you aren’t static. You are running a remote peice of JavaScript that you have no control over on your page. Is that a good idea? Do you trust anyone to control any website you put their content on? This is the definition of XSS, only you have to trust the website it resides on.

It can be done under the guise of understanding what is on the page so you can do targeting, but in the end they are doing data collection. They want to know what is on the page, who is calling it, and if they are committing some form of fraud. The trick is that they have only recently been figuring this out, as you can see by the statistics of how much they are paying out in fraud loss. In fact it was mentioned as one of the main ways that Google could fail as a business model. Having worked in the industry and invented a lot of the technology I’m talking about, I really have no opinion about it. Lots of it is flawed, which is why I quit - click fraud prevention is just too flawed.

There is a small article on MercuryNews today about three ways to be tracked online. Well that’s three of maybe hundreds of ways, but it’s kind of interesting reading from a newbie’s perspective only because it’s clear they do not have a grasp of all that is out there. Yes, cookies, IP address and registration (not sure how that third one isn’t really just a combination of the first two + more information), but there are dozens of other ways to track movements across the internet. Here are a few in no particular order:

Referring URL. This is one of the most interesting environmental variables because it’s not used that often for tracking purposes except for websites, but really, it’s a pretty useful tool for knowing information about your users. For instance if you see them coming in from a particular search engine you can know what they were actually looking for which can give you insight into that user.

Language encoding. That’s a pretty simple way to at least know which languages the user is interested in, if not which country they are from or currently living in.

X-Forwarded-For. Well, using a proxy is a great idea, but not if it gives up your remote IP address.

Flash cookies. Why not cookie the user with flash? It’s harder for them to clean, and lesser known!

Persistance. Only works in IE, but hey, it’s hardly known and hard to clean.

SSL session IDs. They only change when you tell them to, so you can track people between pages on SSL connections unless the user closes their browser.

CSS history tracking. As Jeremiah found, I can know where you were. The possibilities here, are practically endless as far as knowing things about the user. Clean your history often!

Browser plugins. Spyware is the best way to track users, bar none - well maybe besides a full blown trojan.

DNS tracking. Well if you’re going to be a man in the middle why not know every single website the user is going and track that back to a user? Sounds like a good way to track people to me! I wonder why Google would want to start it’s own ISP? Hm!

MITM sniffing. If you happen to run an ISP, why not track every single request? In the case of content filters, it’s a given anyway!

Mail. You write it, your ISP routes it, your freemail provider logs it forever. There are tons of places for this to be used against you.

Search engines. Ever used a public social networking site? It’s public record now and forever thanks to the WayBackMachine. Think twice before sending that email to the public mailing list.

I’ve probably missed a few hundred others, but trust me, there are way more than three ways to be tracked online. Sometime I’ll have to write up the story about how one of the anti-virus guys ended up tracking down a few phishers using nothing but some photographs. The point being, if you are on the net and you have any discernable patterns and use any machines that can be tracked back to you, you are leaving a trail that can be followed.

I got a disturbing email from one of the more frequent posters on the blog the other day where he said he felt funny posting so much. That’s ridiculous. I get why people want to make sure they aren’t spamming me, but this isn’t a one sided conversation. On top of that, I’ve noticed a lot of side conversations between multiple users, which is encouraged, but it probably makes more sense on a forum setting. So id and I decided to throw together a forum for everyone interested in web application security to use at sla.ckers.org. It’s free, and it’s designed to talk tech, and it’s so named sla.ckers.org because you all probably have better things to do with your time.

I put some high level topics together that we can discuss, but if you have other things that you are interested in let me know. There are some known bugs on the board, so bare with us until we sort everything out, but it should be working. Feedback is welcome (there or here).

I’ve been talking with Jeremiah Grossman about his history revealer a lot over the past few days (I’ll probably talk more about it in some later post), but I started thinking about additional applications for knowing where someone was beyond the obvious stuff. It then occured to me that there is a way that porn sites and other blackhat websites can monetize traffic that they haven’t touched yet, to my knowledge.

There’s a pretty old trick where once the user clicks on a link they are immediately taken to another page. When the user finds that they are on a page that they aren’t interested in they hit back on their browser. When they do that they land back on the page with the redirect and they either get redirected again or to another website. This is a pretty aggrevating user experience that just makes them hit back on their browser twice quickly, use the history drop down or manually type in another website to escape the site. As they do so the malicious website looses that user - probably forever.

It just occured to me that there is a better way to monetize that traffic based on two factors that are known. The first is where the user is coming from. Thankfully most browsers send referrers. If you know the referrer of a search engine you can tell exactly what they were looking for and what all the other links on that page are. Stay with me.

When the user clicks back on their browser, instead of blindly sending them off into redirect land which is a highly frustrating experience, why not serve them up a page that looks exactly like what they would expect to see by hitting back on their browser? How does that help? Well if you can completely re-create the page that the user expected to see, you can change all the links on the page to things you own, with the possible exception of the previously viewed links (which you can know using Jeremiah’s trick). You can then hijack the rest of the links with JavaScript onclick events or just serve them up completely different links - either way. Instant page rank, without even trying!

Now the user gets the search experience they would expect but now you completely control everything the user will find upon searching and clicking. I bet more often than not the user won’t even notice they aren’t on the search engine website because they will be served up an exact replica. Without looking at the URL they will still be convinced because it looks exactly like the last page they were on, complete with the search results and the viewed links.

Of course if you do this you are risking getting lawyers all over you for trademark infringement blah blah, but I’m not sure most blackhats care about that kind of thing - if they can be located anyway.