2009-08-08:

A step beyond the drivers\etc\hosts file

security:windows:medium:re:cpp
(Be sure to checkout the demonstration video at the bottom of the page). Two months ago I've written about banker troyans, that some change DNS settings, other add a list of domains (used by financial institutions) to the c:\windows\system32\drivers\etc\hosts file. Of course both mentioned behaviors result in redirecting the user to some evil phishing site (sometimes an unlucky user might loose some money in effect).

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.

M: "Hah!"

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 ;>

Comments:

2009-08-08 01:42:10 = lallous
{
Nice trick! haven't googled, but has anyone spoken about this topic (and played with the dns dll) before?
}
2009-08-08 09:24:41 = Daniel
{
Interesting. Raises the question if WFP could be extended to verify not only on disk but also in memory?
}
2009-08-09 20:51:54 = plusvic
{
"driversetchosts" is the default path to the "hosts" file, but the path can be changed by adding a registry key. I don't remember the registry key right now, I leave it as an exercise to the reader :)
}
2009-08-10 10:33:00 = Gynvael Coldwind
{
@lallous
To tell you the truth.. no idea ;>

@Daniel
Thats an interesting idea ;>

@plusvic
Hi, didn't know you read my blog ;>
Anyway, are you referring to "HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpipParametersDataBasePath" (according to Wikipedia, it's this key) ?
I've researched this key a little on my Windows XP machine, and it seems that this key is not used by the Dnscache service. Even if I set this key to point at some other location, the Dnscache service still uses the driversetchosts file. Well, it isn't a surprise I guess, since as I've written, the hosts file location is hardcoded into the dnsapi.dll module on XP.
I've also checked Windows Vista, with same results.
So my personal opinion based on above research is that there is no way to change the file path by modifying registry keys (it's good to test it with process monitor with registry and file monitoring turned on, and do ipconfig /flushdns followed by a ping or some other DNS-resolving command).
}
2009-08-10 10:45:25 = Gynvael Coldwind
{
A little update on my above comment:
I've figured to check this also if I turn off the Dnscache service. But it appears to change nothing, since winsock also uses the dnsapi.dll module.
}
2009-08-10 10:57:43 = Gynvael Coldwind
{
Another update:
The key works OK on Windows 2000. Seems like they made some changes in XP and newer versions.
}
2013-09-28 16:05:26 = Nguyen Hung
{
Where to download file hostshack.exe ? Thanks !
}
2013-09-28 16:39:59 = Gynvael Coldwind
{
@Nguyen Hung
Download of the exe is not available. Just compile the source file that's at the bottom of the post.
}

Add a comment:

Nick:
URL (optional):
Math captcha: 4 ∗ 7 + 6 =