Message-ID: <20050825120435.GC4544@rwth-aachen.de>
Date: Thu Aug 25 14:17:50 2005
From: release at redteam-pentesting.de (release@...team-pentesting.de)
Subject: Advisory: iTAN not as secure as claimed

Advisory: 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.txt
Advisory-Status: public

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.

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

-- 
BOFH excuse #434:

Please state the nature of the technical emergency
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.grok.org.uk/pipermail/full-disclosure/attachments/20050825/0e17a9bb/attachment.bin

Powered by blists - more mailing lists