Online Banking Trojan waiting to vacuum up your account!

probe

An online banking trojan is going around that does a man in the middle attack to capture online bank login information and clean out one’s bank account. Unnamed Irish banks are on the list of vulnerable entities. This bright little trojan calls home for updates regularly, to stay ahead of the game. Yet another reason, if it was needed, for multi-factor authentication.

Quote from Podcast transcript:

Steve: Okay. Second amazing story of the week.
Leo: Okay.
Steve: This is also frightening. I mean, this is - what I'm about to read is horrifying and true. It was posted by a blog at Symantec, describing an amazing trojan known as Silent Banker. What's really fun about this, too, is that - I'm going to read the blog entry. It touches on so many things that we have already talked about. So, I mean, this is a little bit of a walk in the park for our listeners. But the blog entry was titled "Banking in Silence."
Targeting over 400 banks, including my own, writes this blogger, this Symantec blogger, and having the ability to circumvent two-factor authentication, are just two of the features that push the Silent Banker trojan into the limelight. The scale and sophistication of this emerging banking trojan is worrying, even for someone who sees banking trojans on a daily basis. This trojan downloads a configuration file that contains the domain names of over 400 banks. Not only are the usual large American banks targeted, but banks in many other countries are also targeted, including France, Spain, Ireland, the U.K., Finland, Turkey, and the list goes on.
The ability of this trojan to perform man-in-the-middle attacks on valid transactions is what is most worrying. The trojan can intercept transactions that require two-factor authentication. It can then silently change the user-entered destination bank account details to the attacker's account details instead. Of course the trojan ensures that the user does not notice this change by presenting the user with the details they expect to see while all the time sending the bank the attacker's details instead. Since the user doesn't notice anything wrong with the transaction, they will enter the second authentication password, in effect handing over their money to the attackers. The trojan intercepts all of this traffic before it is encrypted. So even if the transaction takes place over SSL, and of course we know we certainly hope it would, the attack is still valid.
Unfortunately, we were unable to reproduce exactly such a transaction in the lab. However, through analysis of the trojan's code, it can be seen that this feature is available to the attackers. The trojan does not use this attack vector for all banks, however. It only uses this route when an easier route is not available. If a transaction can occur at the targeted bank using just a username and password, then the trojan will take that information. If a certificate is also required, the trojan can steal that, too. If cookies are required, the trojan steals those, as well. In fact, even if the attacker is missing a piece of information to conduct a transaction, extra HTML is added to the page to ask the user for that additional information.
And he shows two screenshots here. I made a shortcut for this blog entry because it's really worth looking at for our listeners. It's just SnipURL.com/sn130. That's the episode number of Security Now!. So anyone can put SnipURL.com/sn130, and they'll get this blog posting.
He goes on to say, when instructed, the trojan can also redirect users to an attacked-controlled server instead of the real bank in order to perform a classic man-in-the-middle attack. Currently there's only one bank targeted in this way. However, recent updates to the trojan - oh, and get this. It gets constant updates using updated software. He says...
Leo: If it's working, why not?
Steve: Yes. Recent updates to the trojan change the user's DNS settings, which we were talking about just recently a couple weeks ago, change the user's DNS settings to point to an attacker-controlled DNS server. Using this technique, the trojan can start redirecting any site to an attacker's site at any time. This feature could also mean that, if the trojan is removed, but the DNS settings are left unchanged, then the user will still be at risk. See below for the attackers' DNS server addresses.
Add to all of the above the ability to steal FTP, POP, webmail, protected storage, and cached passwords, and then we start to see the capabilities of this trojan. But it doesn't stop there. Don't forget the porn. The trojan also contains over 600 pornographic website URLs that can be shown to the Internet user so that the attacker can make money from the referrals. Lastly, the trojan can also download updates, which it regularly does. It can also upload other executables and can use the infected image as a proxy or as a web server on any chosen port. In tests, the HTTP port used was 18102. The multiple configuration files that the trojan downloads are updated several times per day, so it's more current than Windows is.
Leo: More current than anything.
Steve: Yeah.
Leo: More current than Norton Antivirus.
Steve: And currently the trojan is capable of injecting HTML into about 200 different URLs, meaning that, as a web page is being displayed by the user's browser - and this thing knows about both Internet Explorer and Firefox - as the web page is being displayed, the trojan is able to intercept that communication and insert its own modifications, its own HTML, into the page. He says, the configuration files are compressed and encrypted. However, after decrypting them we can see how the trojan works in detail. And then he goes on into some additional details, which many of our listeners may find interesting.
Anyway, I mean, this is a beautiful posting because it gives you a sense for just how sophisticated trojan technology is becoming. And, I mean, how much effort people are willing to go to for this kind of high-value attack.
Leo: Well, it also introduced to me a new category. I never heard the phrase "banking trojan." But obviously these are trojans aimed at corrupting your Internet banking experience; right?
Steve: Exactly. So you're right. There is now a classification of trojans, a set of trojans, of which this is perhaps - and this guy, from everything he's seen - is the most sophisticated one of all. And for, well, for one reason. It's not like it's one trojan for one particular bank. And so you're - how many - what's the chance that the infected user is going to...
Leo: 400 banks.
Steve: Yes. And it's got specific scripting technology in order to deal with each one on a bank-by-bank basis.
Leo: So just to understand, it would get on your computer as an end-user, and it would intercept information about your banking login, basically.
Steve: Correct. Essentially you really don't want this trojan on your machine if you're someone who does online banking.
Leo: And he mentions it's all over the world. I mean, it's not just U.S. banks, it's banks all over the world.
Steve: Right.
Leo: Wow. So, something to be aware of. You know, banks, I think, routinely cover up these kinds of losses. But this is a loss to you. This wouldn't be a loss to the bank, exactly.
Steve: Right. Exactly. You might very well go to check your balance and find that it has been zeroed. Because this thing watched you log in once. And, I mean, might right then have executed a funds transfer. If not, it knows how to - it's able to send this back to headquarters, and then somebody else can log in as you, even if, as this thing, I mean, this thing is so comprehensive that whatever authentication data is necessary - it understands, for example, you know, grabbing cookie details. So somebody could literally pretend to be you, even if you had static cookies on your machine to identify you. And, for example, we've talked about how authentication strength is reduced in instances where you do have a cookie because you've already authenticated your machine to the bank once before. And so it says, oh, well, you know, here's a cookie we recognize. We'll only ask for the username and password and not, you know, which kitten the guy, you know, has chosen in the past.

