economics of 2 factor man-in-the-middle phishing

by now i would hope that most people reading this blog are aware that 2 factor authentication doesn't protect against phishing...

over on the symantec security response weblog, zulfikar ramzan concedes very much the same thing, that man-in-the-middle phishing can compromise even 2 factor authentication schemes, but puts it into a broader context and states that the 2 factor authentication still changes the economics of the attack and effectively makes it less profitable...

you see, the world of cybercrime is one where information is frequently bought and sold and the one-time passcodes generated by security tokens used in 2 factor authentication schemes are supposed to prevent your credentials from being traded like a black-market commodity... as such, the theory goes that the phishers, rather than having a salable good that they can pawn off on someone prepared to actually use the information, are only able to access the compromised account login sessions directly and so have to be prepared to get their money from the victims directly... this is a riskier proposition and therefore seemingly less valuable to the phishers...

although it may seem like the credentials the phisher captures are useless for resale, i'm not entirely convinced they are - credential re-use being what it is and with the heightened sense of security that the tokens offer, i'm sure those usernames and passwords will often be useful on sites other than the ones using the 2 factor authentication systems... moreover, i'm not convinced that the economics of the attack are changed as much as one might think, or that there isn't a comparable salable good to be offered here... if pornographers can monetize live video feeds of young women in various states of undress then i don't see why phishers can't sell real-time access to the login sessions they've compromised, perhaps even by setting up their customers as mirrors for the phishing page(s) and using load balancing to direct the appropriate proportion of phishing page requests to those customers' mirrors depending on how much the customer paid (and those customers could in turn resell the sessions in exactly the same way their provider sells them)...

2 factor authentication certainly changes the phishing landscape, but to say that it will reduce profitability assumes the bad guys can't innovate (which is a pretty bad assumption to make)... one simply has to imagine new ways to do things, and criminals are already familiar with imagining new ways to make money...

security tokens don't protect against phishing

you never know when you're going to come across a train of thought so thoroughly wrong it deserves to be debunked... that's what i learned today (hey, i haven't gone to sleep yet, it's still officially today) when i read david maynor's blog entry where he mentions thinking that with a paypal security token he won't have to worry about where he enters his paypal credentials anymore...

gold star if you're shaking your head just thinking about that... security tokens, generally part of a 2 factor authentication system (where you prove who you are using something you know, like a password, and something you have, like a token), won't protect you against phishing - at least not completely... the simplistic phishing attempts that we're familiar with right now would be thwarted by 2 factor authentication but not only can the practice of phishing adapt to 2 factor authentication it's already started to do so...

phishing schemes using man-in-the-middle attacks have already been spotted in the wild and some specifically support 2 factor authentication...

the reason phishing is possible is the same reason man-in-the-middle attacks are possible - one end of the communication (in this case the phish site) hasn't been authenticated... you can strengthen your own authentication until you're blue in the face - even 3 factor authentication won't help you if you don't know for sure that the person you're talking to really is who they claim to be...

site authentication is a hard problem, though, a lot harder than people give it credit for... as i've said before, site authentication schemes that work by placing something on an authentic site to prove it's authentic won't work very well because we just aren't all that good at noticing when something is missing (which it theoretically would be for a fake site)... i also don't understand what's so special about things like site authentication images that prevents them from being spoofed by a man-in-the-middle attack as well - the attacker's system should be able to pull the proper image from the real site so long as it sends the same identifying information to it that the client normally would have...

sender authentication isn't quite as hard a problem, though... perhaps david should read my post about avoiding phishing emails the easy way so that he can harden up that soft spot he has for paypal phish...

what is a man-in-the-middle attack?

a man-in-the-middle attack is a type of attack where the attacker tricks both sides of a 2-way interaction into believing s/he is the other entity in the transaction...

for example in a man-in-the-middle attack, you might think you're talking to your friend bob when in fact you're talking to mallory who then passes on what you say to bob... bob in turn thinks he's talking to you but in fact is also talking to mallory who then passes on what bob says to you... mallory gets to see both sides of the conversation and even has the opportunity to subtly change it for some nefarious purpose, perhaps to make bob mad at you or something...

there are all kinds of contexts where man-in-the-middle attacks can be useful to an attacker - in simple terms they allow an attacker to gather data sent over what was believed to be a secure channel, whether that data is login credentials for a bank or encrypted web traffic sent to a secure site, and possibly even inject their own messages (such as a financial transaction) into the communications... the channel may even be secure in and of itself, but the problem is that the party at the other end isn't who they claim to be... securing the channel over which communication occurs doesn't secure the communication unless you also authenticate (make sure they are who they say they are) the parties at both ends of the channel...