Time to move to voiceprint with spoken PIN.
The SpyEye banking trojan has acquired the ability to reroute one-time passwords sent to victims' cellphones, a measure that bypasses protections more and more financial institutions are adopting. According to a blog post published Wednesday by a researcher from security firm Trusteer, SpyEye was recently observed trying to …
Friday 7th October 2011 03:19 GMT Coen Dijkgraaf
Re: Time to move to voiceprint with spoken PIN.
I think it wouldn't take long before the Trojan programs would then record you speaking the PIN and send it of to be re-used. Even if you make it a one time PIN they could put together a sound file with the stolen PIN if they had enough samples of your voice.
Friday 7th October 2011 03:19 GMT Anonymous Coward
Friday 7th October 2011 03:20 GMT Steven Roper
Friday 7th October 2011 04:15 GMT Dr. Vesselin Bontchev
Read the original blog post for a real understanding of the attack
As usual, ElReg's journalist has not understood what is really happening and, as a result, his article is incomplete and confusing. You are strongly urged to read the original blog post, in order to understand the situation.
I mean, by reading just this article, we are left wondering - what would be the point of the attacker telling you that you have been "assigned a new phone number", the SIM card for which never arrives? This, by itself, does not divert the communication from the bank to a phone controlled by the attacker, because the bank will keep sending you the one-time passwords to your original phone.
In reality, this is how it is done. First, the attacker steals your bank credentials - user name and password. Second, he enters your bank account and tells the bank, on your behalf, that you are going to switch to a new phone. In this case, the bank requires a confirmation from you, by requiring you to enter a one-time password sent to your OLD phone.
Meanwhile, the attacker has told YOU that you are being assigned a new phone number, blah-blah, and in order to "activate" it, you have to send to IT the "code" that is going to be sent to you by your bank shortly.
So, the bank sends you the code you are supposed to enter as confirmation that you are changing phone numbers, you send that code to the phone number indicated by the attacker, thinking that you are "activating" it, the attacker receives the code and enters it on your behalf into the form on the bank's site, in order to confirm that "you" are switching to a new phone number. Presto, the attacker has replaced your phone number with his in the bank's database.
It is riskier than usual for the attacker, though, since it leaves traces in your phone's logs of a phone number owned by the attacker. That can be traced, so the attacker has to take additional steps to prevent that.
Friday 7th October 2011 08:40 GMT MacroRodent
The Bank's error
So the real failure here is that the bank allows the addresses used by the of the out-of-band confirmation mechanism to be changed by in-band messaging, which the crooks then intercept! They should require an actual office visit for setting or changing the phone number used for verification.
Friday 7th October 2011 11:29 GMT Dr. Vesselin Bontchev
"So the real failure here is that the bank allows the addresses used by the of the out-of-band confirmation mechanism to be changed by in-band messaging, which the crooks then intercept!"
This isn't quite true - the bank uses the same out-of-band channel to confirm that you are changing phones that it uses for confirming that it's really you entering your password.
But this, of course, is correct:
"They should require an actual office visit for setting or changing the phone number used for verification."
I don't know which is the bank that is being attacked by this. "As is", the attack won't work against the bank I use. They require the entering of an SMS-received code at the very first step (logging in) - not when you've already logged in and have requested to change your registered phone number. But this is just a technicality - it is trivial to adapt the attack, so that it works in this case, too. Plus, my bank requires an out-of-band confirmation only at login time, not for every transaction, which is a definite minus.
There are viruses which do not attempt to steal your credentials but, instead, simply modify on-the-fly the transactions you are sending, so that when you think that you have just instructed the bank to send $100 to Alice, it has actually received a command to send $10000 to Bob. (They even modify on-the-fly your balance, as shown by the bank's site, so that you don't see that more money than expected have disappeared.) In such cases it would be useful to receive from the bank an out-of-band communication about how much money and where you've just sent.
On the plus side, if I want to change my registered mobile phone number, my bank requires me to appear there in person and to sign a form.
Friday 7th October 2011 20:22 GMT Nun of Thee Above
"But this, of course, is correct: 'They should require an actual office visit for setting or changing the phone number used for verification.' "
Easy for you, but rather more difficult for those of us living abroad. You suggest it's appropriate that expats and workers overseas be required to spend time and money traveling simply to register the change of a phone number?
As the Web, like email before it, was never designed to be a secure environment, it's time for the banking industry to step up and take an honest look for ways to rectify the problems. Either that or banks should become liable for the "unusual transactions" to money mules which are at the heart of the fraud involving commercial accounts.
Saturday 8th October 2011 08:17 GMT Dr. Vesselin Bontchev
"You suggest it's appropriate that expats and workers overseas be required to spend time and money traveling simply to register the change of a phone number?"
Indeed, it is a problem for such people. But do you see a better solution?
"it's time for the banking industry to step up and take an honest look for ways to rectify the problems."
Like, how? Security theory suggests that both sides should authenticate themselves to each other - i.e., the bank should be certain that it is talking to you, and you should be certain that you're communicating with the bank. But how to achieve this if you communication channel is compromised? Public-key encryption can do that only if the channel provides at least authenticity during the key exchange (confidentiality of the channel is never needed and authenticity is not needed after the key exchange). But if the channel is completely compromised, you can't have even that and you get man-in-the-middle (or man-in-the-browser) attacks.
The best the banks can do for now is use and additional, out-of-band channel (the phone). But if that's compromised too, all bets are off.
One solution is to perform the initial key exchange in person, when you're opening the bank account. But that, too is vulnerable. People will fail to safeguard access to their secret key, malware will modify the transactions on-the-fly, as I explained above, and so on...
"Either that or banks should become liable for the "unusual transactions" to money mules which are at the heart of the fraud involving commercial accounts."
In many countries they already are, if you complain on time. I mean, if you regularly check your account and complain to the bank about any unusual transactions you did not make, the bank will restore you the lost money.
Friday 7th October 2011 08:51 GMT Ian McNee
True, but there's no Trust 'ere...
As usual for Trusteer "security bulletins" the only mitigation they suggest is the use of their software. In this case they are fairly subtle about it:
"The only way to defeat this new attack once a computer has been infected with SpyEye is using endpoint security that blocks MITB techniques."
However, even if this is more subtle than their usual "BUY OUR SOFTWAREZ NOW LUSERZ!!!" (directed at the banks with the cost inevitably added to our charges in the long run), it is at best a questionable claim. If one's PC or other device used for on-line banking has been pwned then the use of MITB social engineering techniques is the least of one's worries.
Friday 7th October 2011 08:40 GMT Allan George Dyer
In May 2010 http://articles.yuikee.com.hk/photos/Page627/201005Security.pdf I wrote, 'Two trends are on a collision course, on one hand, smartphones with internet browsing are becoming cheap and common, on the other hand, banks are desperate to counter online insecurities by using out-of-band transmission of a one-time-password. How soon will it be before malware that collects your account details as you browse your bank website, initiates a transaction and silently collects and uses the OTP sent by SMS exists?', the answer to my rhetorical question is not long at all!
The one with the dumbphone, please.
Friday 7th October 2011 08:40 GMT Voland's right hand
This is not intercepting SMS
This is changing the SMS number via social engineering.
It is not intercepting SMS just yet. If the troyan had modules which use let's say bluetooth or USB and a piece of let's say Android code to do that job we could say that "intercepts".
By the way, the amount of android phones out there and the relatively lax security of the marketplace will soon make this one worth the effort. The pin nabbing application can pretend to be ball juggling game or something similarly innocuous. There is also always the option of using the same ploy as for the SMS divert - "Here is our new banking one time code app".
SMS codes which do not correspond to a troyan command can be displayed (with some logos and fancy formatting to make the app look legit). SMS codes which were originated by botnet transactions can be hijacked so the user never sees them.
Friday 7th October 2011 11:29 GMT Dr. Vesselin Bontchev
Nevertheless, Alan's point stands. In fact, since I know him personally and he is quite a competent anti-virus researcher, I am surprised that he hasn't realized that the kind of malware he is "predicting" has already appeared - and quite some time ago, too.
The first one that I remember - and I might be wrong on this, in the sense that there might have been an even earlier one - appeared more than a year ago. It was a mobile component distributed by one of the Zeus Trojans. I think we called it Zitmo. It was for Symbian phones and did precisely what Alan is predicting - stole the out-of-bank SMS message sent to your mobile phone (infected with it) by the bank and sent it to the attacker.
Recently a similar mobile component (they are both Trojans; not viruses) appeared for Android phones, too. We call it Spitmo and it was distributed by another SpyEye variant.
Friday 7th October 2011 12:39 GMT multipharious
on phone SMS interception
Currently malware writers are just using them to intercept confirmations for premium SMS services in the USA. This is the monetization of the exploit so far as reported by the App Genome project report.
The two factor auth (username and password + OTK) means that even though the attacker might be able to skim the OTK, they would have to know who the user is and their bank details to be able to use it. It would require an infection of both the home computer and the mobile for this to work.
The use case of infection of home computer and mobile is what you are talking about, right?
Saturday 8th October 2011 07:53 GMT Dr. Vesselin Bontchev
"The use case of infection of home computer and mobile is what you are talking about, right?"
Correct. As I said in my message describing this issue, the mobile malware components are Trojans, not viruses. They don't spread on their own. They are dropped by other malware that has already infected your computer.
Monday 10th October 2011 07:30 GMT Allan George Dyer
Was that Zitmo or Mitmo?
I did make the prediction in May 2010, I think Mitmo appeared September 2010, but yes, there might have been an earlier one. Either way, I wasn't aware of them when I wrote that.
In any case, all our currently-used methods for remote authentication can be broken by malware on the endpoint. Banks can pour in money trying to develop new methods, and promoting them as "even more secure" to the customers, but customers just get more confused with the changes (and therefore more susceptible to social engineering attacks), and the crooks develop new malware variants.
Friday 7th October 2011 12:17 GMT david wilson
Presumably rather than having to visit an office, even having the bank ring you up to ask you *why* you want to change your notification phone number would foil this particular scheme?
If the bad guys already actually had full control of your phone, then they wouldn't need to change the notification number in the first place, so in the case of defending against a 'change number' attack, it'd be reasonable to assume that if the bank did ring up, they *would* be talking to you.