Full podcast at: http://www.podtrac.com/pts/redirect.mp3/aolradio.podcast.aol.com/sn/SN-130.mp3

http://www.symantec.com/enterprise/security_response/weblog/2008/01/banking_in_silence.html

.probe

Martyr

hybris by 'vecna' was a worm that was able to update itself - it appeared over 8 years ago.
it used an RSA library to sign/verify updates so that it couldn't be terminated easily or hijacked by someone else.

it used DLL plugins to run exploit code so it could infect machines remotely.
i don't believe that modifiying DNS settings is anything new either..there was spyware with this behaviour appearing 2 years ago.

overall, this stuff that symantec (who else) keep squeezing into the minds of people consciously isn't really anything that we haven't seen before - symantec employees are certainly no strangers to it.

i'm not attacking your post btw probe.

they're in business to detect malicious software, and if that were not a good enough reason to write advanced software like this to keep themselves in business, then i don't know what is.

probe

Average Joe wrote: »

hybris by 'vecna' was a worm that was able to update itself - it appeared over 8 years ago.
it used an RSA library to sign/verify updates so that it couldn't be terminated easily or hijacked by someone else.

it used DLL plugins to run exploit code so it could infect machines remotely.
i don't believe that modifiying DNS settings is anything new either..there was spyware with this behaviour appearing 2 years ago.

overall, this stuff that symantec (who else) keep squeezing into the minds of people consciously isn't really anything that we haven't seen before - symantec employees are certainly no strangers to it.

