I was having our weekly cigar meeting with the local security guys when we stumbled across a pretty funny thought. There’s a pretty good paper put out by Cybersource about trends for 2008 in which it had a graph showing that as a percentage of online transactions fraud was dropping. Whoah! That’s not what I expected to hear. But then in closer examination that’s a red herring, because total fraud is still increasing at the same rate it always has. Not so good after-all, it just means consumer spending is out pacing the bad guys. That makes it worth being in the business of online retailing, but spending will eventually taper off with population growth.

The funny part of the story is what if all the consumers finally hit a tipping point where they just decided to go home and stop using the Internet completely? What if we just had bad guys trying to phish bad guys, and spammers just trying to spam other spammers? What would the Internet be when every page was a scam and every person on it was desperate for money because all the people who they wanted to scam went outside to go play in the grass? A funny thought! Hey, we were having cigars, sue us for getting a little off topic!

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!

Whelp, we’ve talked about it, but now it’s finally possible. CSRF can now cause jail time. The FBI has begun arresting people who click on links to supposed child pornography. Now, I understand the noble pursuit, but there’s a fairly huge flaw in the old logic. I can force users to click on links anytime I want. Now here comes some interesting CSRF technology grey area. The authorities might reasonably say, “The referrer doesn’t match.” Okay, well that’s what our good friend META refresh is for. I can force you to click on things without leaving a referring URL at all.

So now the real question is would a user with no referring URL be worthy of investigation? Is this the newest wave in reasons to turn off referring URLs? I mean, seriously, what if the browser pre-fetches, or if an attacker puts a hovering iframe beneath the mouse, or they are using an older browser/plugin that allows spoofed referring URLs. Eesh. Again, I’m all for the noble pursuit, but seriously - this seems a little dangerous to me. Is clicking a link evidence enough of guilt? If so, can I now take search engines to court for trying SQL injection against me or for spidering and caching illicit content? And now have we given people plausible deniability, “I knew it was fake before I clicked on it” or “I was just seeing if it was an FBI site or not” etc….

<sarcasm> Be the first kid on the block to surprise your friend with an illegal version of a Rick-roll. </sarcasm> The act of clicking a link as evidence of guilt is almost certainly asking for trouble and abuse.

Sample code on how easy it is to not send a referring URL: <META HTTP-EQUIV="refresh" CONTENT="0;url=http://child-porn-site">

If you haven’t been to RSACon and are into the whole schmoozing aspect of the security industry, you need to book your flight right now. RSACon is basically a bazaar of vendors from all over the world, promoting their tools. There’s no substitute for it. I wouldn’t expect to go to it and learn anything from the talks, but it is cool walking around talking to the vendors, seeing the new terminology that they’ll be stuck with for the next 12 months, and getting the pitches. I personally love that con for the sellout aspect if nothing else. But wait, that’s not all…

For the last few years Jeremiah has been putting on the RSACon WASC meetup. It’s just a few hours for everyone to get together who’s interested in webappsec. The first year it was just a few of us. The next year it was around 100 people. It’s no doubt going to be even bigger. It just shows how big this industry is getting! So if you are interested, check out the details on Jer’s blog. If you happen to be in town, even if you’re not coming to the conference please drop by. I’m always up to meet webappsec people!

I got this picture from a reader of the site. Apparently the reader was simply viewing Yahoo mail and poof, RogueIframe trojan. We are starting to see a lot more of this kind of stuff, but it’s really disappointing that third party ads are being displayed on otherwise sensitive apps (or at least I think most people feel they are sensitive). Here’s the picture:

Click to enlarge

We’ve seen this exact hack hit before, against Facebook. But I think this kind of thing may be the beginning of a epidemic. As long as you can end up with your advertisements on any site that is even vaguely sensitive, you can start either taking over the site, or delivering malware. Whatever best suits the attacker’s needs. I think this all goes back Tom Stripling’s speech at OWASP where he in painstaking detail explained why you cannot trust third party JavaScript on your site, and yes, that definitely includes advertisements. Anyway, I hope this gets cleaned up quickly.

