December 08, 2011

Two-channel breached: a milestone in threat evaluation, and a floor on monetary value

Readers will know we first published the account on "Man in the Browser by Philipp Güring way back when, and followed it up with news that the way forward was dual channel transaction signing. In short, this meant the bank sending an SMS to your handy mobile cell phone with the transaction details, and a check code to enter if you wanted the transaction to go through.

On the face of it, pretty secure. But at the back of our minds, we knew that this was just an increase in difficulty: a crook could seek to control both channels. And so it comes to pass:

In the days leading up to the fraud being committed, [Craig] had received two strange phone calls. One came through to his office two-to-three days earlier, claiming to be a representative of the Australian Tax Office, asking if he worked at the company. Another went through to his home number when he was at work. The caller claimed to be a client seeking his mobile phone number for an urgent job; his daughter gave out the number without hesitation.

The fraudsters used this information to make a call to Craig’s mobile phone provider, Vodafone Australia, asking for his phone number to be “ported” to a new device.

As the port request was processed, the criminals sent an SMS to Craig purporting to be from Vodafone. The message said that Vodafone was experiencing network difficulties and that he would likely experience problems with reception for the next 24 hours. This bought the criminals time to commit the fraud.

The unintended consequence of the phone being used for transaction signing is that the phone is now worth maybe as much as the fraud you can pull off. Assuming the crooks have already cracked the password for the bank account (something probably picked up on a market for pennies), the crooks are now ready to spend substantial amounts of time to crack the phone. In this case:

Within 30 minutes of the port being completed, and with a verification code in hand, the attackers were spending the $45,000 at an electronics retailer.

Thankfully, the abnormally large transaction raised a red flag within the fraud unit of the Commonwealth Bank before any more damage could be done. The team tried – unsuccessfully – to call Craig on his mobile. After several attempts to contact him, Craig’s bank account was frozen. The fraud unit eventually reached him on a landline.

So what happens now that the crooks walked with $45k of juicy electronics (probably convertible to cash at 50-70% off face over ebay) ?

As is standard practice for online banking fraud in Australia, the Commonwealth Bank has absorbed the hit for its customer and put $45,000 back into Craig's account.

A NSW Police detective contacted Craig on September 15 to ensure the bank had followed through with its promise to reinstate the $45,000. With this condition satisfied, the case was suspended on September 29 pending the bank asking the police to proceed with the matter any further.

One local police investigator told SC that in his long career, a bank has only asked for a suspended online fraud case to be investigated once. The vast majority of cases remain suspended. Further, SC Magazine was told that the police would, in any case, have to weigh up whether it has the adequate resources to investigate frauds involving such small amounts of money.

No attempt was made at a local police level to escalate the Craig matter to the NSW Police Fraud and Cybercrime squad, for the same reasons.

In a paper I wrote in 2008, I stated for some value below X, police wouldn't lift a finger. The Prosecutor has too much important work to do! What we have here is a very definate floor beyond which Internet systems which transmit and protect value are unable to rely on external resources such as the law . Reading more:

But the Commonwealth Bank claims it has forwarded evidence to the NSW and Federal Police forces that could have been used to prosecute the offenders.

The bank’s fraud squad – which had identified the suspect transactions within minutes of the fraud being committed - was able to track down where the criminals spent the stolen money.

A spokesman for the bank said it “dealt with both Federal and State (NSW) Police regarding the incident” and that “both authorities were advised on the availability of CCTV footage” of the offenders spending their ill-gotten gains.

“The Bank was advised by one of the authorities that the offender had left the country – reducing the likelihood of further action by that authority,” the spokesperson said.

This number goes up dramatically once we cross a border. In that paper I suggested 25k, here we have a reported number of $45k.

Why is that important? Because, some systems have implicit guarantees that go like "we do blah and blah and blah, and then you go to the police and all your problems are solved!" Sorry, not if it is too small, where small is surprisingly large. Any such system that handwaves you to the police without clearly indicating the floor of interest ... is probably worthless.

