Financial Cryptography

MITB defences of dual channel -- the end of a good run?

Back in 2006 Philipp Gühring penned the story of what had been discovered in European banks, in what has now become a landmark paper in banking security:

A new threat is emerging that attacks browsers by means of trojan horses. The new breed of new trojan horses can modify the transactions on-the-fly, as they are formed in in browsers, and still display the user's intended transaction to her. Structurally they are a man-in-the-middle attack between the the user and the security mechanisms of the browser. Distinct from Phishing attacks which rely upon similar but fraudulent websites, these new attacks cannot be detected by the user at all, as they are use real services, the user is correctly logged-in as normal, and there is no difference to be seen.

This was quite scary. The European banks had successfully migrated their user bases across to the online platform and were well on the way to reducing branch numbers. Fantastic cost reductions... But:

The WYSIWYG concept of the browser is successfully broken. No advanced authentication method (PIN, TAN, iTAN, Client certificates, Secure-ID, SmartCards, Class3 Readers, OTP, ...) can defend against these attacks, because the attacks are working on the transaction level, not on the authentication level. PKI and other security measures are simply bypassed, and are therefore rendered obsolete.

If they saw any reduction in use of web banking, and the load shift back to branch, they were in a world of pain --- capacity had shrunk.

The conclusion that the European banks came to, once they'd got over their initial fears, was that phones could be used to do SMS transaction authorisations. This system was rolled out over the next couple of years, and it more or less took the edge off the MITB.

Now comes news NSS Labs' Ken Baylor that the malware authors have developed two channel attacks:

On the positive side, there has been little innovation in the functionality of mobile financial malware in the last 24 months, and the iOS platform appears secure; however, further analysis reveals that there are now multiple mobile malware suites capable of defeating bank multifactor authentication. With 99 percent of new mobile malware targeting Android, attacks on this platform are unprecedented both in their number and their impact. The lack of iOS malware is likely related to the low availability of iOS malware developers in the ex-Soviet Republic.

While banks remain slow to evolve their mobile security strategies, they will find the cyber criminals are several steps ahead of them.

Malware now tries to mount an attack on both channels. This occurs thus-ways:

Zeus and other MITB trojans have used social engineering to bypass this process. When a user on an infected PC authenticates to a banking site using SMS authentication, the user is greeted by a webinject, similar to Figure 1. The webinject requires the installation of new software on the user’s mobile device; this software is in fact malware.

ZitMo malware intercepts SMS TANs from the bank. Once greeted by the webinject on a Zeus-infected PC, the user enrolls by entering a phone number. A “security update” link is sent to the phone, and ZitMo installs when the link is clicked. Any bank SMS messages are redirected to a cyber criminal’s phone (all other SMS messages will be delivered as normal).

We knew at the time that this could occur, but it seemed unlikely. (I say 'we' to mean that I was mostly an observer; at the time I was in Vienna and was at the periphery of some of these groups. However, my lack of German made any contributions rather erratic.)

Unlikely because on the first hand it seemed an inordinate amount of complexity, and on the other, there wasn't enough of a target. What changed? The market has shifted hugely over to mobile use as opposed to web use. The Americans have been a bit slower, but now their on a roll:

According to the Pew Research Center,1 mobile banking usage has jumped from 24 percent of the US adult population in April 2012 to 35 percent in May 2013. Banks have encouraged this move toward mobile banking. Most banks began offering mobile services with a simple redirect to a mobile site (with limited functionality) upon detection of smartphone HTTP headers; others created mobile apps with HTML wrappers for a better user experience and more functionality. As yet, only a few have built secure native apps for each platform.

Many banks believe that mobile devices are a secure secondary method of authentication. To authenticate the widest number of people who have phones (rather than just smartphones), many built their second factor authentication solutions on one of the most widely available (although insecure) protocols: short message services (SMS). As banks believed an SMS-authenticated customer was more secure than a PC-based user, they enabled the former to carry out riskier transactions. Realizing the rewards awaiting those able to circumvent SMS authentication, criminals quickly developed mobile malware.

So the convenient second channel of the phone has actually switched places: it's the primary channel, it's life, and the laptop is relegated to the at-office, at-home work slave. The model has been turned upside down, and in the things that fell out of the pockets, the security also took a tumble.

Closing with Ken Baylor's recommendations:

NSS Labs Recommendations

• Understand and account for current mobile malware strategies when developing mobile banking apps.
• Do not rely on SMS-based authentication; it has been thoroughly compromised.
• Retire HTML wrapper mobile banking apps and replace them with secure native mobile apps where feasible. These apps should include a combination of hardened browsers, certificate-based identification, unique install keys, in-app encryption, geolocation, and device fingerprinting.

Hey! I guess that's the business I'm in now. We've successfully ported the 'mature' Ricardo platform to Android: No flaky browsers in sight, and our auth strategy is a real strategy, not that old certificate-based snake-oil. Obviously, public keys and in-app encryption.

Geolocation and device fingerprinting I am yet to add. But that's easy enough later on. I guess I should post on all this some time, if anyone is interested...

Posted by iang at December 24, 2013 03:40 AM | TrackBack