igb’s posthaven

I'm very sceptical about this claim.  OK, we have recently had a case in which a major browser had a flaw which permitted the use of fake certificates, but only under specific circumstances and there's no suggestion I've seen that it had been exploited on a long-term or wide-spread basis.  And there is a roughly plausible mechanism that can be used:

* Hi-jack insecure connections to Google

* Look for searches for BankCo UK Banking

* Inject a fake URL pointing to https://BankC0.co.uk 

* Look for DNS lookups for BankC0.co.uk, and return IP number of attacker's system

* Present a certificate for BankC0.co.uk, rather than BankCo.co.uk.

Alternatively, you can hijack requests destined for http://BankCo.co.uk and redirect them to https://BankC0.co.uk, possibly with the help

of fiddling with Google.

This attack would work even in the face of certificate pinning and, arguably, certificate transparency.  Transparency would allow BankCo to patrol the logs looking for "similar" names being issued, but if the claim is users don't check URLs then the attacker could pass back an arbitrary string as the URL and hope the victim doesn't notice.  

But is this actually happening?  Yes, in principle we should worry about capability and potential rather than execution, but looking at the attacks that are actually "in the wild" helps us prioritise.  Wikipedia's entry for "Evil Twin" networks is old and has very little hard information about actual exploitation.  The pages that come up towards the top of the Google search are getting on for ten years old.  The line between the good guys and the bad guys is blurred and the tools used by the bad guys rarely remain secret for long; it defies belief that "Evil Twin" attacks could have been happening for ten years and yet no example of code or hardware has emerged.

So why do I think the risk is overstated?

Firstly, the attack is quite narrow.  If you have a bookmark for your online banking, it doesn't work.  If your web browser's search bar uses https to access Google, as is increasingly common, it's narrower still (you'd have to hope that users bookmarked the http:// version on their banks website, and use a redirect).  Alternatively, you'd have to hope that people override the many warnings of fake certificates while no-one in the location complains to the owners.  

Secondly, the attack doesn't yield money.   Unlike skimming PINs and card details, which you can monetise immediately, all you get from this attack is a set of login credentials.  If the bank uses one of those funky card machines or some other second factor, then you will not be able to login afterwards.  If the bank uses "select letters 2 and 5" type authentication you might be able to guess, but even the banks that do that require a phone call in order to set up a new payment.  And even if you intend to make transactions within the login session the user has established, rather than afterwards, you will again hit the problem that setting up a new recipient requires out-of-band authentication.  There is far more advantage in having credit card number, CV2 and address than in having online banking details, and far easier ways to obtain them.

Thirdly, the attack leaves virtual fingerprints everywhere.  Ross Anderson has written that the massive step forward in credit card fraud was the realisation by attackers that if they didn't put through the transaction that was hijacked by the skimmer, the banks couldn't cross-match accounts that had been the victim of fraud in order to find out where it had happened.  But here, the attacker doesn't control other payments, so if the victim has paid by debit card (it's a reasonable bet in Starbucks, a near-certainly in hotels) there will be common transactions between victims.  The attacker is probably able to avoid just using a single IP number for the transactions, but given the detail of the logs that are kept it's likely that there will be timing or format similarities between attacked sessions that allow the man-in-the-middle to be retrospectively identified.  And, of course, because there is no way to obtain cash from this attack, you have the problem of money laundering: you have to have a destination where you can transfer the money to, where you can subsequently draw it out, without getting caught.    Even if you manage this, the account(s) will be again an obvious common factor between the victims.

Fourthly, the attack leaves actual fingerprints.  You're going to have to carry the equipment into the building, or nearby.  The equipment has a history.  If you abandon the equipment, it will be found, and the police will have your software to analyse and the hardware to match for fingerprints and DNA.  If you stay near the equipment, you risk observation by CCTV.  There's a reason why ATM skimming is done in petrol station forecourts and out of the way street corners, and that is for an attack which can immediately be converted into cash, rather than requiring laundering.

And finally, the bandwidth of the attack is very low.  You might be able to obtain login details for bank accounts, but the subset of those where you can set up a payment to a new destination will be vanishingly small.  What can you do with access to a bank account where you can't transfer money?

If you were going to conduct these sorts of attacks on on-line banking, you would do so at far lower risk by malware infection, installing keyloggers on victim machines.  There's little evidence that in the UK at least, key loggers are today a significant risk for online banking either; the phone call to setup new recipients is the key defence.  If you want GMail account details (or similar) then Malware is an infinitely more effective attack, and that clearly is circulating in the wild.  And if you want to steal money and goods, credit card details are the best thing to have, which again doesn't require an elaborate attack on WiFi.

So I think this is another of the cyber-crime industry's bogie-men: an attack which is theoretically possible, but only actually works against a tiny, possibly null, subset of potential victims, at high risk and expense to the attacker.

ian