Bypassing Two-Factor Authentication

Yet another way two-factor authentication has been bypassed:

For a user to fall prey to Eurograbber, he or she must first be using a computer infected with the trojan. This was typically done by luring the user onto a malicious web page via a round of unfortunate web surfing or email phishing attempts. Once infected, the trojan would monitor that computer’s web browser for banking sessions. When a user visited a banking site, Eurograbber would inject JavaScript and HTML markup into their browser, prompting the user for their phone number under the guise of a “banking software security upgrade”. This is also the key to Eurograbber’s ability to bypass two-factor authentication.

It’s amazing that I wrote about this almost eight years ago. Here’s another example of the same sort of failure.

Tags: , ,

Posted on December 10, 2012 at 1:04 PM • 40 Comments

Comments

Nick • December 10, 2012 1:22 PM

This would also be a good way to grab phone access even in the absence of two-factor authentication, for some other purpose.

Otto • December 10, 2012 1:47 PM

So, in order for this attack to succeed, the victims had to:

a) fall prey to a trojan link via email spam or similar,

b) visit a bank account site supported by the trojan (presumably it worked with more than one particular bank),

c) fall for the “give us your phone number for a security update” message, and

d) install the trojan onto their phone allowing their 2-factor to be compromised as well.

Okay, I understand that this is a legitimate problem, and that clearly many people (30k-ish) fell prey to this attack… But really, what kind of level of security hoops do you have to put in front of people before they can’t do this anymore? I mean, let’s be frank here, the security failed here on multiple levels specifically because the victims believed what was presented to them at every step of the path. If at any point they had stopped and questioned the sequence of events, then they probably would have broken the chain.

How can you teach a healthy paranoia to somebody to prevent this sort of thing?

Bill • December 10, 2012 1:57 PM

Otto is right on the money. People will do stupid things if you ask them stupid questions. This kind of two factor authentication was nearly fool proof when phones were dumb and couldn’t install a third party app that could intercept texts.

But our phones are smart now, allowing people to make stupid security decisions. So how do we use the intelligence built into the phone to prevent people from doing stupid things? Maybe instead of relying on text messages it should be a push notification that brings up a bank specific app that does some sophisticated secure authentication with the bank and only allows a user to perform the verification. Just about all of the mobile platforms allow enough sandboxing to make this viable, i think.

RH • December 10, 2012 2:28 PM

My solution is still simple: I have a $50 laptop running linux which is only turned on for banking transactions, and the logged off. Now the computer is even harder to break into than the two-factor auth! This makes two-factor auth into security-in-depth, rather than the single line of defense.

Sam J • December 10, 2012 3:06 PM

@RH

Why buy a laptop? As long as everything is being done over the internet (i.e., you don’t need storage space), booting Linux off of a live USB or CD would work just as well.

LPS in particular is perfect for that. It’s specially designed by the Air Force to be used by personnel viewing classified documents on their home computers, and as such has numerous protections against any data being left behind on the machine it’s being run through. It also has a handy AES encryption tool that is quite intuitive.

Only downside is they set it up with a theme that makes it look like XP, but, oh well…

itgrrl • December 10, 2012 4:20 PM

@Sam: From a user-adoption, training cost-reduction, and support cost-reduction perspective, setting LPS to look like XP is exactly the right decision.

When I used to set up cheap/free Linux-based systems for my had-only-ever-used-Windows-before friends, I would skin it to look as much like XP as possible, including setting up a “My Documents” and “My Pictures” folder, etc. They weren’t interested in ‘learning’ Linux, and my goal was to make them as self-sufficient as possible in the shortest possible time (to reduce my support burder). This wasn’t an exercise in bringing about the year of Linux on the desktop (hah!), but rather one of providing friends without a computer one at very low/no cost.^

Similarly for the Air Force, I expect the objective is to create a suitably secure environment for their users, without having to re-train them (much).

(I’m sure you actually know all that of course, but I guess I’m feeling chatty today.)

^ Sadly, after putting in a fair bit of effort to provide such a system to one friend, she then went out and bought a Windows system because the one I’d provided for free couldn’t run her Windows games… Sometimes you can’t win. 😉