i'm not attacking your post btw probe.

they're in business to detect malicious software, and if that were not a good enough reason to write advanced software like this to keep themselves in business, then i don't know what is.

While the idea behind the worm could have been around for nearly a decade, neither its age nor the motivations of companies such as Symantec are really relevant to the core issue – which is the need for multi-factor authentication for systems operated by financial institutions. There are millions of moron customers out there who haven’t a clue about personal computer security. It is not taught in most schools, and anti-virus software may or may not stop a malicious hacking attempt of this nature.

The real solution is for the banks to be required to take the necessary measures to make their login and authentication system bulletproof. The fact that banks are getting away without having to implement MFA is a reflection on the poor system of bank regulation in place. The regulators are too worried about creating more bureaucracy and ratios and “compliance” (as they see it) – and seem to be closing their eyes on the risks posed by badly engineered information systems.

In the example at http://www.symantec.com/enterprise/security_response/weblog/2008/01/banking_in_silence.html not only are they capturing the bank login – but they are getting the person’s NIF (ie the Spanish police state’s ID numbering system for tracking its “subjects”). Hotel online reservations systems even demand the NIF - so the public are brainwashed to hand it over at the drop of a hat.

In the absence of a continuously changing third factor in the login, they can get into the bank account and probably get other information such as the victim’s name and address and other data to facilitate identity theft – as well as doing a bank account clean out on the spot.

.probe

Martyr

While the idea behind the worm could have been around for nearly a decade, neither its age nor the motivations of companies such as Symantec are really relevant to the core issue

if they're really that concerned about consumers losing their online banking details, would they not develop something over 10 years to prevent it?

i know the answer to that one.. :rolleyes:

which is the need for multi-factor authentication for systems operated by financial institutions.

its fair point, but i suspect that any increase in complexity would probably leave coked-up bankers calling their helpdesks to get logged in..probably not good for business.

There are millions of moron customers out there who haven’t a clue about personal computer security.

there are plenty of "professionals" too. *cough*rits*cough*
i would argue that most people are just not informed, or badly informed by the media...and pr0f3ss1onals like Mr Flynn!

The real solution is for the banks to be required to take the necessary measures to make their login and authentication system bulletproof.

lets say you're given the job of implementng MFA for an online bank, what would you suggest? or can you give the name ofbank who has successfully used MFA?

probe

Average Joe wrote: »

if they're really that concerned about consumers losing their online banking details, would they not develop something over 10 years to prevent it?

i know the answer to that one..

Time is moving on, people are getting more sophisticated and computer crime is on the increase. Eg. SocGen’s EUR 7 billion write off – for which I would blame SocGen management rather than Kerviel.

its fair point, but i suspect that any increase in complexity would probably leave coked-up bankers calling their helpdesks to get logged in..probably not good for business.

It seems to work where it is installed. I haven’t come across any stories of MFA users locked out of their systems – have you?

lets say you're given the job of implementng MFA for an online bank, what would you suggest? or can you give the name ofbank who has successfully used MFA?

RSA SecureID (I’m not connected with RSA in any way)
http://www.rsa.com/node.aspx?id=1156

As far as I know RaboBank use MFA in Ireland. But of course they are regulated by http://www.dnb.nl/dnb/home?lang=en (rather than the Central Bank) and RaboBank has an AAA rating. SocGen is rated AA-.

And I'd have it running on all key systems within the bank - not just for their web based activities.

Paypal offer a similar product: https://www.paypal.com/securitykey


.probe

Martyr

Time is moving on, people are getting more sophisticated and computer crime is on the increase. Eg. SocGen’s EUR 7 billion write off – for which I would blame SocGen management rather than Kerviel.

agreed

It seems to work where it is installed. I haven’t come across any stories of MFA users locked out of their systems – have you?

as you mentioned RSA SecureID - no, not really, just some losing/misplacing their tokens, which would need reporting, but thats probably minor detail.
it would be better to use these tokens, i agree, but still don't think its bulletproof.

