Major Bank On-line Security Problem?

You've probably already tried this, but it's worth checking anyway. Have you, or has he checked his hosts and lmhosts files?

As the problem is reproducable on his system, but not on every computer that accesses the banks site, it suggests that the problem is definitely on his computer somewhere.

The Hosts files are usually to be cound in C:\windows\system32\drivers\etc These files define where selected domains and IP addresses are redirected to. Changing these files won't flag anything up on an antivirus sweep. They need to be checked manually.

Reallistically speaking, these files only need one line in them....

127.0.0.1 localhost

Anything other than that could potentially be causing the problem. Just reset the file to read "127.0.0.1 localhost" and check to see if the problem persists.

I have not checked it - I was not aware that it could be that in this context - I will ask him if the Bank asked him to check

I would suggest that "the problem" could be on the ISP's DNS server at the point where he joins their network - and that it does need particular circumstances to trigger it - which may be peculiar to his (and some other) machine(s).

I do not think that the bank would have spent time on trying to resolve an issue on a customer's machine - certainly not all day - and saying do this, send us that, what does that say now, look for this and that if they did not think that it was a more serious problem - and not juts his machine. They would have washed their hands of it and told him to get his PC seen to by an expert!!

Are you saying that if you type in a url to the browser - then you can be redirected to a different url - but that which you type in will appear in the browser address bar.

Would a problem like this effect Firefox as well? - you seem to imply it is more of a configuration problem than anything nasty.

I have never heard of that before - are you sure? (I must admit I do doubt it).

I will have a look for info on this myself - but any pointer to relevant information would be appreciated