Clive Robinson • December 10, 2012 4:49 PM

@ Otto, Bill,

But really, what kind of level of security hoops do you have to put in front of people before they can’t do this anymore?

Pick a number between X and Infinity and keep revising upwards.

The problem is the system put in place by the bank is broken in a number of ways. Some of which alow the user discretion and thus fails to ensure a transaction is properly authorised.

Remove the discretion and use the authentication properly then this problem won’t occure.

Briefly as I’ve indicated on this and other blogs many timess before (going back for more years than I care to remember), the two things that are required to be done are,

1, Properly two way authenticate the transaction, user to bank, bank to user, user back to bank with sufficient entropy that for practical purposes the authentication can only be valid.

2, Force the user into the authentication loop such that the transaction has to actuall go through the user to be authenticated.

Whilst there are known solutions to the first requirment (shared secret) it requires the use of an immutable token to get sufficient entropy to ensure the integrity of the transaction authentication.

The second requirment is currently an open problem due to human failings and this is likely to remain open for some time.

The overal description of the process is,

1, The user types the transaction into the token that uses the shared secret to display a unique transaction request string that cannot be altered or replayed.

2, The user types the request string into the browser and it gets sent to the bank.

3, The bank uses the shared secret to decode the transaction request and uses the information along with a unique acceptance code to produce a unique transaction acknowledgment string that cannot be altered or replayed, and sends this back to the users web browser.

4, The user types the acknowledgment string into the token, the token uses the shared secret to decode the string and recover the information returned by the bank and compare it to the original transaction.

At this point the token has acceptable proof that the Bank knows the transaction details correctly, and importantly it was only the bank that could have generated the acceptance code (which is only the case as long as the shared secret is still a secret and the token has not been infected with malware etc).

5, The token displays the transaction details from the bank and asks the user to confirm the transaction. If the user does the token uses the shared secret, the transaction details and the acceptance code to generate a unique transaction compleation string which cannot be altered or replayed.

6, The user types the displayed compleation string into the browser interface and sends it to the Bank.

7, The bank uses the shared secret to decode the compleation string it checks the transaction details and the acceptance code, if and only if they are correct and have been received in a reasonable time frame does the bank process the transaction.

From this it can be seen that two things are important,

A, The shared secret remains a secret and cannot be accessed directly in any way by the user or any other entity ie it remains in a tamper proof modual in the users token and in the bank system. It can only be accessed indirectly in that messages are submited to the tamper proof module that in effect encodes and signs the message and outputs it as a string.

B, The token is for practical purposes immutable and is never directly connected to anything other than the user via the keyboard and display so it is not possible for a malware shim to be loaded onto it.

The problem with this system is the size of the strings sent back and forth that the user has to be able to type in perfectly without either a mistake or frustration…

And that is an almost insurmountable problem because the size of these strings are likely to be a minimum of 32chars each and may be considerably more than that.

Which is going to make the system impracticable at best to use. Hlwever anything less than this is going to be vulnerable to attack.

somebody • December 10, 2012 4:51 PM

@otto and Bill
Phone numbers are not secret. Smart phones are not secure, heck the entire phone system is not secure. Businesses are trying to build security on sand and then blaming the user.

chris • December 10, 2012 5:06 PM

Sam J wrote: LPS in particular is perfect for that. It’s specially designed by the Air Force to be used by personnel viewing classified documents on their home computers

strong skepticism. in the USA, at least, it’s a severe security violation to have classified material at home or on a computer not certified for that purpose. i highly doubt that AF would develop software to facilitate security violations.

tell it to the marines – the old sailors won’t believe you.

Sam J • December 10, 2012 5:16 PM

@ittgrrl – That’s quite strange, the link is still up for me. I’m not in the military, just on a normal network. I did as well know that familiarity was the reason for LPS’ design. Even still though, it still kind of drags. Seeing Tux in the place the Windows logo usually is on the Start menu just makes me want to bang my face against the desk (I’m a Slacker, to give some background to my feelings regarding the ‘purity’ of Linux).

