> Advisories > rt-sa-2005-014 vertical divider

New banking security system iTAN not as secure as claimed

The new iTAN security feature for online banking promoted by german banks
does not protect against phishing attacks and trojans as claimed.

Details
=======

Product: iTAN Online-Banking Security System
Vulnerability Type: Design Flaw
Security-Risk: medium
Advisory-URL: http://www.redteam-pentesting.de/advisories/rt-sa-2005-014
Advisory-Status: public
CVE: CAN-2005-2779
(https://cve.mitre.org/cgi-bin/cvename.cgi?name=CAN-2005-2779)

Introduction
============

German banks are currently promoting a new security feature called iTAN for
online banking. This iTAN security feature is supposed to protect their
customers against phishing scams or theft of valid TAN numbers through trojan
horses.

More Details
============

As phishing attacks are becoming more and more common, banks are trying to
find new technical solutions to raise the security of their online banking
systems. Due to this, german banks are implementing a new system called iTAN.

In a conventional PIN/TAN system, a client is requested to provide an
arbitrary TAN number he previously received from his bank for the
transaction. Afterwards, this TAN is marked as used and can't be reused. In
this scenario, phishers can intercept the transmitted TAN and use it for
their own purpose.

iTAN is a system where the TAN numbers are indexed. When the client wants to
do anything involving a TAN, the server requests one random unused TAN from
the list by index. Even if the transaction is interrupted, the TAN is from
now on bound to this transaction. The idea behind this concept was to make
intercepted TANs useless for the attacker, as he could only use it for the
original transaction. Quoting one bank, "This technique effectively prevents
against the phishing attacks and trojan horses known today." Similar
statements may be found on numerous websites of other banks.

Unfortunately, these claims are wrong. The iTAN system merely forces the
attacker to act in realtime, which does not make the attack much more
complicated than before. If the computer system of the client is already
compromised by a trojan or the user can be lured onto a phishing site, the
process can take place fully automated without any major drawback.

When RedTeam informed security contacts of german banks about their
misinformation of customers, unsatisfying statements were given.
Representatives of one bank at first did not understand the possibility to
use computers for automated attacks and argued an attacker had to be
incredible fast and exploit within seven minutes. The statement of another
bank was that they understand the problem but will not stop their
misinformation until a major incident happens.

According to private blogs and discussion forums on several newsportals some
people are already aware of the problem, but no further action was taken to
inform the public. RedTeam wants to raise public awareness not to trust iTAN
as a universal solution against phishing and trojans.

Proof of Concept
================

Lets assume a client (C) has been compromised by either a trojan or a
successful phishing attack, so the attacker (A) is able to read, manipulate
or intercept any data communication with the bank (B). This is known as a so
called "Man-in-the-middle-Attack" (MiM), and is exactly the scenario the
banks claim to prevent with the iTAN system.
Lets see what a communication log would look like in the case of the attacker
having compromised the client using a trojan:

1.  C logs into the online banking website of B.
2.  A reads the login data of C.
3.  C does anything which involves an iTAN.
4.  A intercepts the communication of C with B, and saves the original
    request.
5.  A sends his own, new request to B using the login data acquired in step 2.
6.  B requests an iTAN for this request, sending back an index for an unused
    iTAN. This iTAN is now bound to A's request.
7.  A again intercepts the communication, saving the iTAN index.
8.  A now generates the answering request expected by C, forging it to look
    like it comes from B, including the iTAN index for his own request,
    obtained in the previous step.
9.  C, thinking the request is a valid one originating from B, sends back the
    iTAN corresponding to the iTAN index.
10. A intercepts the communication again, now gaining the valid iTAN for his
    own request.
11. A either forges a server reply indicating a successful transaction with
    the original data or disconnects C from the transaction, e.g. by forging
    a server error from B.
12. A uses the iTAN from step 10 to complete his own transaction.

As already stated, the above steps have to happen in realtime, as the
attacker has to manipulate the communication to get the valid iTAN for his
transaction. But, as mentioned before, this does not make the attack
considerably more difficult for the attacker, as it can happen fully
automated.

Workaround
==========

Clients should be aware that the new iTAN system does neither prevent
phishing attacks nor threats from trojan horses, as stated by the banks. It
only marginally increases the security opposed to the conventional PIN/TAN
system.

Fix
===

If possible, use a more secure system like HBCI with a class 3 reader.

Security Risk
=============

The security risk is medium. The banks are spreading false information about
the security of their new system. This may mislead people into being more
careless than before, thinking that using the iTAN system effectively
prevents any misuse of their data even if their computer is compromised or
their communication is intercepted by phishers. This has to be viewed in the
light of the fact that the banks shifted the risk of misuse from their side
to the customers with the introduction of electronic banking.

History
=======

2005-08-01 Initial awareness of the issue, research started.
2005-08-11 Contacted major german banks and informed them about this issue.
           They understood the problem and promised callbacks within a few
           days after further investigation.
2005-08-25 Did not receive most of the promised callbacks.
2005-08-25 Advisory released.
2005-09-02 CAN/CVE assigned
2009-05-08 Updated Advisory URL

RedTeam
=======

RedTeam is a pentesting group working at the Laboratory for Dependable
Distributed Systems at RWTH-Aachen University. You can find more Information
on the RedTeam Project at http://www.redteam-pentesting.de