(If that is what it is then I would have hoped that the Bank's technical department would be aware of it)

Normally a computer will access a DNS server to find the IP address of a URL. You can however override that by entering the URL and desired IP address in the "hosts" file on your PC. This will cause *all* programs to skip looking up the IP address by accessing a DNS server, and instead using the IP address manually entered in the "hosts" file. That file will normally contain only one entry - the URL "local" is tied to IP address 127.0.0.1

There are legitimate reasons for having URLs in your "hosts" file. Maybe you run a server on your computer, for example, which people can access via your external IP address which you have registered with a DNS server. You would configure your router to direct packets of the appropriate protocol coming into that address to the *local* IP address of your PC. But any PC that is on your local network will not be able to access your server via the external address, but needs to use the local address instead, which the DNS server does not know. So you put the URL and local address of your server into all "hosts" files of computers on your local network, and it will all work fine.

Or you might want to be able to access other PCs on your network by name instead of their IP address, so you associate names with their IP addresses in your "hosts" file. My router, for example, is associated in my hosts file with the URL "router". So I can access it by putting the word "router" into the browser bar or telnet session and do not need to remember its IP address.

Malicious programs exploit the "hosts" file by putting in entries for the URL they want to hijack (banks, anti-virus sites etc) and associating it with the IP address of their spoofing server, or (in the case of antivirus sites) an IP address that will not work, so any access to the antivirus site will be met with a connection error.

The easiest way to prevent such an attack is to make the "hosts" file read-only.

This could be teh case, I agree. But I would have thought a lot more people wouldbe reporting the issue if it was anything to do with the ISP's DNS routing. I'm still fairly confident that this sounds like the hosts file - although I'm not being closed minded about it.

They may not even be aware of this as an option. The chaps in the callcentre might be working to a formulaic checklist of flowchart.

That would edepend on what has been set up on the server that the hosts file has redirected you to. But if the malicious coder is a switched-on cookie, then it's entirely possible.

Yes.

In my experiences, the symptoms of a viral infection often turn out to be configuration problems. However, in this case, I'm not suggesting it's a configuration problem. For the Hosts file to have become altered so that it redirects the banks domain to a malicious site, someone must have made a conscious effort to do that. So it would appear that someone has either accessed his system, or managaed to remotely execute some code on his computer. Either way, it's a security breach. Not necessarily his fault, but worth being aware of so precautions can be taken in future.

I'm still putting my money on this being the answer.

In my experience, telephone help desks and tech departments for big companies just work of a cheklist or flowchart. If condition A is met then proceed to B If condition B is met then proceed to C Present them with something that's not on their checklist and they flounder.

Try googling for 'hosts' file. There are lots of entries for it.

excellent - good explanation - thanks

Thanks for comments:

as you will have seen Cynic has also given me a good explanation of hosts.

It was not actually the call centre who I spoke with - it was some levels removed - and I did have a sensible conversation with the guy.

I could imagine something in the DNS which every 1000 requests for a particular bank pushes it to phishing site - and then sits quiet again

- it could be very difficult to find.

The most worrying aspect I thought was that the actual URL as typed in appeared in the browser - and then the phishing site had the "correct" url in the browser.

He has installed Firefox - and the problem has disappeared!!

All of the stuff which the bank asked him to run found nothing.

All cookies seemed to be OK.

Will be interesting to see what turns up when he checks the hosts file. Good to know that the problem has been resolved. It's a very graphic illustration of the importance of constant vigilance when visiting secure sites.

It's worth downloading HijackThis, it's a well known and trusted free utility which scans the hosts files, IE plugins, autoloading programs and loads of other potential hijacks of your system.

Trouble is it doesn't tell you what's good or bad, it just tells you what's there. Anything you're not sure of you can check here:

DON'T tick the boxes next to any item unless you are sure it's bad/not required otherwise you can totally screw the system. Use the above guide, or post the log on the HJT forum on the site.

Thanks for suggestion - it has already been run - nothing found :-(

The bug is related to DNS, which means that someone could change the DNS entry for your bank's website, and redirect the browser to their website, rather than the bank.

This would happen regardless of which browser or operating system you were using as the attack isn't taking place on your computer.

However, if this was to happen, the website security certificate wouldn't match, and the browser would display a warning. To hide the warning, the attacker would either need to get into the bank's computer to steal the private key, in which case all bets are off anyway and they wouldn't need to attack the DNS server, or break into your computer to change your public key store or your browser settings to disable the warning, in which case all bets are off and they wouldn't need to attack the DNS server.

In the interests of technical accuracy and to avoid confusion, perhaps I may just clarify some terminology.

A URL (Uniform Resource Locator) is a combination of a "scheme" or protocol identifier and a host name, such as

"http:" is the scheme and "" is the host name. It's host names that are put in the "hosts" file, not URLs. It's worth making the distinction in case someone tries to put a URL in the hosts file - which won't work.

Mike.

If it was a DNS issue, it would affect Firefox in the same way that affects ie.

Just to explain this in a slightly different way from the other contributions:

Computers communicate across the Internet by means of IP addresses, a series of numbers such as 212.58.253.67. That, by the way, is the IP address of the BBC's Web server. Names, such as

are used for the benefit of humans, who find names easier to remember than numbers.

A name such as

which may appear in a URL, always has to be translated into an IP address before a Web browser can start talking to the distant computer. That translation is usually performed in the background by a DNS server, which knows how to convert a name into the corresponding IP address. But the translation can also be performed by (for example) a "hosts" file on the PC.

If, to give an example, you were to put a line in your hosts file reading:

66.102.9.104

and then point a Web browser, such as Internet Explorer or Firefox, to

your Web browser will display Google's home page, not the BBC's, because 66.102.9.104 is an IP address for !

Mike.

I'm not an expert on the subject, but I strongly expect the hosts file to be "normal".

There's a good chance his ISP has a poisoned DNS cache though, and it might be possible to check with the DoxPara link:

Click the link on the right hand side, and wait for a while - it may require several attempts (it did the first time I tried it)

There may be a way to automate a scan / result comparison for a "known" domain, but i'd have to play around with it (i'm not much of a programmer)

Has the OP tried scanning with some other utils like Vundofix and SmitFraudFix ?

In which case, I suggest that it's unlikely that this problem is caused by a rogue entry in the hosts file, because that would affect all Web browsers equally.

More likely is some malware that has modified the action of Internet Explorer and is intercepting network calls made by that Web browser.

It's been suggested that the ISP's DNS server could be to blame. That's possible but unlikely. There's an easy way of checking whether the local DNS server is returning correct information:

In Windows, click Start -> Run, type "cmd" without the quotes and press ENTER. A black window will appear. In that window, type "nslookup

" (for example), again without the quotes. That command asks the DNS server for the IP address of and the answer will be displayed in the black command box (as 194.60.38.75)

Then go to one of the Web sites that offers a DNS service, such as

and ask it for the IP address of (for example). If they match, the ISP's DNS server is returning the correct result. (There's one complication though: high-traffic sites often have many Web servers, sometimes with a range of IP addresses, behind one name, so different results from nslookup and a Web DNS server need to be interpreted with caution.)

Mike.

Also you can check that the ISP's DNS server hasn't been compromised (as per the Gruniad article) by getting a command prompt up and doing a PING to the bank's URL eg ping

This will give you the IP address as translated by the ISP's DNS server (or the hosts file as above).

Then compare with someone using a different ISP and check they are the same.

I guess once you're sure of the correct IP address you could just use this instead of the URL, might be safer?

That won't always work, especially if the server is using http 1.1 addressing to host more than one website on the server. That's less likely for a bank than some smaller sites, but they might use it for example to separate the business and personal sites or where they have different brands using the same platform.

Also, a lot of banks have different host names for different parts of the site, particularly for moving between the secure area and the customer information area of the site, so you would have to keep retyping the urls when moving between these areas.

In my experience that link "checks" one of the authoritative nameservers for the IP address range for your connection. It does not carry out a rDNS look-up of your IP address.

It does *not* check the caching nameservers at your ISP, unless they are one and the same as the authoritative nameservers which would be unusual.

I might suggest installing Bind for Linux users, or Treewalk for Windows users, behind your firewall or NAT router if you have doubts about your ISP's caching DNS servers.