Although LPS is specially designed to leave no trace, any other lightweight linux distro, Puppy Linux, Tiny Core, Damn Small Linux, or Tails (which uses Tor by default) would all do the trick as well as RH’s second laptop trick (assuming he’s running Ubuntu, Fedora, Debian, Slack, Arch, etc).

@chris – That’s just my understanding of why it was created based on some discussions I found about it online, not directly from the military itself. My assumption is that there is some sort of threshold for the classification level of the material. It’s quite possible people were pulling it out of their asses though, as an explanation for why it exists. It did make sense to me, as well, as I can’t figure out why else they would have created it (except as a programming experiment, I guess).

Johnston • December 10, 2012 5:21 PM

Non-technical users can be protected from all manner of attack, past present and future, simply by using NoScript or something similar.

student • December 10, 2012 5:37 PM

@ Sam, @ittgrrl:
I had no problem accessing and downloading the iso.

Ten days ago I posted questions about the attack surface for live CD’s on the Friday night squid fry. No greybeards answered; here are the questions again.

What attack surface does a mini XP live disk run have for access from one USB to another for propagating a trojan/dropper?

Same question for a linux live disk?

Same question for a Windows PE live disk?

Same questions for a live USB run for any of the above?

Thanks.

Here’s what the .mil site has to say:

Any malware that might infect a computer can only run within that session. A user can improve security by rebooting between sessions, or when about to undertake a sensitive transaction. For example, boot LPS immediately before performing any online banking transactions. LPS should also be rebooted immediately after visiting any risky web sites, or when the user has reason to suspect malware might have been loaded. In any event, rebooting when idle is an effective strategy to ensure a clean computing session. LPS is updated on a regular basis (at least quarterly patch and maintenance releases). Update to the latest versions to have the latest protection.

So the answer is that depending on what you’re doing it is possible to infect the memory space and thereby propagate the virus/trojan to another USB stick through the memory space. Hence, one shouldn’t think that a live CD is completely immune to compromise.

Ben • December 10, 2012 6:29 PM

If you want to secure the system well, then I think you have to dictate the hardware and software that’s allowed to run at least part of the authentication.

I’d run it like this:
You go through your bank as normal with whatever the best security that can reasonably be managed is. Your bank receives your request to do something with your money and sends an encrypted copy of that request back to the their secure device that they’ve given you in branch, where it gets decoded. You then use that device to authorise the transaction. And that device does one thing, accepts a known form of input, in a known way on a restricted platform and refuses to run anything else.

That’s the only way I can think of to do it and be reasonably sure.

Otherwise, if the user’s end is compromised, it’s game over. One time codes won’t do it. You might think you’re typing what you wants into the browser, and you might think it’s telling you the right answers back, but your stuff never went to the bank, it never even left your machine, the attacker just stripped out the authentication – whatever it is you’re typing in as the one time unique transaction code – and added his stuff to it. The attacker can show you whatever he likes coming back the other way, he’s not actually decoding it for you. What you’re seeing is just smoke and mirrors.

You could defeat man in the middle attacks easily enough, if you assume that the user’s end is secure and the bank’s end is secure. You can have shared secrets to encrypt things, and the attacker can’t meaningfully alter the communication without knowing them. The card reader that goes with my account is one example of a store of such potential shared secrets. I have to put them in when I want to use the money in my account, they encrypt the information, it goes to whoever it goes to. If you used them as keys for strong encryption, they’d be useless to anyone who didn’t know the secret.

Assuming of course that the computer this end is secure. That’s the kicker for me.

Pat • December 10, 2012 7:44 PM

“It’s amazing that I wrote about this almost eight years ago.”

It’s amazing that it took someone eight years to follow your advice.

Vijay • December 10, 2012 11:17 PM

Yup …. very simple Two-Factor Authentication is only as good as the first line of defense …. once that is compromised .. pretty easy to hoodwick all other lines of defenses …
As Bruce keeps advising security is all about adequate protection, detection and reaction .. all these 3 put together … As Otto inidicated with the advent of smart phones and democratization of APIs .. its now even more vulnerable …….

anonymous coward • December 11, 2012 1:56 AM