Whelp, I just concluded my rather long trip to Boston for the first annual SourceBoston conference. I actually had a great time. There were a few bugs in the conference here and there, but that’s not unexpected for any first-time conference (totally forgivable). I expect it to grow quite a bit in the future to given the quality talks I heard there. The talks were almost without exception technical or business oriented enough that I had a difficult time picking and choosing which ones I wanted to go to. So much so that this was the very first time I’ve ended up buying a talk after the conference was over. I’m glad I did too. The telephone defenses talk by James Atkinson was excellent - long (2.25 hours) but excellent.

The keynotes were all great, but the one that really stood out in my mind was the talk by Dan Geer. It was a fast speech with a lot of specifics about the correlation between genetics/biology and viral/worm propagation. Later that evening a bunch of the more technical/business people were asked to go to a dinner with Polaris Ventures. There I got a chance to speak with Dan a little more and gently chastised him for not mentioning Samy, which I think intrigued him.

After the dinner, I began thinking about one concept that was mentioned during Dan’s talk and was echoed a number of times during the dinner and then again the next day. The concept was around the fact that in some networks we are seeing a change between parasitic malicious software to symbiotic malicious software. That is, some of the best maintained machines are run by attackers. They are up to date, patched, the logs aren’t writing off the end of the disc, etc… Because bad guys take a great deal of pride and care in their machines, trying to keep other hackers off the boxes. They end up doing quite a bit of defense to insure they have the ability to maintain and control the box.

Okay, here’s where it gets really weird. Now let’s take that to it’s next logical bizarre conclusion - often machines are healthier with an attacker on it than without. In fact, bad guys really do their best to make sure they aren’t saturating the connection or making the machine too slow. It’s in their best interest to have their control over the machine persist. It’s a strange malicious harmony, where the host is fed and nourished by the aggressor organism. But that only really makes sense when an attacker has access to the system and can control the inner workings of the computer itself. Are there any parallels between this and web application security?

I’ve thought about this quite a bit over the last few days and I can’t come up with a single real world instance of where a malicious attack that doesn’t involve some level of OS compromise has been healthy for the host system in any way. Once you begin talking about remote file includes and command injection it’s the same thing as a typical worm or virus scenario, where the attacker may take a great deal of time and energy to protect the system, leaving only small back doors for themselves to recover control at will. But all the compromises that don’t allow for any form of system/OS level control have only damaging effects. XSS worms, CSRF, SQL injection, etc… None of which have any positive effects on the host system.

But each of those classes of vulnerabilities also share one other thing - with the exception of persistent XSS/HTML injection or changes to the database they each have very little longevity compared to OS compromises. Adding an account in a database clearly can persist indefinitely, but more often than not a bad guy is less interested in adding to a database than they are extracting information out of it, meaning the longevity is an afterthought. Persistent XSS that performs overtly malicious actions is typically uncovered quickly because of the real-time effects it typically has against the normal user base.

With that in mind, it would appear to be that the less persistent the attack the worse it is for the host system in terms of any tangible side benefits the attacker can bring to the table. There is little to no symbiosis in these forms of web application attacks. Now clearly you’d say it’s better to have an XSS attack than a computer compromise, and I’m not naive enough to think bad guys really care about the system. Rather their interests lie in maintaining control over their assets, which is an issue of economic loss aversion. But I definitely think there is some interesting side effects of malicious attacks here that are worth thinking through a little more.

Further, one rather interesting argument I’ve heard for protecting machines is for increased OS longevity, which costs enterprises less because of productivity loss when machine re-installs are required. This really is more of a problem when rampant spyware begins to slow down a machine to where it becomes almost unusable, or even unstable because of the poor quality of the spyware code requiring the owner to complain to their IT department. In that case it’s parasitic software. So perhaps what we are really interested in is stopping parasitic software and encouraging symbiotic software to lower IT costs. As long as the machine contains nothing sensitive it would end up driving down support costs, if there were no other negative effects, like having your IP space black holed for sending out too much spam. It sounds crazy, I know.

Jeremiah and I were talking about this with Dan from Polaris yesterday though. If you could somehow get someone to use XSS as a way to do compute type for processor intensive operations you could potentially sell that to people who have high levels of computational needs. I like that idea less than offering a free download to users for the processor or slice of bandwidth when not in use (symbiotic), in trade for hardening the machine against purely malicious (parasitic) attackers. We’ve seen things like this in the past, SETI at home, and the RC5 distributed cracking… but I consider both of those to be parasitic, offering little to nothing to the host machine. Interesting thought, anyway…

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!