don't know anything about paypals securitykey, but guessing its good, maybe better than secureid?

probe

Average Joe wrote: »

agreed



as you mentioned RSA SecureID - no, not really, just some losing/misplacing their tokens, which would need reporting, but thats probably minor detail.
it would be better to use these tokens, i agree, but still don't think its bulletproof.

don't know anything about paypals securitykey, but guessing its good, maybe better than secureid?

Loss/misplacement of a token is no problem. You find a token in the street or steal it out of my pocket - you haven't a clue of my userID or password or what service it relates to. It is totally anonymous - and used in all sorts of applications - banking, corporate email, corporate networks, web access, building security systems, etc.

You have to know the number displayed by the token which changes every 60 seconds or so, AND the user ID, AND the password AND the URL for the system it relates to AND if it is internal to a bank system you have to be able to get through the front door, past security, in the elevator, know where to go, get past their retina/finger print id checker, enter the correct pin to open the door, and which terminal you can log on to, which application you can use it with. A system might also have IP address ranges from which it will only allow access with the token.

A total needle in the haystack for a token thief.

Stop **ssing in the wind!

.probe

Martyr

Loss/misplacement of a token is no problem.

in what context? .. if i lose my token, i shouldn't report it to anyone?

You find a token in the street or steal it out of my pocket - you haven't a clue of my userID or password or what service it relates to. It is totally anonymous

another assumption .. what if its your co-worker that steals it? and had a key logger stored on your system at work..which you just happen to use for online banking..is that not a problem?

You have to know the number displayed by the token which changes every 60 seconds or so, AND the user ID, AND the password AND the URL for the system it relates to.

well..if the co-worker has keylogs, he already has all this information, all thats left to do is steal the key fob, and make a transfer - gone in 60 seconds :P

if it is internal to a bank system you have to be able to get through the front door, past security, in the elevator, know where to go, get past their retina/finger print id checker, enter the correct pin to open the door, and which terminal you can log on to, which application you can use it with. A system might also have IP address ranges from which it will only allow access with the token.

all this really defeats the purpose of banking online, probe.
why need a key fob, if you just walk into the bank?

imho, secureid is good security measure, but its by no means bulletproof.

numbnuts

This sort of info dont help comin from Banks..???

Bet they not the only bank to offer this info if you look in to it ..

Big Italian bank says "Google your password to see if it's good"
Err... a big Italian bank, Fineco, gives these instructions for creating a password.
It’s in Italian, but Francesco here did some translation:


http://online.fineco.it/public/scopri/consiglisicurezza.asp

"to verify the security of a password, it is sufficient to put it in any search engine (such as Google):
if it returns less than 10 results, it means it is a good password"

And then they have examples of how many search results should determine a good password!

pippo = 767,000 -> very bad password
05Fineco = 30 -> good password
F1n3co = nessuno -> excellent
See for yourself. A machine translation to English of the site is here.

http://www.google.com/translate?u=http%3A%2F%2Fonline.fineco.it%2Fpublic%2Fscopri%2Fconsiglisicurezza.asp&langpair=it%7Cen&hl=en&ie=UTF8

This is just beyond nutty.

Paddy...

probe

Average Joe wrote: »

in what context? .. if i lose my token, i shouldn't report it to anyone?

You will report it, because you’ll want to get a replacement token to continue to have access to the system in question.

another assumption .. what if its your co-worker that steals it? and had a key logger stored on your system at work..which you just happen to use for online banking..is that not a problem?

People generally keep these tokens on their keyrings. I wouldn’t leave my car or home keys around the office for a co-worker to steal. So what if they do manage to steal the token. And they manage to install a keylogger on a corporate PC! You come in to work some morning and either there is a new keyboard in place for no reason or they have installed a hardware device on the keyboard cable that you don’t notice or they manage to install key logging software on a corporate PC. All very unlikely scenarios. But let’s say that they do manage to steal your token unknown to you (something you’ll need when you need to log-in – so you’ll miss it fairly quickly) and report the loss. They won’t get away with doing a SocGen style Kerviel job over any length of time. Unless you and the IT people and all the management above them have some heavy drug dependency!

