Malware for Online Banking Services?

So what if you have implemented 2-factored authentication for your online banking services?

Recent developments in malware highlighted that it is extremely hard to protect online banking services from malware. Although I still advocate that online banking users have to play their part not to download suspicious software, visit dubious websites and click on that interesting url link in their e-mails, coverted social engineering techniques are there to fool even the most seasonal experts. Malware has evolved a lot in the last 20 years, human beings have not.

There are 3 new trojan variants that recently made the news:

• The trojan OddJob can hijack a user's online banking session in real-time by stealing session ID tokens from infected desktops, and is able to keep the session alive even after user thinks that he/she has logged off.

• The trojan ZeuS can inject codes into a legitimate webpage and tricked the user to enter his/her mobile phone number and model of phone. This information is forwarded to a rogue site that will install a mobile application that intercepts SMSes and forwards messages to another number controlled by the attackers. The Zeus mobile component will work on some Symbian and BlackBerry devices. Once this setup is successful.

• Recently, it was reported that ZeuS and SpyEye have apparently joined forces, and the author of the SpyEye trojan is working hard to develop a new merged variant that may up the ante on man-in-the-middle attacks for online banking services. Latest news suggested that the ZeuS source code is for sale, at an estimated US$100,000.

How would 2FA and OTP implementation help against malware induced man-in-the-middle attacks? Besides 2FA, MAS has required Singapore-based banks to implemented a follow-on OTP for every change in transfer details and to authorise a transaction. Traditionally, the follow-on OTP is a simple one-time password generated from the 2FA token or from SMS. However, it does not stop the trojan from changing the payee account within the same authorised transaction.

The latest incarnation is a challenge-response implementation that requires part of the payee account number (e.g. last X numbers) to be entered in the token to generate a unique security code. This security code is then entered into the transaction webpage to authorise the transaction. If the payee account is changed by the trojan, the authorisation will not matched.