No mention of the targetted URL's though.
Security researchers have discovered a tiny, but highly capable banking Trojan. Tinba (Tiny Banker, or otherwise known as Zusy) hooks itself into browsers before stealing banking login information and snaffling network traffic. The malware used injected code and Man in The Browser (MiTB) tricks to change the way banking …
I'm sure CSIS sees the revelation of the hardcoded URLs as giving away proprietary info that gives them an advantage, and thus they'd lose their chance at getting a few panicked users to buy licenses of their product. It'll come out once an independent gets their hands on it.
"BofA does have it. They send you a code via SMS on your cell phone."
Which is annoying if, like me, you have SMS totally switched off (by choice) on your phone. Fortunately, they will also email to you. Of course, they insist upon doing that anytime they don't see their cookie on your machine, which, if you are security conscious and only allow their site to set session cookies, and wipe them after you are done, means every damn time.
"Be careful when doing online banking", that's what this boils down to.
Its this reason why I always use MSIE's "InPrivate" navigation mode when doing stuff like this. This mode turns off /and/ blocks all plugins, history and (temporary) internet data such as cookies is saved in memory /only/ (so close browser, remove history & data) and because of this it also thwarts any tracking outside the current session.
And it does indeed help to use a bank which takes security seriously. Some banks tend to use a static list of numbers which you can use to authorize your transactions, which I personally consider quite stupid. With challenge/response you will at least rule out any extra options for the man in the middle.
My bank generates numbers which I need to process locally with my bankcard and pincode. A device generates a return code based on several aspects like account number, amount of money wired, account number to which money is transferred, etc.
So even if a 'man in the middle' tries to mess with the data by adding extra payments or such it would automatically render my signature invalid thus the whole transaction will fail.
No matter how strong the authentication when a user signs in to online banking, the main defence against such attacks is protection of each transaction, separately, by some means external to (i.e. independent of) the device on which the browser is running.
As others have noted, some card issuers provide card readers which, in conjunction with the user's debit card, generates one-time codes can be used both for strong authentication and (by entering transaction details) for digitally signing each transaction. Since the card reader is independent of the device on which the browser is running and isolated from e.g. the internet, this arrangement is far more difficult to subvert.
The real question is why don't all card issuers provide such devices? And why are they not used for securing other internet transactions?
no. My browser wont be. Its got root write privileges only and cannot be patched by a user process, even if that user process knows that it was compiled from source and running on Linux.
This is a windows specific trojan that relies on the fact that firefox etc and users have the complete ability to write and modify anything in the windows systems folders.
My bank uses 2-factor (card+card reader) authentication, and I generally feel pretty safe when using it. This is only available for internet banking though; when I use a credit card to buy stuff, I don't get the same protection.
Isn't it time credit card companies started doing the same thing as banks? Would be a hell of a lot better than MasterCard SecureCode or whatever, which as a previous poster has mentioned would simply be seen as 2 passwords to a MiM attack.
ET because sometimes Mastercard and Visa seem to be on a different planet...
Biting the hand that feeds IT © 1998–2021