Good for Mozilla - they recently fixed a very odd referrer spoofing issue that I was talking about back in January. It wasn’t exactly ten days, but who’s counting. But referring URLs are a tricky beast. I see them being relied on an awful lot. I also see a lot of misbehaving robots in my logs that seem to think they understand what a referring URL is, but yet… they don’t.

One good example are robots that forget how Google works: http://google.com instead of http://www.google.com/ (notice the “www.” and the trailing slash are missing.) Also spammers, please note that as of today and every other day I have checked I have never once been a link on the front page of Google’s website and if it did happen, there will be a great earthquake; and the sun will become black as sackcloth of hair, and the moon will become as blood, so we best not even talk about such things. There’s tons of this garbage in my logs all day long. It’s almost surprising to me that the bad guys would bother. If anything it makes it stand out like a sore thumb. Yet, I do see companies making security decisions based on referring URLs. Kinda scary given how many reasons referring URLs might be wrong or non existent.

As a side note, when I attempted to use the :username@ trick for phishing it did not silently drop the username, it actually redirected me to the search engine, which is actually pretty appropriate behavior given that it’s malformed. I’m glad someone was able to reproduce it because I had a hard time proving to myself that it was even something widespread enough to talk about. Anyway, Kudos to Mozilla for the patch!

After almost a year, I’ve decided to re-visit an old post I wrote regarding solving CAPTCHAs for cash. Specifically, people that want to use Google or Yahoo to spam, by automatically signing up for thousands of email accounts which requires humans to solve CAPTCHAs for them. According to MessageLabs, webmail based spam represents approximately 4.2% of all spam on the Internet - pretty significant.

There have been a number of articles on the Internet about automatic solutions to CAPTCHAs, but honestly, I find those stories somewhat dubious at best. Firstly, I don’t believe the solution rate is all that high as some people are claiming (it’s possible, but I don’t believe it’s happened for Gmail or Yahoo mail at the moment - if someone has actual proof I’d love to see it), secondly it’s super easy to change an algorithm to make it non-solvable again - keeping the automatic solutions at bay long enough to build another algorithm and so on. Lastly, there are very few people with the sophistication and know how to develop and use these tools as a percentage of the people who spam.

However, none of this issues deter a human CAPTCHA solver. If you remember my last article on this, we were seeing the economics drop significantly to where this is suddenly worthwhile, and if you read the comments of that post even more of these CAPTCHA breaking crews are popping up all over the world. Why wouldn’t they? Someone is willing to pay for it, so why wouldn’t you, if your family needed food? Sure the money may or may not belong to the spammer, but legit or not, the money is still real enough.

That leads me to something I found on the Internet while I was searching for more information on the economics of it. During my searching, I happened across some job offers for CAPTCHA breakers (also known as data entry). The advertisement was pretty intriguing:

Click to enlarge

The way the job offer is written is like it’s a stay at home sales person, or some other sort of semi-professional position. Words per minute, 12 hour shifts, a PayPal account along with an internet connection appear to be the only pre-requisites. I thought it was fascinating. Also, the economics appear to have dropped significantly from the last article I wrote a year ago. Now people are being paid $1/1000 CAPTCHAs solved, rather than five to nine times that, which is pushing this market into different directions due to increased competition. Perhaps there are other additional benefits for using a more expensive Romanian service verses the cheap version the Philippines are offering.

Unfortunately, I haven’t seen the operations personally, so I have to speculate that it’s less about the service and more about the cost of operations in the various countries. If anyone is willing to show me their operation I’d love to see it. In the mean time I think we should think about what exactly CAPTCHAs are offering us, and how we are sponsoring micro-economies in countries based on fraudulent human form filling. Is that really the goal? Is it actually the deterrent we intended? Perhaps we should be looking at other/better options.

Well, I’ve had to sit on this info for quite some time but I’m happy to see that Phishme.com is now up and running. Phishme.com is founded by the Intrepidus Group who you may have heard of, with names like Rohyt Belani and Aaron Higbee at the corporate head. What is it? It’s education, but the kind of education that actually works for a change. If you’ve read this site long enough or heard my speeches you probably know I’m not the biggest fan of consumer education. It just isn’t impactful and it doesn’t give enough incentive for people to pay attention and learn. People don’t digest the information and they don’t become armed with the correct information on what to do when faced with an attack. That is until now.

