Many online business transactions are vulnerable to a man-in-the-browser attack even though the technology currently used for personal transactions could be used to defend against them.
As part of securing online bank transactions, many banks have adopted a second factor of security, usually in the form of a numerical code provided by a token or in an SMS sent to the customer's mobile phone.
However, according to SafeNet Australia and New Zealand regional manager, Vince Lee, authentication doesn't completely protect customers from attacks.
"Someone can be strongly authenticated with the bank, but if their browser is infected with malware, then they will be susceptible to a man-in-the-browser attack," Lee said.
A man-in-the-browser (MitB) attack revolves around the presence of malware in the browser, whether this be from a malicious plug-in, extension or script, which can modify pages and transactions without the user knowing. This ability can fool a user into believing they are sending an amount of money to a legitimate recipient, but what the malware is actually doing is sending money elsewhere.
"Man in the browser is a sophisticated type of attack, but we are seeing evidence of [more] in the market," Lee said.
Combating the threat involves verifying the transaction outside of the browser. This could include a phone call from the bank verifying that the customer did intend to send large sums of money overseas. Most banks are already doing this for personal accounts by sending customers SMS messages with details of transactions (such as amount and account name), but token-based authentication schemes normally thought to be more secure and reserved for business customers, are more vulnerable to an MitB attack since they don't allow customers to verify actual transaction details outside of the browser.
NAB is one of the banks offering SMS security, providing transaction details along with the security code as a second factor of authentication, allowing customers to verify the transaction amount and the recipient. An SMS is sent after a user-definable daily limit is exceeded and allows customers to verify every transaction made or none at all. NAB sets the default limit at $300 per day.
Yet NAB's process for verifying business transactions is different. In order to verify the account a transaction is heading to or the amount it is for, the verification process is displayed in the browser, so it can be manipulated by malware. The tokens themselves only provide a one-time code and not any information about the transaction.
Westpac's SMS feature for personal accounts includes transaction details and a security code, which is sent only for certain transactions such as paying a new payee, making overseas payments or increasing daily limits.
Its token-based process for business customers, however, fails to provide users with any information about the transaction they are approving.
The Commonwealth Bank provides personal account holders with verification by sending details of the transaction in its NetCode SMS. One drawback is that it only sends this information for transactions that are considered high risk, with no option to force verification on all transactions. High risk transactions include adding or changing accounts and billers, transferring money using international money transfers, or accessing customer contact details.
In addition, users that have opted out of NetCode and instead adopt the bank's physical token alternative will be vulnerable to an MitB attack as they are unaware of whether the transactions they are authorising is legitimate.
The bank has given MitB attacks some consideration by offering a NetLock USB device for corporate CommBiz online banking customers. It contains a hardened version of Mozilla Firefox as a precaution against these types of attacks.
ANZ is the only member of the four big banks that doesn't provide a form of SMS security or two-factor authentication for its personal account holders. Only corporate customers have two-factor authentication and these token-based security devices do not provide any details of the transaction taking place.
SafeNet attempts to solve both problems of two-factor authentication and transaction verification with its own token. At the time of a transaction, the details are encrypted with a key from the bank and converted into a blinking black-and-white image. The token's optical reader then takes the signal, decrypts it using the key it shares with the bank and displays the actual transaction value on the token itself.
With most banks having already implemented a form of two-factor authentication, there has been increased interest in creating a "soft" token that is created through a mobile app. Lee said that although mobile devices could be used to provide both two-factor authentication and transaction verification, since their built-in cameras could be used as an optical reader, he highlighted the problem that exists with this implementation.
"If you're doing internet banking on your phone, or your iPhone or something like that, it would be difficult to use the camera in that sense, but the optical token you could put up to the screen and read the transaction."
Even SMS verification results in customers running into the problem of not being able to securely use that device for mobile banking since the code would be sent to the same device. Recognising this security risk, some banks such as the Commonwealth Bank have disabled certain transactions such as creating new payees, while on mobile platforms.
Instead of making the mobile device a factor of security, Lee argued that the token should be kept separate from the mobile device since the token doesn't discriminate against what device is being used to conduct mobile banking.
"It doesn't matter what the screen is. The screen could be your computer screen, or it could be a screen on your iPad."