Look at the real-world practicalities of trying to defeat MFA. You can easily add a fingerprint verification as a fourth factor if you are totally paranoid.

And if you work on serious, serious, serious stuff, they can add a retina scan as a fifth factor. Not to mention the option of involving other parties having to sign off on transactions over a given amount.

You can make multi-factor authentication as bullet proof as the application demands.

.probe

probe

numbnuts wrote: »

This sort of info dont help comin from Banks..???

Bet they not the only bank to offer this info if you look in to it ..




Paddy...

There is a good password generator at
https://www.grc.com/passwords.htm

It is on a secure connection (though using only a 1,024 bit key - most security conscious financial institutions and corporates are moving to 2,048 bit keys).

You can take chunks of the password offered - or use the entire thing. Ideal for setting up WPA for WiFi.

Put [FONT=courier new,courier]>*`^j93[6'ATA$0VOouFb3,&5R?d"sU<szx5f+-&g@~r0%~%.^68j:EECEr9P2.[/FONT]
into google!

.probe

Martyr

People generally keep these tokens on their keyrings. I wouldn’t leave my car or home keys around the office for a co-worker to steal.

good for you, doesn't mean everyone else does the same.
actually, lets say somebody did leave their key fob lying around, and you just replace it..by the time the victim has figured out its not working and called in to the bank, a transfer could already have been made..

So what if they do manage to steal the token. And they manage to install a keylogger on a corporate PC! You come in to work some morning and either there is a new keyboard in place for no reason or they have installed a hardware device on the keyboard cable that you don’t notice or they manage to install key logging software on a corporate PC. All very unlikely scenarios.

unlikely scenarios? ..well gee, i hope you don't work in security, probe because you assume far too much.

You can easily add a fingerprint verification as a fourth factor if you are totally paranoid.

easily? - so then everyone who wants to bank online must do so from a PC with fingerprint verification..how common is that? how many of your friends/family that bank online have hardware capable of this?

we are still talking about banking online, yes?

lets say the login goes:

* Enter Acc. # / Customer ID (or selected randomly)
* Enter PIN / password + RSA Secure ID
* Fingerprint scan

most hardware needs to have software, right?
so for the fingerprint verification it reads the data from the hardware.

if the attacker is skilled enough, he could just record the valid data and emulate a response to the O/S or application that retrieves the scan.

but of course, we could add more factors to the login, and really make it impossible for even the customer to login!

probe

Average Joe wrote: »

good for you, doesn't mean everyone else does the same.....

Look at it like this. If I was BillG I'd be happy for my bank to process a transaction of say up to $1 billion with my login, password and SecureID type of thing.

Where larger transactions are concerned, (like the settlement for a $50 billion bid for Yahoo!) I'd probably prefer to go over to the AIB in Millstreet or the BoI in Letterkenny and shake hands with the bank manager I knew well before the payment went through. But that's probe - he doesn't trust other people with his biometric data. As I have said before, the idea of replacement eye transplants, new fingers and plastic surgery doesn't appeal, if there is a risk that my personal data gets into wrong hands. However if one is comfortable with one's biometric data going here, there and everywhere, five factor + is pretty bullet proof.

It's down to materiality of transaction size, convenience and trust in a system.

.probe

cormie

Anyone care to save me reading all the above and just letting me know if it's safe to log into AIB online banking please?

Martyr

this is quote from 2001'ish by mudge from l0pht.

Pieter Zatko wrote:

It seems that SecurID was a valid tool when it first was introduced but is now suffering
in security areas as the world has evolved around it. The card does up the level of
attacks necessary but does not seem to offer the security that one might expect it to. In
the world of computer and network security some of the biggest vulnerabilities occur
when there is a false sense of security. Particular concern is felt for large corporations
that rely solely upon this method for ‘secure access’. The race attacks based upon fixed
length responses, denial of service attacks, separating the master and slave servers and
the sdshell bug have all been witnessed. The weakness based upon understanding the f2
hash has not been witnessed to the best of my knowledge. However, if there is a problem
there, it is only a matter of time before it is exploited. Reverse engineering the f2
hash should not be difficult for anyone with a copy of the sdshell binary and a common
debugger. This paper is meant to inspire customers, consumers, and hackers alike to
Weaknesses in SecurID 11
question companies when they claim their product is secure and that there are no vulnerabilities
in it - even more so when the security is based upon proprietary software algorithms.

put it like this probe, there are people out there alot smarter than you give them credit.
never assume anything.

cormie wrote:

Anyone care to save me reading all the above and just letting me know if it's safe to log into AIB online banking please?

i don't know, all depends on situation, system you're using to login to the banks remote server.

if someone skilled really wanted your online banking details bad enough, and they had any kind of access to electronic devices that you used to bank online, or they were able to dupe you into to revealing them,either way, they would get them eventually..IMHO, its no problem.

and it doesn't really matter how many factors you add into the authentication process, if it has to be stored/processed and sent to the banks remote server electronically, if the attacker can access it in some way, chances are he can just use replay the information to the server when he needs to.

you can't really expect "unlikely scenarios" - you should really expect anything to happen..for example what if a bank employee turns bad and starts accessing the secureid token values on the banks server? - but of course, that could never happen, right?

we could discuss all day the merits of fingerprint,retina scans..etc, its pretty much useless if an attacker can control the system where the authentication takes place.

probe assumes that this is an unlikely scenario, which is pretty naive - sorry probe.

IMHO you can only make a system more difficult to attack, not bulletproof or impossible to break.

probe

Average Joe wrote: »

and it doesn't really matter how many factors you add into the authentication process, if it has to be stored/processed and sent to the banks remote server electronically, if the attacker can access it in some way, chances are he can just use replay the information to the server when he needs to.

you can't really expect "unlikely scenarios" - you should really expect anything to happen..for example what if a bank employee turns bad and starts accessing the secureid token values on the banks server?

These values are not stored on the bank's server (using the RSA Secure ID system).

1. Client issued with RSA token, controlled by RSA.
2. Client logs in with user ID, password and RSA security number.
3. Bank computer sends RSA security number to RSA - together with token ID for authentication.
4. RSA confirms authenticity or otherwise back to bank computer causing access to be allowed or blocked.
5. RSA doesn't know who client is - all they need is the token number and the code entered by the client.
6. The code displayed on the token changes every minute. If the clock on the token goes out of sync with the clock back at RSA, the RSA system checks the previous and next valid code and adjusts its clock time tracker for that token accordingly.

An organisation could use similar offsite verification and storage procedures to other factors to reduce the risk of any one person being able to compromise the system.

.probe

probe

cormie wrote: »

Anyone care to save me reading all the above and just letting me know if it's safe to log into AIB online banking please?

While I can’t comment on AIB’s security arrangements, one has to take a pragmatic view of the risks.

Don’t visit your bank account from an internet café or hotel or airport lounge or any other type of public internet access facility – there is probably a 50% chance that it will have a keyboard logger. Even a family computer – all it takes is a spam email to have an attachment opened, or an unpatched browser vulnerability exploit – done perhaps via the carelessness or ignorance another family member several years ago – to install keyboard logger which will keep working until the hard drive is fully reformatted and the system re-installed from original software media (not a restore of a backup).

The biggest risk is with banks that allow ebanking payments to any account – where you can enter the account details when entering a payment transaction. If epayments can only be made to an account appearing on a list of pre-approved payees, the risks are greatly reduced. It also helps if a weekly or monthly limit is put to the total epayment debits to put a cap on one’s exposure.

There have been cases in GB of stolen credit cards and e-banking happening together where the thief dipped into the victim’s mortgage account, transferred funds to the current account and from there to the card account to take about €30,000 equivalent from an account via credit card transactions over a short period! So in extreme circumstances like this, allowing online transfers between your own accounts could be dangerous….

.probe