8 ms·
How I reverse engineered my bank's security token
- fiorix 13y agodat hax
- bblough 13y agoNice work!
- piyush_soni 13y agoJust one word. Wow!
- elwell 13y agoWow, that's commitment!
- memracom 13y agoA 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.
- MichaelGG 13y agoWhat 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.
- tokenizerrr 13y agoLooked like they did pretty much everything right to me.
- drdaeman 13y agoWhat'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.
- ge0rg 13y agoI 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.
- jrockway 13y agoThe 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.)
- valverde 13y agoThis 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.
- jrockway 13y agoAh, 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.
- nly 13y agoOTP 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
- jrockway 13y agoI 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.
- easy_rider 13y agoWell explained, nice read!
- sebastianavina 13y agohe 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...
- s_henry_paulson 13y agoI think the lesson you were supposed to learn is "responsible disclosure"
- jrockway 13y agoWhat was embarrassing about it? You didn't add the security hole to the software.
- harryh 13y agoWhat security hole?
- valverde 13y agoI 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.
- hlieberman 13y agoI 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.
- fpgaminer 13y agoWonderful 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).
- lstamour 13y agoThis 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.yubioath 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 13y ago[deleted]
- lstamour 13y agoOh -- and just don't put your phone in the same pocket as your YubiKey! ;-)
- deleted 13y ago[deleted]
- B0Z 13y agoArticle is 404 inside of 5 hours. That's fairly swift. (assuming OP didn't remove it himself)
- lstamour 13y agoI do not see a 404, perhaps it was temporary?
- jwr 13y agoThink about it for a moment. He did all this (impressive) work just because the application that the bank provided sucked. 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?)
- lclarkmichalek 13y agoCould we at least wait for the bank to give its response before we start condemning it?
- flurdy 13y agoI 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.
- kybernetikos 13y agoI 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.
- deleted 13y ago[deleted]
- mschuster91 13y agoGerman banks do this with the HBCI standard - some quirks aside, you can use the same banking app for nearly every bank in Germany.
- StavrosK 13y agoIt 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!
- ryan_collins 13y agohttp://web.archive.org/web/20140104041807/http://valverde.me/2014/01/03/reverse-engineering-my-bank's-security-token/ http://web.archive.org/web/20140104041807/http://valverde.me...
- aaronsnoswell 13y agoBack up for me now.
- sajb 13y agoThanks valverde, quite interesting work, and very well written.
- Vespasian 13y agoWhile 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_faq/FAQ-TAN-Generator.jpg https://www.ksklb.de/privatkunden/banking/chiptan/chiptan_fa...
- akx 13y agoFor 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.
- enqk 13y agoNordea'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.
- akx 13y agoI 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.lompsa 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... :)
- nly 13y agoJust 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.
- raverbashing 13y agoInteresting I suppose my bank token uses the same structure and produces a similar code (but I haven't reversed engineered it though)
- r4pha 13y agoA very interesting read. Also, I think I saw you on facebook's hackathon this year!
- shocks 13y agoDark grey text on a light grey background. :( Apart from this, awesome read.
- ithinkso 13y agoWhy obscuring error/debug messages? Couldn't production just go without it?