Tuesday, December 28, 2010

Breaking PIN for software tokens

Software tokens usually use PIN for accessing token functions. Some vendors avoid implementing methods of validating PIN within an application. PIN is validated implicitly by validating dynamic password or response value generated by the application. It is possible because PIN is hashed and then the result (key) is used to decrypt a main key. Next, the main key is used by the application to generate OTP. So when the wrong PIN is provided, the application will decrypt incorrect key and will generate not valid OTP.

But under some conditions it is possible to find out the right PIN code. First of all, we have to obtain at least one valid OTP. For time based tokens we have to know the time when the valid OTP was generated. For counter based tokens we have to find out the counter value. It can be a problem so the attack is more effective when we know an approximate value of the counter for corresponding OTP. The counter is stored in local database of the application and usually we are able to modify the content.

The last step is to perform brute force attack and to compare the values of two dynamic passwords. After every try we have to recover the previous value of the counter (for counter based tokens) or set the right time (for time based tokens).

The attack is very difficult to perform against mobile devices with offline software tokens. We have to have an access to local database of mobile device and capture valid OPT which is send via network.

Tuesday, June 15, 2010

Two-Factor Transaction Authentication

More and more banks to mitigate banking frauds implement new methods of authenticating electronic transactions. Few methods rely on the customer's mobile phone. It looks that today the most popular are SMS messages and software challenge response tokens. Both methods can help in detecting the Man in the Browser attack. And in both cases the customer is able to verify details of transaction during making a payment.

A discussion about which method is "better" seems to be quite interesting. One of such discussion takes place on the OWASP-POLAND mailing list. What "the better" mean? It is tricky to justify which method is "better" because banks must consider several factors. Security is important but system has to be customer-friendly and inexpensive.

I am not going to write here about attack vectors and all pros & cons but in my opinion method which is based on SMS messages has more advantages.

The customer can receive SMS message with transaction details including full destination account number, an amount and an authentication code (valid only for particular transaction). The code is used by the customer to confirm the transaction. When the customer submits authentication code to online banking system then the bank will consider that the customer has just verified transaction details and accepted the payment.

The second method is not customer-friendly enough and can have security issues. I have to emphasize here that I do not have knowledge about all solutions which are available on the market and it is possible that some solutions work in different way and offer different level of security.

As I mentioned, the second method is based on software challenge response tokens. An application (software token) is installed on the customer's mobile phone. Bank and the customer shares the same secret key which is used to generate and verify challenge and response codes.

When the customer makes a payment, the bank's application generates the challenge by using destination account number, an algorithm and a secret key. Only few digits from destination account number are used to create the challenge. Of course all destination account number can be used but then the challenge will be too long. The customer submits the challenge to the mobile phone and after acceptance, details about transaction are displayed on the screen (but only selected digits from destination account number) - the challenge, the algorithm and the secret key are used to calculate and display such information. Sometimes bank requires from the customer to submit additional information like the amount of payment. And then this value is used to calculate the response. In next step, the customer submits the response code to internet banking application. When everything is fine, the bank will accept the transaction. It is a little bit complicated, isn’t it?

I'm going to write more about algorithms in next article. Here let's just focus on numbers.
So why such system can have more secure issues than SMS messages? All because of the challenge code length. Limitation of challenge code length does not allow to display all numbers of destination account. For example, in 6-digit challenge it is possible to “hide” only 4 digits from destination account number.

We can imagine an attack vector where an intruder will use different account numbers which contain the same 4 digits like original destination account number. It is important to mention about the length of IBAN notation of destination account number. The IBAN consists of the Country Code, a 2-digit checksum, a Bank code and the account number. The account number in Poland has 16 digits.

Now, let’s try to calculate the probability of above attack vector. I will use the formula for classical probability P(A) = n (A) / n (S).
Below calculations are performed for the attack where victim and mule accounts have the same Bank code. It is very popular scenario used by frauders. Calculation are done for 4, 5 and 6 digits. Also, I checked if showing first 2-digit checksum from destination account number decreases the risk of the attack.

In addition to the formula I created the Python script to compare results. The script generates the valid account numbers.

Variant 1A – last 4 digits are extracted from the challenge and displayed on mobile phone. Probability is 1:10000. It means that we have to have 10000 accounts to perform a successful attack. Few valid account numbers:


Variant 1B – first 2 and last 2 digits are extracted from the challenge and displayed on mobile phone. It is important to emphasize that the checksum is only used to verify if an account number is correct. It is not related to security and we can notice that probability of attack is the same 1:10000. The result received from my script is presented below:

Variant 2A – last 5 digits. Probability is 1: 100000. Few examples of valid account numbers:


Variant 2B – first 2 and last 3 digits. Probability is 1: 1:100000. The same is for Variant 2A.


Variant 3A – last 6 digits. Probability is 1:1000000.


Variant 3B – first 2 digits and last 4 digits. Probability is 1:1000000.


Above examples show that the risk of attack is very low but the situation can change when we consider that destination account is in different bank and/or that few last digits have value 0 (what sometimes can be true).

Thursday, June 03, 2010

Internet Banking Security

Last few months I was engaged in projects related to internet banking security. I was performing analysis of various variants of malicious software called “banking Trojans” and spent a lot of time playing with fraud detection systems. Currently I am involved in another project related to new methods of transaction authentication. In the meantime I was invited to workshops for the police officers and prosecutors.
I would like to share some materials (in Polish) that I prepared for these workshops. I hope that it can be useful for some of you. First document is available at http://forensic.seccure.net