I understand that there has been some discussion and concern around “pharming” – the (ab)use of the Domain Name System to misdirect people away from legitimate site(s) – normally financial institutions, to fraudster controlled sites. It has been alleged that banks are pretending that the problem doesn’t exist, refusing work properly with the police, and “want to keep online crime (an implicit “artificially” should be recognised here) figures low”.
Where to start – well, let’s start at the end. Yes, banks do want to keep fraud against them and their customers within manageable levels and ideally as low as practical (note, not possible – as low as possible would be £zero, and this is impractically expensive, even if you exclude collusion between criminally inclined bank staff). Risk appetite varies with the specific banking product - consider the difference between mortgages and "unauthorised overdrafts", for example, and controls are selected, in part, for their cost effectiveness. Pretending crime is lower than it actually is will happen in some areas, I am sure, but in the end the books have to balance, one of the pretty fundamental attributes of banking and all that would happen, really, is that the amount would move between different fraud categories – customer to third party or internal.
Let’s look at the initial premise – does a problem exist? DNS attacks, of various levels of subtlety and technical prowess, have been around for some time. The fraudulent transfer, for example, of the sex.com domain (which is still rumbling on over 10 years after the event) was a totally non-technical DNS hijack.
So, how can the DNS compromise take place:
- On host - modify \etc\hosts - this will often be done with a memory resident browser (mostly IE, as ever) exploit, therefore will not show on AV
- On host - modify resolving DNS servers to ones controlled by the fraudsters and fake authoritative for bank domains - as above
I do not personally consider those to be "pharming" - they should be categorised as malware payload impact and, it needs to be pointed out, that the only way you can spot these is to be using the client resolver on the customer's machine - not a practical detection (as opposed to investigation - you can ask the customer to run nslookup or dig and ip/ifconfig and compare the results with what might be reasonably expected) proposition for the banks.
- At the ADSL router or cable modem - these often will act as a DCHP server and there is a history of security vulnerabilities and lack of a patching mechanism. These can then either direct DHCP clients to use a fraudster controlled DNS server or, where they also act as a DNS server, either be falsely authoritative for the banking domains or use a non-standard root to find the "authoritative" servers. This has the same advantage for the fraudster that you need to be on the customer's LAN / WLAN to see the issues.
- At ISP - compromise the DHCP servers to get them to return DNS resolving servers controlled by the fraudsters: this has the advantage that it can be trivially invisible to even the most well aware customer.
- At ISP - compromise the DNS servers to get them to pretend to be fake authoritative for the target banking domains or to refer to fake auth servers controlled by fraudsters.
- At ISP - DNS cache poisoning using glue records - this shouldn't work as the attack is 3 to 4 years old. However, surveys suggest that too many resolving DNS servers are still vulnerable: I have seen data which suggests over 80% of boxen surveyed are broken - not that I have any trust in the methodology or the results of that survey.
- At the registry or root servers - as per two layers above - these should be better protected 'though.
- At the authoritative servers for the banking domains.
Now, only the last two will affect all of the bank's customers and only the very last will be on infrastructure that the bank reasonably control or have direct contractual influence over. The previous 3 will only affect customers of the specific ISPs targetted, who may or may not be an ISP that the bank uses for some form of internet connectivity. Now the bank's customer relations / internet banking helpdesk will normally access the site through the bank's internal network, so they are going to need (and, in my experience, often have) terminals capable of dialing in through consumer ISPs, in order to see as close as possible what the customer is seeing.
It should also be noted that "compromise" does not mean "hack" - the malware, router modification and DNS cache poisoning are all technical compromises, but for the others a suborned or placed ISP employee would be perfectly viable method. I suppose that you could also get an ISP employee to place a dodgy upgrade to the routers, but you would expect that this would be more likely to be detected by the ISPs controls framework.