So when would you trust a system that backstopped to the police? I'll stick my neck out and say, if it is beyond your borders, and you're risking >> $100k, then you might get some help. Otherwise, don't bet your money on it.

Posted by iang at December 8, 2011 04:34 PM | TrackBack

I wonder --- couldn't, shouldn't, the bank sue Vodafone? After all, their lax security cost the bank 45k.

Posted by: Hasan at December 8, 2011 03:34 PM

@ Hasan,

"I wonder --- couldn't, shouldn't, the bank sue Vodafone? After all, their lax security cost the bank 45k"

Err not realy.

Look at it this way Vodafone's security is about the costs incured for using the phone as a phone not as a security token.

Thus from Vodafone's point of view if their security lapse caused a large phone bill to be run up then they would be liable for the cost of those calls ONLY...

This mismatch of security drivers was something I missed back in the late 1990's when I proposed a method of doing two channel transaction (not communication path or entities) authentication.

Without going into all the details I've been warning against the use of mobile phones for two factor and side channel authentication for some time now, and certainly since the birth of smart phones.

If you think about it a lot of people do online banking on a smart phone (very very stupid see CarrierIQ debacle for just the latest reason) and the chances are that they also use the same smart phone for their "second channel". Which means it's not a second channel at all...

There is also the problem that many smart phone browsers leak information about the phone ID. quite deliberatly. And this ID can be fairly easily used to find out the phone number and other details.

The problem is that for a transaction to be secure it must be two way authentication on each and every transaction, and the authentication must be done not only through a secondary secure channel but also include the human into the security chain otherwise an attacker can do an "end run" around the security.

This requires the user to have a token into which they enter the transaction details it produces a secure messsage the user types in at the computer keyboard, the user then enters the response they see on the computer screen sent back by the bank into the token and then type in a second secure message from the token into the computer and send it back to the bank as a secure confirmation. Not only is it labourious process for the user, it's expensive for the bank to make such tokens. Oh and users have a habit of leaving the token at home when they need to use it at work or on a trip etc or worse doing the opposit...

Posted by: Clive Robinson at December 10, 2011 07:53 AM

@ Iang,

Maybe it's time for you to do an analysis of what is actually required to do banking and other monetary transactions in something aproaching a "secure manner".

Posted by: Clive Robinson at December 10, 2011 07:56 AM

Ha! Well I did that, I built a secure payments system back in the old days called Ricardo (see next post). It didn't have any of the discussed two factor or two channel things in it, only because it was well above the security required at the time. Partly this was because of a very small user community, also partly because it had strong back-end traceability that is easier in a 3 party payments model. Banking payment systems being a 4 party model, it requires inordinate degrees of discussion to get a one byte change in place... there being no surprise that they are problematic and holey from a security pov.

E.g., part of your question there is "who for?" If you talk about a bank, it would be "which one" and "which products." A security analysis is very personal, very particular.

Which leads into the whole "core business" question: a security analysis for a bank, which is about risk & security, shouldn't really be outsourced. Otherwise, you're outsourcing your soul...

Posted by: Iang at December 11, 2011 07:14 AM


Well the big problem I saw with phishing an MITM is the multiplication value by doing it large-scale for free. You can send out millions of phishing emails without much effort, and collect lots of money from lots of MITM´ed computers.
Now with this attack, you have to do phone-calls to the telcom providers. You can´t do millions of phone-calls to take over millions of mobile phones. So even if it is attackable, we are still back to a normal fraud scenario, and the barrier has been raised considerably. You have to attack both the PC with an MITM, take over the smartphone.
And I heard of telecom provider already increasing their security, by asking for things like the PUK when you want to transfer your number to a new SIM-card.
By the way, I heard about the same attack a few years ago from Turkey, so this is not new, and it has not become mainstream in the past few years.

So if you are paranoid about your money, ask your mobile phone operator how they verify your identity if someone else wants to transfer your phone number.

Posted by: Philipp Gühring at December 11, 2011 09:42 AM
Post a comment

Remember personal info?

Hit preview to see your comment as it would be displayed.