Malware that Foils Two-Factor Authentication
This is an interesting article about a new breed of malware that also hijack’s the victim’s phone text messaging system, to intercept one-time passwords sent via that channel.
Comments
Lorenz Diener • June 28, 2013 6:16 AM
That’s why I like the little too-dumb-to-run-malware hardware keyboard/display I have from my bank – just going from one untrusted device to two untrusted devices makes things harder, but not hard enough. The only things that still work with the dumb hardware dongle are things like “tell the user on the website you are running a ‘test of the system’ and please enter the TAN here”, which really is probably impossible to avoid.
Robert • June 28, 2013 7:02 AM
I find it weird that I haven’t heard about any malware that would install a legit email-me-my-texts (or some kind of unified messenger that notifies the user about texts) app from Google Play using Play’s web interface and mess with user’s gmail inbox enough to hide these messages from him.
This is the very reason why I’m contemplating having a second phone, as simple as possible, to be used only to receive one time passwords from the bank.
@Lorenz Diener: and these attacks do not work against password-in-the-text-message systems: you can have a text with the password and details of the action the password is supposed to confirm.
Nick P • June 28, 2013 7:30 AM
@ Robert
“This is the very reason why I’m contemplating having a second phone, as simple as possible, to be used only to receive one time passwords from the bank.”
It would be better to have a device, simple as possible and robust bottom up, to do that and much more. I’d like one for bank transaction authentication, password management, TRNG, trust anchor for other devices, attestation, etc. Any signed, managed app or function that could be loaded on it. Wired or wireless hardware whose functions were partitioned away from main code.
Closest thing to it is the “transaction appliance” I designed and eventually posted on this blog.
http://www.schneier.com/blog/archives/2011/06/court_ruling_on.html#c552667
It has been implemented as a prototype. It can be used for all sorts of things where something must be authorized/authenticated/checked and you want the user to see the data itself first. COTS hardware. It was also designed to meet the requirements of EAL5-7 in certain configurations if anyone ever wanted to take it that far.
Recently, I’ve been looking a lot into language based security, capabilities and type-safe OS’s. There’s been previous working products that used these approaches for security. My favorite modern effort so far has been JX Operating System. These kinds of things have the advantage that you’re mainly just coding your app functionality without worrying much about the OS or various memory attacks. Lets one create many more apps and even swap them while reusing OS/platform trusted code.
Peter A. • June 28, 2013 8:00 AM
The malware described needs quite a lot of social engineering to succeed. First, lure the user to some site and get his computer infected (that’s easy), then compel the user to install some “banking security app” on his smartphone, them compel him to pair the two.
I’m not particularly impressed. It needs a half-moron user to be successful. If it was all-automagic, like infecting the computer via some vulnerability, looking around for banking sites used by the computer’s owner and spying on him using them, looking for a mobile device used by him and infecting it via Bluetooth/WiFI/USB/whatever, spying on the SMSes received and correlating then with banking activity, finally doing some fraudulent transfer while grabbing the SMS with authorization code and hiding the ledger entry from the user – that’ll be an achievement! 😛
NIck • June 28, 2013 8:20 AM
It’s not even remotely interesting. It is a marketing puff piece by RSA. It’s a bad sales pitch. Want to make it interesting? Tell us now many times this malware has succeeded and how much money it has stolen. Compare that number to the numbers before implementation of two-factor authentication, even crappy SMS two-factor. I’m willing to bet that the SMS system has worked very well.
H4xx • June 28, 2013 8:23 AM
I make my own bank apps that use a cryptostick for 2factor, a pinned SSL cert to prevent spoofing and I run it on a custom build of android I stripped down. To figure out the bank API I ran their stock app inside a emulator and collected all its outgoing requests. This is because I trade a lot of cryptocurrency and don’t trust their stock apps or web logins. The banks I use do not have 2factor ID options besides those useless test questions that can be intercepted once and reused forever.
Sure the bank will reinburse me any unauth transactions but that takes months and I have to run a business. The stock android app they offer is frightening unless you are running seandroid or openpdroid permissions checks, and SQLcipher to store its data malware can yoink passwords saved in cleartext out of the stock app easily.
Kevin Lyda • June 28, 2013 8:40 AM
I’ve never understood the text-message for otp thing. There’s the algorithm implemented by the Google Authenticator app and others and you can run it on practically anything. I use it for dropbox, lastpass, google and aws – it works fine.
I’m sure it’s not perfect, but it raises the bar a bit.
As for malware on your phone, that’s a problem regardless. Most phones have a great deal of access to various accounts and services. Heck, just malicious access to the phone part of your phone can rack up huge charges.
Larry Seltzer • June 28, 2013 8:42 AM
The attack only has a realistic chance of succeeding on Android and for users who have configured the system to allow installs from 3rd-party stores. I think we know already that such users are generally vulnerable. Not interesting.
It’s not a happy situation, but the curated store is clearly the answer to most of our security problems. The Android/Play store is a weak curation, but it’s still largely effective.
Eric Hacker • June 28, 2013 8:45 AM
There are two problems here.
The first is that the banks are sending a secret in the clear. That might have been acceptable before smartphones, but clearly now that is stupid. It’s not just smartphones. If the NSA has a back door into all phone communications, why not the Russian mafia?
The second problem is one of overall security engineering. Somewhere along the line, there likely was some security engineer who raised the issue of the secret being transmitted in the clear. At the time it was the risk was acceptable to management and the project moved on. Now the technology is entrenched and the risk has changed. We should be able to do a better job of keeping up with the changing risk.
Mr.G • June 28, 2013 10:46 AM
My bank device you have to insert your bank code(something you own), enter your pin, and it generates a long one time hash.
I keep the internet bank card in a safe, and the reader in another drawer when not in use.
This seems reasonably secure. (I did help the bank re-engineer the reader to add tamper detection).
I run a one trick browser in a virtual machine to access the bank. I have snort and uptodate AV.
But then, I’m a sad IT security geek, who regularly changes his pins, and actual bank cards.
I own several smartphones, but do not use them for banking.
I have been scammed through NFC cards, but I learnt, and now cut the aerial out.
CASH IS KING!
Wael • June 28, 2013 12:59 PM
I would think (hope) the one time password sent to a mobile device is tied to a specific browser session ID. It remains to be explained how capturing that one time password helps the attacker, given that the one time password is ephemeral. The attacker would also need to hijack the browser session before the legit user as well as capture the one time SMS password before the user sees it.
Peter A. • June 28, 2013 1:23 PM
@wael: I assume it either uses the actual users’s session and sends web request(s) needed to execute money transfer or does the same in a session of it’s own. The malware can capture the login credentials as well and simulate user’s session.
Wael • June 28, 2013 1:45 PM
@Peter A.
The typical scenario I know is this sequence:
1- User points browser at the bank portal, https://bank.com
2- User enters a username
3- User verifies an image that was chosen during registration.
4- If the image matches, user enters password — sometimes multi-factor authentication is used, and sometimes it’s just single factor
5- User now has access to account and proceeds to a transaction
6- User decides to transfer some money to some other account, for instance
7- Bank sends a text message to the user’s MD
8- User enters this OTP into the browser to authorize (or authenticate) the transaction
The passwords I have seen typically have a 10 minute lifetime. If that lifetime elapses, the OTP is invalidated and another one needs to be sent and used.
If an attacker manages to bypass this mechanism (which is not clearly explained in the article, and I am not saying it cannot be done either), then there is the traceability problem. The money must go to another bank account that can be traced to an individual.
Carl 'SAI' Mitchell • June 28, 2013 2:42 PM
RFCs 6228 and 4226 provide a way to create and verify a shared secret that varies with time. They’re widely implemented (Google Authenticator uses this system) and don’t rely on sending the shared secret over text message. It’s easy to use, and less susceptible to malware attack. If the attacker has the ability to modify or replace existing applications they could change the authenticator app, but that’s a much harder permission to get (root access) than the ability to send text messages.
Peter A. • June 28, 2013 2:44 PM
@Wael:
The article describes how a careless user is lured to install two pieces of malware, one his PC (malware-1) and then another on his mobile device (malware-2), then pair the two by entering some code.
The action sequence is more or less like you have described. All these steps can be scripted for a particular banking service as long as maleware-1 running on users’s computer has snatched the username and password (for example, by plugging into the browser and getting contents of specific fields of a specific HTML form on the banking site when this form is submitted by the user during normal login) and malware-2 snatches the OTP sent via SMS and forwards it to malware-1 by some channel.
Of course there’s the issue of traceability, but criminals are good at circumventing that, mostly by hiring mules who withdraw and western-union the money to them. Mules get punished, victims get robbed, criminals keep the money, banks keep the business…
Robert • June 29, 2013 7:08 AM
@Kevin:
Text message OTP is better than a token, because the text message contains details of the action that the password will authorize. Thus, someone who owns the machine you’re using can’t substitute one transaction for another.
Subscribe to comments on this entry
Leave a comment
Sidebar photo of Bruce Schneier by Joe MacInnis.
Martijn • June 28, 2013 5:57 AM
This technique has been going on for quite some time, things like Zitmo (Zeus-in-the-mobile) and Spitmo (SpyEye-in-the-mobile).