
How I reverse engineered my bank's security token - valverde
http://valverde.me/2014/01/03/reverse-engineering-my-bank%27s-security-token
======
jwr
Think 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?)

~~~
viraptor
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.

~~~
chris_wot
He was able to reverse engineer the whole process. The bank's app definitely
sucks.

~~~
_cbdev
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.

------
fpgaminer
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).

------
lstamour
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...](https://play.google.com/store/apps/details?id=com.yubico.yubioath)
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 ;-)

~~~
lstamour
Oh -- and just don't put your phone in the same pocket as your YubiKey! ;-)

------
Vespasian
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...](https://www.ksklb.de/privatkunden/banking/chiptan/chiptan_faq/FAQ-
TAN-Generator.jpg)

~~~
akx
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.

~~~
enqk
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.

~~~
akx
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....](https://play.google.com/store/apps/details?id=fi.op.android.lompsa)),
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
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.

------
memracom
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.

~~~
MichaelGG
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.

------
jrockway
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.)

~~~
valverde
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.

~~~
jrockway
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.

~~~
nly
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

~~~
jrockway
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.

------
sajb
Thanks valverde, quite interesting work, and very well written.

------
shocks
Dark grey text on a light grey background. :(

Apart from this, awesome read.

------
StavrosK
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!

~~~
ryan_collins
[http://web.archive.org/web/20140104041807/http://valverde.me...](http://web.archive.org/web/20140104041807/http://valverde.me/2014/01/03/reverse-
engineering-my-bank's-security-token/)

------
raverbashing
Interesting

I suppose my bank token uses the same structure and produces a similar code
(but I haven't reversed engineered it though)

------
r4pha
A very interesting read. Also, I think I saw you on facebook's hackathon this
year!

------
ithinkso
Why obscuring error/debug messages? Couldn't production just go without it?

------
sebastianavina
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...

~~~
valverde
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.

~~~
hlieberman
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.

------
elwell
Wow, that's commitment!

------
B0Z
Article is 404 inside of 5 hours. That's fairly swift. (assuming OP didn't
remove it himself)

~~~
lstamour
I do not see a 404, perhaps it was temporary?

------
easy_rider
Well explained, nice read!

------
piyush_soni
Just one word. Wow!

------
bblough
Nice work!

------
fiorix
dat hax