We can continue about stupid users for a long time, but if doctors would ask “all your problems will disappear with a lobotomy, proceed?” how many “yes” would you get?
We still have not learned to formulate questions or propose systems most users can understand.
Our web page shows some figures we need to type on a token, then our token shows some figures we need to type on the computer, done. Money gone. How much? to whom?
There is only a perceived relation between what we type on a keyboard, what is shown on the screen and what is send over the line. The software is one big MitM doing something.
We can solve it but not by fixing people I am afraid.

Richard Birenheide • December 11, 2012 2:20 AM

Bank policies worsen this. When two-factor authentication was introduced at my bank, one had the choice for SMS or a (cheap) device. I am able to receive SMS to my landline phone (which is a pretty dumb phone). Nevertheless, the bank rejected using the landline for this and insisted for using a mobile number. I opted for the device then (in addition to using a Linux Live USB stick).

Steve Jones • December 11, 2012 4:00 AM

I believe there was a similar case recently with HSBC accounts where the trojan adds “training” options to the online banking website. It looks just like part of the site, so all the two-factor authentication is useless.

I mentioned it to someone in the bank when they were boasting about how secure their new code generator dongles were. I said it decreased security as it gave a false sense of security, making the customer less likely to be sceptical about the new “training” options.

matt • December 11, 2012 4:34 AM

Live CD is the easiest way for free but its secure only if your hardware is not programmable … because malware can infect BIOS or VGA so even if you change your hard drive or use Live CD still malware works (this attack is not common because its much easier to trick people or hack them). as we saw before tokens do not help noobs who are victim of social engineering (problem of security guys is that they see problem from their own skill and think it works, put yourself as a old fat woman who even get scammed by facebook links.. if you understand this then don’t use token as most of american banks. this ACH which take 3 days is much more effective to prevent fraud, European banks who have instant transfer with token security are paradise for black hats)

Peter A. (not the usual one)) • December 11, 2012 5:14 AM

Clive,

Have you thought about how much random text will be required for each transaction? I suspect bank usability teams would scream in protest at making customers copy 50+ random chars each time.

Adam • December 11, 2012 5:57 AM

My bank (Rabo) would be pretty immune to this.

There is a 6 digit pin to log into a bank account which thieves might be able to exploit but to actually do anything inside the account requires answering a secondary challenge. When I want to transfer money, even between internal accounts, the site challenges me with a code and requires I punch it into my device and receive an 8 digit response and type that into the site.

So even if I were unfortunate enough to be running a trojan they’d get to look at my bank account (possibly assuming the site doesn’t vet suspicious IP activity) but would be limited in what they could do.

Clive Robinson • December 11, 2012 11:01 AM

@ Peter A. (not the usual one),

Have you thought about how much random text will be required for each transaction? I suspect bank usability teams would scream in protest at making customers copy 50+ random chars each time

Yes which is why I mentioned it as an (insurmountable problem).

I have in the past thought of various ways to reduce it but each time the attackers come up with a new way (for another attack) that could provide an attack against a shortend string.

For instance I thought about using some kind of shortish checksum, which by using Capatchers would make automated attacks much more difficult… However within a year or so it became clear attackers were not using automated attacks against capatchers but paid next to nothing computer users in places like China, to post spam to blogs etc…

Firefox • December 11, 2012 11:16 AM

Anybody wonder whether the LPS distro includes something that logs your activity to NSA/DIA/MI/etc.?

Alexander Churanov • December 11, 2012 11:31 AM

Very strange. I’m in Russia and my bank requires entering a one-time password for each transaction – this is second factor. One-time passwords are printed on a scratch card, I get the card directly in the bank office.

Why use phones at all? Is it a legacy authentication method?

Jonathan Thornburg • December 11, 2012 12:39 PM

@Alexander Churanov (and others)
A similar one-time-password-for-each-transaction is used by many German banks. Alas, there are already trojans in the wild which successfully attack this scheme. The problem is that if the PC is trojaned, then when you one-time-password-authenticate a transaction, it may actually be a very different transaction than the one you expect. That is, you think you’re one-time-password-authenticating “transfer $rent to $landlord” but the trojan in the browser has invisibly-to-you rewritten the transaction to become “transfer $rent to $crook”.