Phishme.com uses a fake phishing attack to simulate what a user might see in a really targeted (Spear-Phishing) attack against the company. Specifically it scrapes the pages of an organization’s website and then sends everyone in the company a phish email to entice them to click on it and give up their credentials. Once the user is phished their information is logged and aggregated for future use by the security team to do further communication with the impacted employees or build further metrics, etc. Screenshot of the interface:

Click to enlarge

Does it work? Preliminary numbers in at least one exercise with 24,000 people say there is a huge drop in the numbers of users who stop clicking on links. In the first run of one experiment 82% opened the email and 64% entered info. In the second 28% opened and 27% entered info and in the third 4.5% opened and 4% entered data. That’s a pretty impressive reduction because it’s actually actionable and it gets people thinking almost immediately about the problem and that it can and will negatively affect them personally. Would you rather phish your users or have the bad guys do it for you? Ethics of owning your own employees aside, I think it’s hugely valuable to know this information.

There are all sorts of legal implications for doing this to your own staff and personally I think those issues are almost completely outweighed by the benefits of solid actionable training. When I talked with Rohyt about this, I get the feeling they’ve spent a lot of time trying to make the interface as difficult as possible to inadvertantly get compromised by trying not to actually transmit the password. So all in all, I think this product is going to do a lot of companies a lot of good. I can think of a dozen or so companies that need to go through this training right now. With phishing attacks becoming a constant and ever present attack, this is a very timely product!

I actually had to read this email several times before I got it - paranoia taking over - I thought I was being told my site was hacked. No no, just another interesting way to abuse people that people find when visiting my site. This time, this email comes from Alex who found that pre-fetching can be used to phish users in certain circumstances.

When I’m visiting http://ha.ckers.org/blog/20070608/cross-domain-basic-auth-phishing-tactics/

my Firefox showed up the HTTP-Auth dialog immediately, which I placed on my subdomain testing.bitsploit.de But why I asked myself.

I looked into your HTML source to find a hidden image or something like this, but I didn’t found anything but the link. I haven’t clicked on the link, so why does it pop up ? Than I figured out, that the FasterFox-Extension for Firefox prefetches that link and that’s why the HTTP-Auth dialog pops up.

So there’s another chance to trick FasterFox-users (in forums) without having to use HTML/BBcode for embedding images.

Alex is absolutely right. In fact, this is the exact reason I never used to use Opera (it turns out this is not the same kind of prefetching that Opera does, I only just learned). Sure you can turn it off, but pre-fetching has always been a dangerous thing to me. It can speed things up because it pre-fetches and caches the results, but if it pre-fetches and triggers something, like auto-deletion of your account, or automatically adds something to a shopping cart or anything else, you run into some pretty serious problems. Think CSRF. So yes, this apparently can also be used for phishing in FasterFox. But either way, it’s a very cool example of why pre-fetching can be nasty.

I was anonymously sent this link to an article talking about MySpace phishing attacks. The article talks about the newest phishing scam, which essentially just puts username and password fields on user’s profiles, asking for their information. Same old attack, just another day. But this is the part of the article that is actually noteworthy. The MySpace CSO, Hemanshu Nigam, suggests the following will help you from phishing attacks on their site:

But MySpace’s Nigam offers this advice to prevent phishing scams as well:

* Install the latest operating system and auto-install for critical updates.

* Use a firewall.

* Use anti-virus and anti-spyware software and keep them updated.

Does anyone else see a problem with this? Absolutely none of these will protect you from MySpace phishing attacks. So the CSO of MySpace either doesn’t understand the problem he faces, or he has no idea how to help consumers solve that problem. Either way, it’s scary. There are possible solutions to the problem in the browsers, but those are a long ways off. I’ll be talking about a number of them this week at the World OWASP/WASC conference in San Jose. In the mean-time, ignore the CSO of MySpace’s advice. His advice may help you solve other security issues, but not MySpace phishing attacks, unfortunately.

I was asked to take a look at ThreatSTOP the other day. Although it’s not very clear from the website after signing up I found out the basics. It’s essentially a lot like OpenDNS. In fact, it’s so much like OpenDNS that I actually confused id when I said what it was because he thought that’s what I was talking about. It’s not exactly like OpenDNS - there are a few differences.

First the similarities. They both rely on DNS to protect consumers (not websites) from contacting “bad” sites. They both require that you use their sites to perform the lookups on your behalf. They also share some of the same negatives - bad guys who use IP addresses are unaffected by this mitigation. It’s always reactionary - meaning it won’t block you from going there until it knows it’s bad. And if you’re paranoid, don’t forget that they both get to see every site you intend to contact.

