How I reverse engineered my bank's security token(valverde.me)
valverde.me
How I reverse engineered my bank's security token
http://valverde.me/2014/01/03/reverse-engineering-my-bank%27s-security-token
21 comments
I don't really agree with the description of the app: "the application that the bank provided sucked". What's the reason for this? The only thing he didn't like about the app was that when he reflashed the phone he had to re-register it. ("calling the bank every so often after changing ROMs, resetting or changing phones") Does that app suck? I don't think so, you should reauthorize the app on every new device and if reflashing your phone makes it look like a new device, that's not really the app's problem, is it?
> what do you think the bank will do? Hire him (or buy the app), or fight him?
Ignore. Most likely they didn't write the app, but rather contracted the work to some company that specialises in writing apps. There's no reason for the bank to hire him. He didn't produce any better app either.
I'm all in for a good rant about companies preventing reverse-engineering and modifications of software, but I really don't believe this is the right article for it.
> what do you think the bank will do? Hire him (or buy the app), or fight him?
Ignore. Most likely they didn't write the app, but rather contracted the work to some company that specialises in writing apps. There's no reason for the bank to hire him. He didn't produce any better app either.
I'm all in for a good rant about companies preventing reverse-engineering and modifications of software, but I really don't believe this is the right article for it.
He was able to reverse engineer the whole process. The bank's app definitely sucks.
Actually, being able to reverse-engineer and thus also being able to audit the processes and protocols being used is widely regarded to be a good thing, improving overall security standards.
You know that everything can be reverse engineered, right? It only depends on the time you're prepared to spend on the problem.
> The only thing he didn't like about the app was that when he reflashed the phone he had to re-register it.
Lots of apps require you flash a new ROM actually. Dropbox and Gmail to name a couple.
Lots of apps require you flash a new ROM actually. Dropbox and Gmail to name a couple.
Huh? I installed dropbox without doing anything special. Gmail may not be installable from the internet, but gapps can be added without flashing the whole phone.
I meant you have to readd your accounts with the device when you flash a new ROM (even if you backed up the app and data previously). Poor English in my previous comment.
Could we at least wait for the bank to give its response before we start condemning it?
I doubt they will respond. I think they are unlikely to ever really find out. If they find out it is better for them to ignore it because an official response could be picked by main stream media and turn into bad PR for them. By ignoring this story will remain within 'our' very small community and the intersect of those that are Brazilian.
I find it so frustrating that many organisations put massive efforts into software that is very locked down and not as good as the community would provide for themselves and probably share for free.
This is particularly obvious in the case of media companies and banks. If they provided a nice API instead of specialised webapps, there'd be beautiful and more functional applications available for free to their customers within weeks.
This is particularly obvious in the case of media companies and banks. If they provided a nice API instead of specialised webapps, there'd be beautiful and more functional applications available for free to their customers within weeks.
German banks do this with the HBCI standard - some quirks aside, you can use the same banking app for nearly every bank in Germany.
[deleted]
Wonderful work, and thank you for documenting the experience. From the title, I thought this would be a story about decoding a banking website's cookies and gaining access to other peoples accounts, or something similar. I was quite surprised to see that your bank did basically everything right. I was also surprised that you went so far as to implement an embedded clone. Very cool!
P.S. Consider yourself lucky to have such a bank. Here in the U.S., our major banks do not take security seriously by any stretch of the imagination (they have little incentive to).
P.S. Consider yourself lucky to have such a bank. Here in the U.S., our major banks do not take security seriously by any stretch of the imagination (they have little incentive to).
This post had me guessing, but good work. First I saw the card with codes and thought you'd be showing that they weren't randomly created. But then you went on to the app -- and from the "What you'll need" section, when I saw the decompiler and the rest, I thought, "I know what comes next," but again I was surprised. You went above and beyond with the decryption of obfuscated error messages, etc. I could have guessed that it was OATH TOTP, as that's how these apps should work. Congrats on getting there from the source code, and indeed it's too bad they didn't retain compatibility with Google.
To fix the bug you mention -- root access from phone -- perhaps you could use something like Yubikey Neo loaded with ykneo-oath. I was searching the code for ykneo-oath (it's a java applet for the small key) to see where the timestamp was used for the dates, but it appears to be part of the YubiOATH app: https://play.google.com/store/apps/details?id=com.yubico.yub... So you'd have to modify the app source (it's on github). The advantage, however, is that your secret isn't stored on your phone and vulnerable to root apps. Instead, your secret is on a mostly-offline key inaccessible from your phone. There's a YouTube video on how it uses NFC to get that OTP from the Yubikey when you need it. In case you're somewhat extremely paranoid, this might interest you. :) For the truly paranoid, you've found a way to disable account recovery methods while mixing time-based and counter authentication mechanisms ;-)
To fix the bug you mention -- root access from phone -- perhaps you could use something like Yubikey Neo loaded with ykneo-oath. I was searching the code for ykneo-oath (it's a java applet for the small key) to see where the timestamp was used for the dates, but it appears to be part of the YubiOATH app: https://play.google.com/store/apps/details?id=com.yubico.yub... So you'd have to modify the app source (it's on github). The advantage, however, is that your secret isn't stored on your phone and vulnerable to root apps. Instead, your secret is on a mostly-offline key inaccessible from your phone. There's a YouTube video on how it uses NFC to get that OTP from the Yubikey when you need it. In case you're somewhat extremely paranoid, this might interest you. :) For the truly paranoid, you've found a way to disable account recovery methods while mixing time-based and counter authentication mechanisms ;-)
[deleted]
Oh -- and just don't put your phone in the same pocket as your YubiKey! ;-)
While I don't know about the situation elsewhere in the world, here in Germany most banks retired the single use codes (called TANS or (if indexed) iTans) quite some years ago for being insecure.
Most online banking will now require a code created per transaction that is 1. either send to you via text on your mobile phone (and is thus prone to phone malware) or 2. is generated using an external device and the chip on your banking card[1] (a true two factor authentication). Both system will show you the exact details (target account, amount to be send) before confirming the transaction. A virus on the computer is not sufficient to hijack your account.
Just out of curiosity: What security measures do your banks employ and do they allow you to upgrade to a higher security level?
[1]https://www.ksklb.de/privatkunden/banking/chiptan/chiptan_fa...
Most online banking will now require a code created per transaction that is 1. either send to you via text on your mobile phone (and is thus prone to phone malware) or 2. is generated using an external device and the chip on your banking card[1] (a true two factor authentication). Both system will show you the exact details (target account, amount to be send) before confirming the transaction. A virus on the computer is not sufficient to hijack your account.
Just out of curiosity: What security measures do your banks employ and do they allow you to upgrade to a higher security level?
[1]https://www.ksklb.de/privatkunden/banking/chiptan/chiptan_fa...
In The Netherlands you can go with a bank like ABN that issues you a dongle called the e.dentifier. It looks like this: http://thumbs.dreamstime.com/z/dutch-ideal-paymentsystem-usi...
To make an online transaction with it you insert your debit card into it, enter a random sequence of digits displayed on the bank website as well as your PIN in the dongle to get a sequence of digits that you enter into the dongle again.
I found it annoying to have to carry this device everywhere in case I needed to make a bank transaction, so I went with the only bank in The Netherlands that does TAN codes, ING.
Every 6-8 months or so I'll get a sheet of 100 TAN codes in the snail mail, I'll OCR the full sheet with offline-enabled Android app whose name I forget, convert it to a text file, edit it a bit, and encrypt the text file with GPG.
Then when I need to make transfers I can ssh to a box or use my laptop to "gpg -d tan.txt.gpg | grep ^123" where 123 is the TAN code number that the online form requests.
They recently amended this system so that there's a second set of TAN codes (that comes in another snail mail) that they'll supposedly ask for if you make a transaction from a suspicious IP address, I've yet to use one of those.
It sucks a bit but I find it far better than having to carry some device on my person at all times.
To make an online transaction with it you insert your debit card into it, enter a random sequence of digits displayed on the bank website as well as your PIN in the dongle to get a sequence of digits that you enter into the dongle again.
I found it annoying to have to carry this device everywhere in case I needed to make a bank transaction, so I went with the only bank in The Netherlands that does TAN codes, ING.
Every 6-8 months or so I'll get a sheet of 100 TAN codes in the snail mail, I'll OCR the full sheet with offline-enabled Android app whose name I forget, convert it to a text file, edit it a bit, and encrypt the text file with GPG.
Then when I need to make transfers I can ssh to a box or use my laptop to "gpg -d tan.txt.gpg | grep ^123" where 123 is the TAN code number that the online form requests.
They recently amended this system so that there's a second set of TAN codes (that comes in another snail mail) that they'll supposedly ask for if you make a transaction from a suspicious IP address, I've yet to use one of those.
It sucks a bit but I find it far better than having to carry some device on my person at all times.
For my bank (Nordea in Finland), it's numeric user id + single-use 4-digit code (on a physical card; they automatically mail you a new one when you're starting to run low on codes) to log in to net banking. A random one of ~30 multi-use verification 4-digit codes is then used to confirm a transaction.
In addition, the Nordea mobile app uses a request to activate a single 4..8-digit password for read only access to your information. (I may have reverse engineered the app a tiny little bit to find this out. The underlying HTTPS API is, as one might imagine from a banking app, terrible.) Beyond that, you still need the above login procedure to do writes (transactions) with the app.
In addition, the Nordea mobile app uses a request to activate a single 4..8-digit password for read only access to your information. (I may have reverse engineered the app a tiny little bit to find this out. The underlying HTTPS API is, as one might imagine from a banking app, terrible.) Beyond that, you still need the above login procedure to do writes (transactions) with the app.
Nordea's finnish service was the simplest, most comfortable service of all the (4) european banks I've tried.
And I liked that their service is not fancy for fanciness' sake. (In terms of the way the website looked and functioned)
Not anymore a customer, unfortunately.
And I liked that their service is not fancy for fanciness' sake. (In terms of the way the website looked and functioned)
Not anymore a customer, unfortunately.
I agree. The competitors are starting to pass Nordea wrt technology though -- I've only heard good things about OP-Pohjola's Pivo app (https://play.google.com/store/apps/details?id=fi.op.android....), and apparently Danske Bank has some sort of analytics built-in to their webapp nowadays too.
That said though, I'm so happy Nordea finally added free TSV export of bank statement data. I rolled my own analytics script in Python based on that... :)
That said though, I'm so happy Nordea finally added free TSV export of bank statement data. I rolled my own analytics script in Python based on that... :)
Luckily, that's not true!
First, I think chipTAN is not publicly documented, and given banks' track record in security matters, I certainly would not want to trust a system that is not publicly documented, and secondly, using a card that I am supposed to carry around all day instead of putting it into my safe at home for transaction authentication doesn't sound like that bright an idea to me.
mTAN is completely braindead, of course, given the essentially non-existent security of mobile networks.
First, I think chipTAN is not publicly documented, and given banks' track record in security matters, I certainly would not want to trust a system that is not publicly documented, and secondly, using a card that I am supposed to carry around all day instead of putting it into my safe at home for transaction authentication doesn't sound like that bright an idea to me.
mTAN is completely braindead, of course, given the essentially non-existent security of mobile networks.
While that are definitely a valid concerns I prefer that closed undocumented system over others that have actively been used to steal money(sometimes even undetected for some days). The probability that a virus infects my computer is (even with up-to-date software and AV) magnitudes greater than someone breaking the debit card transaction authentication.
So until something better comes around chipTANs "hopefully/maybe some level of cryptographic based security" beats "sheet of paper with no verification at all" ;).
So until something better comes around chipTANs "hopefully/maybe some level of cryptographic based security" beats "sheet of paper with no verification at all" ;).
Are you sure that you don't mean "especially with AV"? AV is an attack surface, not a security mechanism.
Also, how do you know that chipTAN has not been used for stealing money yet? Criminals commonly don't publish their methods, and as far as banks are concerned, the customer did something wrong and is lying unless the customer can prove that the (proprietary) security system is broken. Not exactly favourable conditions for finding out about security problems.
Also, how do you know that finding a security flaw in chipTAN/some chipTAN implementation is more difficult than finding a security flaw in your webbrowser for someone who is motivated by the monetary reward of doing so? You are aware of the gaping security holes in GSM SIM card software, for example?
I think you are making a whole lot of not particularly well-supported assumptions there.
Also, how do you know that chipTAN has not been used for stealing money yet? Criminals commonly don't publish their methods, and as far as banks are concerned, the customer did something wrong and is lying unless the customer can prove that the (proprietary) security system is broken. Not exactly favourable conditions for finding out about security problems.
Also, how do you know that finding a security flaw in chipTAN/some chipTAN implementation is more difficult than finding a security flaw in your webbrowser for someone who is motivated by the monetary reward of doing so? You are aware of the gaping security holes in GSM SIM card software, for example?
I think you are making a whole lot of not particularly well-supported assumptions there.
Unfortunatelly Deutsche Bank has not retired TANs and wants to charge me for using a SMS TAN.
Makes me want to ask: you really want to charge me for an SMS after all the interest you make from me leaving my money there?
But I suppose TANs are still preferred by the luddites that abound in Germany
Makes me want to ask: you really want to charge me for an SMS after all the interest you make from me leaving my money there?
But I suppose TANs are still preferred by the luddites that abound in Germany
Which security concerns have been voiced against iTANs? I saw them as the equivalent of a one-time-pad, secure as long as both the secret and the index are not both intercepted. And super cheap and simple.
Phishing. A MITM attack could "intercept" real transactions and exchange the receiving bank account ID without the user noticing (some even will manipulate the account transaction history!) so you'll only notice it when your bank calls you or your ATM/debit card won't work anymore because your account is empty.
As a matter of fact, this is done (with user consent) by Sofort.com to authorize immediate payments. MITM as a service!
isn't the same attack valid with token based cards (I'm only familiar with RSA's tokens) .. as long as you're in the middle, anything goes..
All tokens distributed by banks I've seen until now here display the amount and the receivers account number prior to generating the transaction confirmation number. So you can double check that everything is correct
Some of these tokens (active ones) display the transferred amount. I dont know if these are still actively used, though.
Just another example of a proprietary implementation tweaking a de-facto standard / well-known algorithm (RFC 6238) just enough to be annoying.
Fresh in my mind is the Wii U controller reverse-engineering presented at 30C3, where the WPA-PSK handshake protocol was tweaked by performing bit-rotations on the resulting keys.
Fresh in my mind is the Wii U controller reverse-engineering presented at 30C3, where the WPA-PSK handshake protocol was tweaked by performing bit-rotations on the resulting keys.
[deleted]
Thanks valverde, quite interesting work, and very well written.
Dark grey text on a light grey background. :(
Apart from this, awesome read.
Apart from this, awesome read.
It looks like this is down, does anyone have a mirror? It's frustrating to read all the gushing comments and not be able to read the post!
Interesting
I suppose my bank token uses the same structure and produces a similar code (but I haven't reversed engineered it though)
I suppose my bank token uses the same structure and produces a similar code (but I haven't reversed engineered it though)
A very interesting read. Also, I think I saw you on facebook's hackathon this year!
Why obscuring error/debug messages? Couldn't production just go without it?
dat hax
Nice work!
Just one word. Wow!
Wow, that's commitment!
A good lesson for those of us who have had the idea of building a similar app to generate one-time passwords. Now we have a better idea of the minimum that needs to be done to build such an app securely. Thanks.
What exactly does this give you as a minimum? If you distribute code to a client, they can look at it. The only way to prevent this is relying on some sort of "trusted hardware" model or not distributing code.
What's the point on securing the algorithm?
Especially since this is just OATH-TOTP under the hood, with a weird key provision scheme that uses SHA1 of device's ID (huh?) instead of bank- or user-provided random key.
On the contrary, I think it should be open, so anyone can audit the application.
Especially since this is just OATH-TOTP under the hood, with a weird key provision scheme that uses SHA1 of device's ID (huh?) instead of bank- or user-provided random key.
On the contrary, I think it should be open, so anyone can audit the application.
I would add one thing to the list though: the PIN is stored as part of the data, instead of being used as the basis of an encryption key. With PBKDF2 and the option to supply longer PINs/passphrases, this can improve security by another significant step.
Looked like they did pretty much everything right to me.
The only point of these token generators is to provide a stream of tokens, so that if the generator is cloned (which is trivial), that can be detected. That's it. As far as I can tell, this attack does not prevent the server from detecting a cloned token.
(To do that, you would have to install a new client on the victim's device that will increment its counter and tell you the counter when you ask.)
(To do that, you would have to install a new client on the victim's device that will increment its counter and tell you the counter when you ask.)
This specific token is time-based, so a clone would not be detected.
On the other hand, counter-based tokens as you described them do exist, and it would indeed be simple to detect if one of those was cloned.
I wouldn't even call this an attack, given that you would need physical access to a rooted device to carry it out.
On the other hand, counter-based tokens as you described them do exist, and it would indeed be simple to detect if one of those was cloned.
I wouldn't even call this an attack, given that you would need physical access to a rooted device to carry it out.
Ah, time-based tokens are basically against adversaries with physical access to your time-based token. Good against password guessers / leaked password databases, however, which is a much more realistic attack these days.
OTP tokens usually don't protect you against server database compromise because they're completely symmetric. The server has a copy of the seed/key stored in the clear. OTPs really only protect you against key logging
I mean for the password reuse case. You use the same password for example.com and Gmail. Someone steals the example.com password database. They still can't log into your Gmail account because they don't have your second factor.
Well explained, nice read!
he is going to get a very awkard phone call from the bank...
Some years ago I stumbled with something similar on a webpage, posted it on reddit, and the next day the IT manager of the company called me... it was one of the most embarrassing days of my life.
Lesson: don't mess with other peoples work just because you can...
Some years ago I stumbled with something similar on a webpage, posted it on reddit, and the next day the IT manager of the company called me... it was one of the most embarrassing days of my life.
Lesson: don't mess with other peoples work just because you can...
He didn't "mess with other peoples work". He looked at what his computer was executing. This isn't even like poking at a webpage and telling someone it appears to not validate inputs - the code was running on his own computer.
On top of that, why would you ever feel embarrassed? Perhaps if you posted something very damaging with the sole intent of harming that person, then realised they weren't responsible for the problem.
On top of that, why would you ever feel embarrassed? Perhaps if you posted something very damaging with the sole intent of harming that person, then realised they weren't responsible for the problem.
I recognize this as a possibility and I would definitely take it down if the bank requested it.
On the other hand, if anything, I exposed that they did a good job. They could have rolled out their own crypto, or some flawed form of code generation, in which case I would have disclosed it to them through proper means. But they adhered to standards (TOTP, RFC6238) and protected their data as well as possible. This article should be seen as praise.
Then again, corporations aren't always that understanding, which is why I would be happy to comply.
On the other hand, if anything, I exposed that they did a good job. They could have rolled out their own crypto, or some flawed form of code generation, in which case I would have disclosed it to them through proper means. But they adhered to standards (TOTP, RFC6238) and protected their data as well as possible. This article should be seen as praise.
Then again, corporations aren't always that understanding, which is why I would be happy to comply.
I agree. If anything, reading this analysis would make me feel /more/ comfortable about the security of this bank's software, not less It seems that they did pretty much everything right, if a bit strangely, in some cases.
TOTP and co. require a private key, just like all crypto. If you have that private key, bad things happen. This is not exactly news at 11.
TOTP and co. require a private key, just like all crypto. If you have that private key, bad things happen. This is not exactly news at 11.
I think the lesson you were supposed to learn is "responsible disclosure"
Now, once he writes a better app, what do you think the bank will do? Hire him (or buy the app), or fight him?
How much effort do we collectively waste because of moronic organizations that force their crap upon us, that we cannot escape from? (You can go to a different bank, but what if they all uniformly suck?)