Follow Slashdot stories on Twitter


Forgot your password?

Reverse Engineering a Bank's Security Token 55

An anonymous reader writes "An engineer from Brazil has posted a technical walkthrough of how he was able to reverse engineer his bank's code-generating security token. He found a way to accurately generate his unlock codes with some custom code and an Arduino clone. (Don't worry: his method doesn't give him access to anybody else's codes.) 'Every exception thrown by this piece of code is obfuscated, as well as many of the strings used throughout the code. That is a major roadblock, since exception messages and strings in general are a great way of figuring out what the code is doing when reverse engineering something. Luckily, their developers decided to actually show useful text when a problem occurs and an exception gets thrown, so they wrapped those obfuscated strings with a.a, presumably a decryption routine that returns the original text. That routine is not too straightforward, but it is possible to get a high level understanding of what it is doing.'"
This discussion has been archived. No new comments can be posted.

Reverse Engineering a Bank's Security Token

Comments Filter:
  • He found a way to accurately generate his unlock codes with some custom code and an Arduino clone.

    By itself, this isn't a bad thing. But the fact that they've obscured the crap out of their code suggests to me this wasn't done by a crypto expert, but an insecure programmer forced by management to develop a solution in a field he didn't fully understand, and did it homebrew. The overwhelming, vast, pitifully large, number of attempts made by non-crypto experts to do this result in a house of cards when it comes to security.

    There are standard, tested, and amply documented alternatives available. It's just

    • by russotto ( 537200 ) on Saturday January 04, 2014 @01:22PM (#45865741) Journal

      They used a standard algorithm (TOTP from RFC6238, with a Time Step X of 36 seconds and a T0 of April 1, 2007). They obfuscated it for what amounts to no good reason, but there's no loss of security. The problem of preventing someone who controls the device from obtaining the key is the DRM problem, unsolvable without specialized hardware.

      • by Bert64 ( 520050 ) <bert@slashdot. f i r e n z e> on Saturday January 04, 2014 @02:46PM (#45866259) Homepage

        Unsolvable even with specialized hardware, you just increase the costs for both yourself and any potential attacker... Probably increasing your own costs far more than that of the attacker.

      • by Animats ( 122034 )

        Right. But a big problem is preventing some hostile app on the user's phone from obtaining the user's secret key used in the challenge/response algorithm. With the code reverse engineered, atttackers now know where to go looking for that key and what to do with it when they have it.

        Smartphones are not a secure platform. The carrier and Google (for Android) or Apple (for their phones) have total backdoor access. So does anyone who has their signing keys.

      • by mveloso ( 325617 )

        The obfuscated it for the same reason that passwords on-disk should be encrypted: to make it harder for idiots to figure out anything. If you really want to make life difficult you write self-modifying code, but I'm not sure that's possible anymore...

        As an aside, I've wondered how mobile developers protect against someone decompiling their stuff and using their API key. I guess the answer is "they can't."

    • by MightyYar ( 622222 ) on Saturday January 04, 2014 @01:23PM (#45865749)

      This is security through obscurity at its worst,

      I don't get that impression from reading TFA. It sounds like the implementation is mostly OK. Remember that all this generator is supposed to do is verify that you possess the token. Knowing the algorithm, so long as it is sound, shouldn't be a security problem - someone would still need to get their hands on the real token in order to clone it.

      Now, had he figured out a way to divine the secret device ID from the generated codes, well now that would be bad.

      • by Anonymous Coward

        It does break some assumptions though: For any token device, someone can clone it without your knowledge and abuse it.
        Having the physical token is no longer the assurance against abuse by a third party that one would assume.

        • by Bert64 ( 520050 )

          Such an assumption has always been false.
          The problem is the obscurity of the code, if you don't know how it works then you can't be sure...

          If you do know how it works (as mentioned above, TOTP from RFC6238) then you know that it can be cloned, but only if you have the initial seed values...
          Knowledge is power, if you as a user know how the system works then you know what to protect, and you can more easily raise the appropriate red flags if you detect compromise of the seeds.

          As a user i would never be happy

        • But this "token device" is a smartphone, and the bank generator is just an app. You have to assume that physical access means security has been compromised, just as with any other computer. There is nothing on a smartphone that can't be cloned with Titanium Backup and friends plus a few minutes of time.

      • Re: (Score:3, Insightful)

        by Anonymous Coward

        There is still a problem here. Even though physical access is needed to clone the device, it should be prohibitively difficult to do so, otherwise you leave yourself open to an attack where, for instance, someone steals the token while you're sleeping or left it unattended at home and clones it, then replaces it.

        They retain a valid access token, and you're not aware of it because you still have yours.

        • by AmiMoJo ( 196126 ) *

          I doubt the bank is worried about that kind of attack. They likely get thousands of phishing sites trying to trick the user into entering the security code themselves that are a much less risky form of fraud.

      • Now, had he figured out a way to divine the secret device ID from the generated codes, well now that would be bad.

        Since has has duplicated the functionality of the device, including its ability to generate codes... then the "secret device id" is no longer secret. It also invalidates the security model that you need to be in physical possession of the token to access the account.

        He has effectively copied a key that had "do not duplicate" stamped on it. This attack could be carried out against a customer and then used to impersonate them in the future.

        This is not my definition of security that is working, and I'm disappo

        • It also invalidates the security model that you need to be in physical possession of the token to access the account.

          That was not the security model. If that were the security model, the bank would require a dongle instead of an Android app. The security model is that he possesses a unique ID, a password, and a token (in this case, generated from his Android's ID). An attacker would need all three of those things to access his account. One can be read in plain text, one can be picked up with a keylogger, and the third by cloning his phone. Certainly not perfect security, but every piece makes an attacker's life more diffi

      • by jimicus ( 737525 )

        Now, had he figured out a way to divine the secret device ID from the generated codes, well now that would be bad.

        Worse than "bad".

        Looking at the (admittedly obfuscated) screen grabs and the comments that say the bank provide RSA hardware tokens if anyone wants one - I reckon it's a software implementation of an RSA SecurID token, probably bought in directly from RSA. And if it's bought in from a third party, it follows that anyone else who's bought in the same product would almost certainly be vulnerable to the same issues.

  • I'm not particularly concerned, so long as I'm not on the hook for any lost funds. It would be nice to know that our banking institutions were competent, but I'm happy so long as dispute resolutions aren't arduous.

    Speaking of which, I've disputed charges on my credit card twice, and my credit card provider has made it quite painless. If my bank was that forgiving, I'd probably use my chequing account more than my credit account.
  • Tokens? (Score:5, Funny)

    by Dan East ( 318230 ) on Saturday January 04, 2014 @01:35PM (#45865811) Journal

    Does this work on Chuck E Cheese tokens too? I need to feed my skee ball addiction.

  • The most interesting comment for me was this:

    This is not a security vulnerability or even criticism by any stretch. The bank‘s app is (arguably) more secure than Google Authenticator (which keeps secrets around in plaintext), and this article should be seen as praise for the bank’s app, which does things the right way by (mostly) adhering to the TOTP standard, and protects its data as well as technically possible.

    Yes, because any TOTP app must be able to read the secrets to generate the OTP, it must have any encryption keys internally, so it can never really be safe from cloning (unless it relies on a hardware encryption component which the phones don't have). Still, storing in plaintext makes grabbing the token data particularly easy.

  • by MobyDisk ( 75490 ) on Sunday January 05, 2014 @04:34AM (#45869375) Homepage

    FYI: This is not a security breach. The algorithm is not supposed to be the secret. There are lots of android/iphone apps to do this, and most of them use HOTP or TOTP which is an IETF standard algorithm. The security is in the secret key that is generated when you run the app the first time. This key is synchronized between the server and the key generator when it is setup.

It seems intuitively obvious to me, which means that it might be wrong. -- Chris Torek