+49 241 510081-0
kontakt@redteam-pentesting.de
DE
DE

Contact

Contact us

+49 241 510081-0
kontakt@redteam-pentesting.de
Contact form
RedTeam Pentesting HeaderRedTeam Pentesting HeaderRedTeam Pentesting HeaderRedTeam Pentesting HeaderRedTeam Pentesting HeaderRedTeam Pentesting HeaderRedTeam Pentesting HeaderRedTeam Pentesting Header
newer
back to overview
older

Text Version

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: https://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 https://www.redteam-pentesting.de.