A month ago I got back to the topic with a proposal to remove the write-access to the hosts file to every user on the system, including admin users ofc (in the comments the readers proposed to use a trip-wire-similar tools to watch the file). This can turn into a "dialog" of "what will we do next" between system admins and malware writers:
Malware writers: "We'll just change the file access back to the original (writable) state. Users run malware as admin anyway".
System admin: "Then we will turn on the audit flag for file access change and setup an special event handler that will kill your malware!"
M: "We'll just turn the audit handler off..."
S: "We will setup a guard program for that audit handler!"
M: "So? We'll just turn off the guard program as well..."
And so on...
All the focus is on that hosts file. Who can access it, who can write to it, etc. So... maybe we should change the question to: which part of system reads the hosts file?
Answering that question will lead us to the DNSAPI.DLL module (if one looks for files containing the path to the hosts file), or to the Dnscache service (if one uses a file-access monitor and checks which process accesses the hosts file).
Another question arises: if someone would change the path string (\drivers\etc\hosts) in the DNSAPI.DLL file to something else, what would happen?
Well, the DNSAPI.DLL would read the domain list from some other file and the drivers\etc\hosts file will become unless. And yes, the evil-phishing domains could be added to that other file.
What of it? Well, currently no-one I know monitors an unknown not-yet-existing file for domain list being modified ;>
S: "Hah! But I can monitor the access to the DNSAPI.DLL file!"
M: "But I don't need to change that file on disk, just in memory..."
Yep, the malware writer can just find the string in DNSAPI.DLL module in memory of the Dnscache service, and modify it there. There is no need to change the file itself.
S: "I will revoke all access to the Dnscache process for non-SYSTEM users!"
Well, the sysop doesn't have to to that - in Windows XP it's already done "by default", and I guess it's the same on newer systems (haven't checked it though).
But that doesn't change anything if the malware is run as admin, since the malware can gain back the access privileges just by calling a few API functions.
What malware families use this technique currently? Well, non that I know, so we still have enough time to set the access 'Audit' to Dnscache on the systems we run, or add some additional functionality to the products we create.
Is there a really good solution to this problem? In fact THERE IS - NEVER USE AN ADMIN ACCOUNT FOR NORMAL WORK! A user account is sufficient. If a malware is executed from a users account, it has no access to the hosts file, nor to the Dnscache service. I trust that every sane security-aware user works on a normal account. As for the security-in-aware users, well, there's always the drivers\etc\hosts file ;>
A demonstration of this technique:
The Proof of Concept code (yes, I publish it... it's just a combination of simple WinAPI functions, without any magic, so any coder would be able to write it, yet not all sysadmins are coders, and they do need to test their counter-measures if they decide they need them):
hack_a_hosts.cpp (8KB, CPP, source, tested on XP SP3)
Warning: the above PoC sets full access to the Dnscache service for the 'current' user, and does not revoke them later (it should be all OK after a reboot).
Comments are welcome ;>