The only way I know of around this problem, is to cryptographically bind the transaction details to the authentication… which requires a SECURE outboard device to do the crypto.

Clive Robinson • December 11, 2012 2:24 PM

@ Firefox,

Anybody wonder whether the LPS distro includes something that logs your activity to NSA/DIA/MI/ etc.

It does not need to.

All it needs to do is have some kind of recognizable signature within it’s expected traffic.

We already know the NSA is in progress to “Hoover up” all the Internet packets within what the NSA consider ther purview. Thus all they realy need is some marker used to identify the traffic type…

RH • December 11, 2012 5:55 PM

@Clive

I think one can boil the problem down to much simpler (though the full robust path you describe is nice): Secure transactions require a secure computing device. In your system, it is an “immutable token,” but it can be anything.

Boiling down your transaction yields:
– The bank must generate a 1 time transaction, which it will harden against replay attacks (separate from the authentication method)
– Some method to transfer that 1 time transaction to the secure computing device (your method was having the user type it in)
– Some way of viewing the transfer on a secure display on the secure computing device (your method did this as part of typing in the transaction)
– The secure computing device signs the transaction using any method desired
– The secure computing device transmits the signature to the insecure medium (in your case, by having the user type it in)

I find the most undervalued part of the whole process is the secure display. The only way to truly stop man in the middle attacks is to be able to trust the device you’re using to inspect the transaction.

Clive Robinson • December 12, 2012 2:37 AM

@ RH,

Secure transactions require a secure computing device. In your system, it is an “immutable token,” but it can be anything

There is a subtle problem with “immutable token” that needs to be addressed (and no I did not go into it this time around explaining it, so here we go 😉

Immutable tokens are a theoretical device which in practice just don’t get made in a standard low cost manufacturing dessign. And further for such a device to be even close to “secure” they have to be bug and backdoor free as well…

To make something immutable, bug and backdoor free and suitable for low cost production is a tough bordering on impossible problem…

However let us assume the device does not have a backdoor but might have a bug. Due to testing and some formal methods we know the device will work correctly for correct input and that to behave incorrectly it needs incorrect input in the form of malware.

Thus provided we control the input to the device to correct input only it will suffice for the task it is designed for.

We can do this by making the device only communicate to the outside world through the user, and make the user innitiate the transaction through the device.

Provided the user can tell the difference between correct input and malware then we can negate the device bug issue by moving it to the user recognising incorrect input.

There is of course a problem with this over and above the user typing in a lot of information, which is the information has to be meaningfull to the user so they can differentiate it from potential malware. Which has the downside of making the communications process longer (but probably less error prone).

All in all the “not in person” transaction problem is a difficult one and involves all sorts of tradeoffs to move it from theoretical to practical. And everywhere you perform a trade off you potentialy open a point of attack.

It quickly gets to the point where you get into a guessing game of “security margins” where, “You know there is an actual or potential risk but you view it as acceptable within current knowledge / technology available to you.” (think size of DES key as an example). You are in effect placing a bet against the future/unknown knowledge which is perhaps not a good idea as the attackers are likely to be better at finding bugs etc as they have future time on their side, whereas you don’t with production deadlines.

As far as I’m aware I was the first person to publicaly propose using SMS as a side channel to give secure authentication back in the 1990’s, but indicated I thought it impractical due to “secondary service” timeliness issues. Since then a lot of things have changed and as I indicated above with capatchers in ways I would not have guessed at because the idea had not (as far as I’m aware) even been thought of at the time.

Patrick G. • December 12, 2012 10:23 AM

SMS-TAN systems were introduced after the old (indexed) TAN systems were deemed too easy to exploit even without any user interaction (drive-by infection, man-in-the-middle attacks etc.)

The fix for generic (i)TAN cards was that SMS-TAN systems don’t just give a code but show transaction details and amount so you can check the code is used for the transaction you desired.

Sure it won’t help if you give them full access to your Smartphone by following a series of unclever actions, but let’s be serious, if they own your Smartphone, E-Mail and your home PC there is no end to how they could screw you…

As to alternatives with old-style “dumbphones” and special ReadOnly-Linux-PCs or ROM-Distros: never going to happen for the majority of people. Period. They would rather go to the Bank counter “per pedes” to make a transaction…

brazzy • December 12, 2012 3:17 PM

@Adam:

Sorry to burst your bubble, but that method offers almost no additional security when your computer is compromised, as the malware can do a man-in-the-middle attack and when you next want to transfer money between your accounts, you’re actually confirming via your device a transaction that moves everything you own to the Ukraine while your browser shows you a perfectly innocent internal transaction.

Otto • December 13, 2012 3:23 PM

To be fair about it though, people don’t understand 2-factor authentication anyway, so it may be a case of they don’t know what the expected path to be taken is, and thus cannot recognize when they have deviated from it.

Every time I’ve tried to explain how Google Authenticator works (I use it for my gmail account) to somebody, at some point I’m invariably asked “so, what happens when your phone can’t connect to the internet?” They assume that there’s some communication between the phone and Google to do the authentication, when there is not.

John • December 16, 2012 1:45 AM

Honestly, once there’s malware running on the user’s OS, all bets are off. 2fa is red-herring.

JB • December 17, 2012 7:54 AM

In my opinion part of the problem is that the users are now left on their own. Two decades ago you couldn’t do much bank business without interaction with bank people. Now normally you can’t even reach them when you want to. It’s all online, it’s all automatic … and cheap of course. So when you see that message there’s no easy way to just call the bank and ask … Of course if there were a phone number displayed on the webpage that number would be faked too :-).

