« previous 1 2

Differential Analysis

A friend of mine, Florian Walther, once came up with a very useful script to plot a Differential Analysis of web application session IDs to analyse their randomness and predictability very quickly. Bind View used the same technique in 2001 to inspect the randomness of TCP sequence numbers. So I decided to throw my not-so-random TAN list into the script and compare it to my list of Perl generated numbers.

When looking at the plots, one should carefully consider the orders of magnitude in which the scaling of the axis differs (Ymax 1400 for Citibank, 1000000 for Perl). It became clear that an attacker could predict the next TAN on my list based on the last TAN I used with a fairly good chance (my math fails to produce an exact number) when using the increment 172, which was the most frequent (9 times) in my case.

So, I tried to inform Citibank.

Their web site states that they test the security of their site on a regular basis using accredited external experts. Luckily, it also lists a phone number, which turned out to be their Internet Banking helpdesk. The call centre guy on the other end did know what an algorithm is and immediately understood why predictable TANs are bad. After a few moments of consideration (the case probably never showed up on the ISO9001 process charts), he suggested to call the Internet Fraud Department of Citibank.

The Internet Fraud Department seemed a pretty logical choice, considering that these people would probably face the consequences directly if a criminal ever discovered the problem. That was, until I called them. The lady (name intentionally omitted) first suggested simply to freeze the current TAN block and order a new one if I'm concerned about its security. And hey, it's free of charge. She also pointed out that the TAN block would be locked automatically after three failed attempts. After trying to explain the problem to her again, we agreed that I document the issue in an email and send it to her, so she could pass it on to the "TAN experts", as she called them.

So I did write an email, attached the plots and explicitly asked for feedback. I also froze the TAN block in question and ordered a new one. After all, the TAN list was from early 2005 and Citibank probably just had a goof-up in their generation software at that point in time. Stuff like this happens all the time. And although the bank has a copy of the TAN list in their system and could therefore identify all customers with a weakly generated list, I can see why they did not recall the lists for fear of bad press and confused customers.

I never heard back from Citibank. But I did get the new TAN list, ordered September 2006, which didn't even have a date of print on it.

Yes, it has the same pattern. The increment from one TAN to the next is now 3,263 in average and the most frequent single increment, 2593, only shows up 3 times, but that's still far from what it should be. Taking the old and new TAN lists together with my Perl generated list and plotting them makes it painfully clear.

If you wonder where the Citibank TAN lists are in the second picture, try zooming all the way into the middle of the cloud.

I'm currently having arguments with another bank about their new terms of use for Internet banking, since they state that it is the customer's responsibility to make sure he's connecting to the real bank web site instead of a phishing site. Most banks in Germany put the burden of proof onto the customer's shoulder and constantly state that it's always the customer's fault when money gets stolen from his account. But the largest private banking institute worldwide fails to generate random numbers and, when notified of the problem in all detail, ignores it. They also state in their Online Banking FAQ that SSL is equally secure to HBCI (Home Banking Computer Interface) and the latter would require such complicated things as chip cards and card readers. But maybe an HBCI terminal would be able to generate random numbers.

I currently see two main attack scenarios for such an issue. The first is an email phishing attempt with a text such as this:

Dear customer,

we are currently working with $authority on a fraud case involving your account. Please reply to this email and send us the last 3 TANs you used in online banking, so we can compare them to the TANs used in the fraud incident. Please make absolutely sure you are not sending a curently valid TAN.

Regards
Citibank

By gathering the replies, the phisher can see what increment range the TANs are in and would have a high chance of finding a working one with only a few hundred people answering the email.

I also don't think it is unlikely to assume that a Citibank customer would note down his used TANs in an unencrypted text file as well as scratching them out, since you usually want to remember what the TAN was used for and there is no space for such information on the sheet. A simple file read vulnerability in the browser can then be used to obtain the list. Given the current state of Citibank TAN lists, the only thing a customer can do today is to consider a used TAN to be as secret as an unused one.

And the morale of the story: if your one-time pad is not random, it's not a one-time pad. (ehe).

Felix "FX" Lindner runs SABRE Labs and specializes in professional security agency services and analysis.

« previous 1 2