Now for the differences. It appears that OpenDNS has quite a bit of added customization that you can put in front of it - allowing customized blocklists. OpenDNS also uses a block page, which theoretically could see the actual URLs you are going to (since it takes over the DNS for them - rather than simply blocking the request completely). Lastly, and the most import difference between the two: OpenDNS focuses on Phishing and ThreatSTOP focuses on malware infested websites.

Maybe one of the two companies should just buy the other? Not that I use this kind of stuff, but for those who do, it seems like you’d want to be protected from both threats as a consumer, not just one or the other.

In talking with the browser companies there seems to be more and more interest in content restrictions. For those of you who don’t know anything about it, let me just quickly give you the overview. Three or four years ago I was trying to find a way for my company to put malicious user generated input into a sandbox but still allow it to show up on the site. The obvious answer was use an iframe to isolate it. That, unfortunately, has all sorts of user experience issues. The first one being that you cannot tell how big it needs to be so you often end up with double scroll-bars which messes up printing, and causes links inside flash movies to only change the iframe instead of the whole page. Yah, it’s ugly. So I started looking for alternatives.

The first was talking about the concept of a re-sizable iframe. There are security implications with that cause the parent to know the state of the child, so that was thrown out by the Mozilla team. There may be tricky ways to bring that up but some of the other usability problems are still there so it’s not really ideal anyway. So the best alternative is to create something that tells the browser, “If you trust me, trust me to tell you to not trust me.” This is based off of the short lived Netscape model that said if a site is trustworthy you lower the protections of the browser as much as possible. Content restrictions was born. I submitted the concept to Rafael Ebron, who handed it off to Gerv. It went to the WHATWG, and that’s where it’s stayed for the last 3 years or so.

The Netscape model doesn’t work if the site you trust has lots of dynamic content. So by extending it with content restrictions makes a lot of sense for a few reasons. The first reason is that it puts the onus on the websites to protect themselves. The other is that it doesn’t hurt any other usability, because it’s an opt-in situation. Pretty ideal, actually. While I was talking with Mozilla last week they asked me to put together a list of the top things I’d like to see in content restrictions. They are eager to get started on it, but can’t promise the world. They’d like to hear the top two ideas and then work from there.

How you instantiate content restrictions is still up for debate - whether it be a new header pointing to an XML file, or inline in meta tags or a new HTML tag. I’m a little indifferent, except that I think it should be accessible both to people writing dynamic pages, as well as people who simply include HTML placed there by whatever means (FTP, mail, etc…). So it should probably be a hybrid of a few of those, but that’s a different discussion.

So there are two use-cases. The first is that the site wants to simply remove anything potentially malicious, which could include something like JavaScript but exclude things like objects, for instance. The other is that a site might want anything dynamic, but doesn’t want anything embedded off-host to get injected into a page, or any automatic redirection of any sort.

One thing is certain - there are many site that don’t want any content to be placed outside of the user’s content. The beauty of an iframe is that CSS only affects what’s in the iframe, JavaScript can’t overwrite things outside of it, doesn’t have access to the cookies etc. The first thing I can think of that would be highly valuable to lots of sites if they were able to create a resizeable psueo iframe to restrict the content to a portion of the page, which would include styles (absolute positioning) as well as JavaScript access to the page.

Other possibilities include not creating a new DOM (no iframes, frames, or the like on the page between two places on the page). Another is no automatic redirection that is not user initiated. That’s a common problem because malicious users perform redirection to other domains.

A possible valuable tool for content restrictions would be to be able to limit what sort of functionality is between two sets of tags. The first example would be turning off any HTML tags that aren’t allowed to be rendered. The second would be to limit the event handlers to a pre-defined set (or removing them entirely). I’ve seen a number of situations where this would have been handy as a last resort.

Another thing I have been toying with quite a bit lately is the concept of XMLHTTPRequest. One thing that has always surprised me is that it allows more than it’s name implies. That is, if you request something that isn’t XML it still gives access to the page. It could be up to the page’s digression if XHR has access to anything other than XML. That would limit XHR to session riding, rather than being able to read nonces or other unsavory functions used in worms.

So I’d like to get people’s feedback. Those are some of my ideas, but I’m hoping people will have even better ideas as well. Once I get the top two ideas, I’ll submit those, and we’ll rank order the next several ideas and submit them as supplemental ideas for a later day.

