The attack described is an example of a “man in the middle” (MITM) attack. The user thinks the details that he types are transmitted direct to his bank, but the MITM alters those details to suit himself before forwarding the modified details to the bank. Information that is transmitted from the bank is likewise intercepted before it appears on the user’s screen, and duly modified so that he is none the wiser that his instructions have been tampered with. Because traffic is encrypted between the user’s computer (or smart phone or whatever) and the bank, the only practical place for the MITM to sit is at the bank itself or within the user’s browser; it is the latter scenario, dubbed “man in the browser” (MitB) that is the subject of the BBC article. By some means, the user will have been duped into downloading malware that will perform the interceptions within his browser.
In the absence of a card reader device, the malware can hijack the user’s banking session and perform transactions (such as setting up a new payee and making a large payment to it) at will. No involvement from the user is required at all, beyond supplying his username and password to login to the banking service. If the bank only requires use of a card reader device to login, then the MitB’s task is scarcely more difficult. However, if the device is used to authenticate the most sensitive transactions, such as setting up a new payee or making a large payment, the MitB can be completely defeated. To understand how, we’ll go through what a device (in this case the Barclays PINsentry) does.
- The user is instructed to insert the chip-and-PIN card associated with the account into the reader.
- The reader instructs the user to enter his PIN, which is checked by the card.
- For every use, the bank can issue a challenge. This is a number of up to 8 digits, which the bank can determine at will for each transaction.
- The user types the challenge into the reader, which transmits it to the card. The card (if and only if it has previously verified the PIN) will produce a passcode that is an encrypted version of the challenge (and of additional information to identify the card and ensure that passcodes are different (and thus cannot be replayed) even if the challenge is the same).
- The user types the passcode into a field on the web page for transmission to the bank.
- The bank verifies that the passcode could only have originated from the card associated with the account, that the card has been given the correct PIN and challenge, and that the passcode has been produced in the correct sequence for that card.
Even used in a straightforward way, this complicates the task of the MitB. For example, he cannot just insert a transaction to set up a new payee at will during a session. He has to wait until the user wants to set up a new payee and then must change the details (on the way out and the way back). To defeat the attack completely, the challenge must be a function of the transaction details. For example, in the case of setting up a payee, it should be the payee’s account number. For a payment, it should be the amount in pence of the transaction. Provided the user is educated that challenges will always take those forms, there is nothing that a MitB can do for his own gain. For example, he will substitute his own account details when the user sets up a new payee. He will modify the screen instructing the user to enter a challenge to contain his own account number. But the on-the-ball user will recognise that it bears no relation to the account he was trying to set up, and raise the alarm.
To conclude:
- MitB attacks are a real threat to sites that do not use devices such the PINsentry;
- MitB attacks are much harder if these devices are used to authenticate individual transactions;
- For maximum protection, banks must adopt a consistent policy for linking challenges to transaction details, and ensure that users are educated as to the nature of the challenge for each type of transaction.
These are personal opinions and should not be misunderstood as representing the opinions of
Consult Hyperion or any of its clients or suppliers