While looking back at some of my old speeches, and after writing the last blog post it occurred to me there is another attack I haven’t heard anyone talk about. Often times spammers will use contact member forms for spamming purposes. But most contact forms can’t spoof the contact name so this form of spamming is pretty limited. However, let’s consider another common scenario, which is that a user is allowed to change their email address. Almost never is there an email address confirmation link sent to make sure you are indeed the owner of the email address. So let’s take an actual example.

Let’s say Cathy wants to spam Alice, but Alice isn’t a member of the message board. Cathy signs up with two accounts, one to send messages from and one to receive them. Cathy logs in as the second user account and changes her email address to Alice’s. She then logs into the first user account and send the spam, which then gets routed to Alice. Then Cathy logs in to her second account, switches it to the next spam victim, logs back into her first account and sends a second spam and so on.

The limitations here are that the email must actually contain the spam message to work, so if it’s just a link back to the platform, that won’t suffice since Alice isn’t a legitimate user of the system, let alone has access to Cathy’s account. The second problem is that the email probably contains some site specific information which can easily identify the spam as such. And thirdly, many sites send an email change notification to alert users that their email has been changed, so when Cathy switches her address over and over, she will also inadvertantly be sending emails to her victims telling them that she’s switching accounts.

But in this way I believe many existing member to member communication functions can be used as spam gateways. Weird, huh?

Okay, I had more trouble naming this post than I did writing it so bear with the title, because I think this is actually a pretty interesting problem. I went out for cigars with a few uber old school hackers from a huge company last night and we got to talking about databases. I’m not exactly sure what lead my brain down the path, but I suddenly realized there’s actually some fairly tricky issues around data deletion/retention that can lead to sensitive information disclosure. Here’s how it works. Let’s say you have three people, Alice, Bob and Cathy. Alice and Bob are both good users of a web site message board. Maybe they have special privileges, or maybe they are just communicating privately and Cathy wants that information.

In a secure database setup, if a user is deleted from a system no other user can take over their information after they are gone from the system. It’s not deleted (for data integrity/forensics, etc…) but it should be inaccessible to users. However, it turns out that not all database structures are made equal. Sometimes people use usernames as primary keys, or hashes of usernames, etc… instead of a non-reputable number. So let’s say Alice had her account deleted (intentionally or accidentally) there is an opportunity for Cathy to create a user account with the same name as Alice’s username and suddenly gain access to the same information that was supposed to be accessible only to Alice.

Let’s take this further and bring back an old favorite and normally not all that interesting attack - DoS by CSRF - that is forcing a user to click on a “delete my account” link. Typically DoS isn’t all that interesting to me, but here’s where you can actually use it to take over the account. This all relies on knowing the username of the person you are attempting to compromise. So let’s say Cathy creates an account on the message board. On a forum she places an image link to http://www.evil.com/x.php?.jpg which looks at the referring URL before making the decision on whether to show a benign image, or redirect the user’s browser via 301 or 302 redirect to the delete user function (eg: http://www.good.com/deluser.php). If the referring URL contains the username “Alice” the Alice user’s browser automatically is redirected and the account is deleted.

At this point Alice is probably almost immediately aware that her account has been deleted, so it is time critical that Cathy immediately registers with the same name “Alice”. Assuming the database uses the registered user as the primary key (or some derivation of the user name) it is possible for Cathy to now assume control over Alice’s account. Now she can read Alice’s private communication with Bob, or if Alice had some administrative controls, it might be possible for her to do other nefarious things, like promote other user’s access, etc…

There is an alternative to trying to detect Alice’s name in a referring URL. One example is if images can be sent within private messages or other out of band communications, assuming Alice is already logged in it will have the same net effect of targeting the individual user. It’s also fairly easy to detect this in a blackbox situation simply by creating an account, using all the functions, deleting it and re-creating the same name to see if any data was retained during the creation of the account. The point being, it’s bad form to use a username as a primary key unless it’s forever off limits for future users attempting to re-assume that username. Kind of an esoteric problem, but as I talked with the gurus, at least one of them had actually seen this happen in his own penetration tests against some very large well known companies. So there you have it, it’s not even just a theoretical attack. Yet another thing to look out for and at least one good reason to protect account deletion functions from CSRF.