A few days ago Sylvan von Stuppe posted about a proposed change to Firefox 3.0 that changes the way the address bar works. I hadn’t heard this proposal, but it’s an interesting one. Basically they grey out the parts of the URL that aren’t the domain. Sylvan correctly pointed out that although that’s good for showing users that they are connecting to sites other than the one they meant to go to, it has nothing to do with the content on the page. XSS is still an obvious way around this, as the malicious content can be injected onto valid pages. According to Zeno MITRE is about to disclose that XSS is the attacker’s choice.

Although I should say that I do think this idea is a fairly good one, but there is at least one other problem with it. Almost all websites have IP addresses associated with them (except in the case of virtual hosts that also require a Host: header). Just because it’s an IP doesn’t mean it’s bad. I can’t tell you how annoying I think Thunderbird’s anti-phishing filter is to me always thinking every URL with an IP in it is a phishing attempt. That’s just not a good way to know if something is malicious or not. But I would like to see the consumer research that says people will actually use this and not be fooled by it. I’m always a little wary of “look for the ____” type security given how poorly the “look for the lock” security education has proven to work for SSL.

I’ve talked about this problem before - using basic authentication to phish users across domains. But it might be good to do a quick refresher for those of you who don’t know what I’m talking about. A bad guy can include a reference to an image on a domain that is protected by an Apache module, or protects itself. That then pops up a basic authentication dialog on the site that you want to phish credentials from. The only problem with this is that the basic auth dialog has the name of the URL in the title. Well Alex found a few potential workarounds to that issue:

I’ve found some nice bugs in Opera and IE (7.0), which could trick a user in thinking that he/she’s on the right server, ’cause the server’s hostname looks like what they do expect it to. Opera truncates the server’s hostname after the 34th character and adds three points “…” at the end. This could be overseen. I’ve reported that to the vendors of Opera and they don’t know a solution. Well, sounds very funny. The could display the whole string like other browsers do, but they don’t want to change their layout of the dialogue … They were not very happy with all my other suggestions I had (explicit warning message, etc.) for them. So, there will be no change in the future, I think. Due to the missing status bar (default setting) you can’t see where it probably came from => “Waiting for phishers.com …” (And if you go to enable it, there will be no output on the bar. *G*)

Don’t forget, that there’s no link you must click on. An embedded image is good enough.

(Use Opera for testing: http://testing.bitsploit.de/test.html )

The second bug, which leads to phishing is in MSIE 7. If you use IDN domain names like microsoft.de with a cyrillic, little o instead of a latin one, you won’t see the real hostname in the HTTP-Auth dialogue (www.xn--blabla.de). Only the status bar is showing the real hostname while showing the dialogue. That’s bad, but Ronald van den Heetkamp told me, that this shouldn’t be a big problem. (Don’t know how, ’cause IE7 ignores something like status=no and e.g. Firefox gives no access to rewrite the status bar string as a default setting.)

I’ve informed MS, but they didn’t respond so far.

The IDN thing is interesting because I’m sure if you were in the field a few years back this will sound familiar - people setting up fake websites that looked in every way like the target website, except one letter would be Cyrillic. That mostly affected Firefox, and Netscape (because it used the Gecko rendering engine), but now it looks as if IE might also run into problems. Not that I think a ton of people fall for this sort of thing, but even if it’s only vaguely useful, it’s still something we should consider as a workable attack vector.

After reading a comment by David Ulevitch on a post by Dragos Lungu I was pretty interested in reading a new press release from OpenDNS on how they are “partnering” with the anti phishing work group (APWG). I actually laughed when I read it for a few reasons. Firstly, if you read Dave Jevans’ comment he says, “We are pleased to welcome PhishTank.com as a member of the APWG.” To me that seems less like a partner and more like a client. I couldn’t find any supporting words on APWG’s website at all to confirm a partnership in any capacity. To me it sounds like OpenDNS is simply going to consume data from APWG.

Secondly, this affirms what I was trying to get across in my comments on my post about the phishtank’s competitive nature with APWG. Although David Ulevitch never answered my questions posed to him in the comments, this pretty much sums up what I was saying. Unless these players start working together, they are only causing more churn in the industry as more companies have to deal with more anti-phishing aggregators. That in turn means that companies trying to protect themselves or their consumers have to build more APIs, sign more contracts or whatever, just to get the global knowledge of where phishing sites are. So, ultimately this sounds like a good thing, although I’m skeptical of how much a partnership this really is, given Dave Jevans’ comments. It sounds more like they are just a simple consumer/submitter, just like the other APWG members, but the press release may also just be poorly written.