MCE • December 19, 2012 11:22 AM

It is not necessary to generate and rewrite 50+ random characters. Keep in mind that such an OTP is valid only for limited amount of time and just for one transaction, if HOTP is used, you can retype 9 random characters as well.

As of the transaction details (target account number, amount and currency), you need not to retype them into calculator, there are many solutions how to transfer them from the computer screen to the calculator. One solution I described here one year ago. (It’s in Czech, sorry, but you can use Google translator, if you are interested).

fjf • January 1, 2013 3:55 PM

In Germany, many bank customers use “SmartTAN optic”. The secure(1), immutable(2) token is a generic TAN generator with an individual chip card.

After logging in to the bank site with a password (PIN) you can see your data. To make a transfer, you enter the data (recipient, amount, etc.) on the web site. It then generates a flickering code which is read by the TAN generator via optical sensors from the screen. It shows the data on a small display and computes a 6-digit TAN from it using the secret on the chip card. The user types this number into the web site form and submits it to the bank which can verify the TAN. (More details on Wikipedia; the English version is not so detailed, but you may be able to translate the German version or at least see some pictures.)

An attacker who controls the victims’s computer can read their data, but if they try to modify the transaction details, the data displayed on the TAN generator won’t match and the customer will notice (if they pay attention, otherwise it’s all a useless endeavour anyway).

After (usually) 3 failed attempts the account is locked. So the TAN does not have to be excessively long and uncomfortable to use (6-digits mean a 3/1000000 chance for a guessing attack; much better than the 4-digit TANs used on ATMs here).

(1) Of course, an attacker could attempt to subvert either one in production, transport or at the customer’s site, as by breaking in. These are not really attacks against electronic banking, more like physical attacks and the usual security mechanisms (secure transport, secured storage etc.) would apply.

(2) The only input to the TAN generator (apart from a few buttons to basically start the procedure) are the chip card and the optical code. An attacker could try to subvert the code in order to infect the device with malware. However, it’s a rather simple device with limited function, and as a programmer myself I do think it’s possible to write such firmware securely (treat the input as fixed-length, or otherwise avoid buffer overflows and other beginner’s mistakes, separate writable data from executable code etc.). So if the device was designed competently (which, of course, the normal has no way to verify), it won’t be possible to subvert it like smartphones.

Leave a comment

Login

Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via https://michelf.ca/projects/php-markdown/extra/

Sidebar photo of Bruce Schneier by Joe MacInnis.