Friday, October 3, 2008

OSfuscate

OSfuscate: Change your Windows OS TCP/IP Fingerprint to confuse P0f, NetworkMiner, Ettercap, Nmap and other OS detection tools

I was wondering awhile back how one could go about changing the OS fingerprint of a Windows box to confuse tools like Nmap, P0f, Ettercap and NetworkMiner. I knew there were registry setting you could change in Windows XP/Vista that would let you reconfigure how the TCP/IP stack works, thus changing how the above tools would detect the OS. I wasn't sure what all registry changes to make, but luckily I found Craig Heffner's tool Security Cloak ( sec_cloak.exe ) and by looking at it's source I was able to figure out what to do. The needed IP stack changes were hardcoded into Security Cloak, but for my tool I decided to make it easier to update by allowing the user to add new OS fingerprint profiles as ini files. Yes, I know this is security through obscurity and the attacker can still probably figure out the OS on a box by other means, but I still think it's kind of cool to play with. If you want to try out the beta use the link below and let me know how well it works against Nmap, P0f, Ettercap and NetworkMiner:

Download OSfuscate 0.3

Curret profiles include: BeOS, Checkpoint Firewall, DOS, FreeBSD, HP Unix, IBM OS400, IRIX, Linux, Novell, Palm OS 3.5, PalmOS 5.2, Playstation, Sega Dreamcast, Sun OS, Tru64, Windows 2000, Windows 98, Windows CE, Windows NT and Windows SP SP1. Some may work better than others. Also, if you create any new OS profiles, please send them to me so I can add them to the distribution (I'll be glad to give you credit and link to your site). I make no guarantees that it won't screw up your box, so use it with caution. OSfuscate modifies the following registry keys:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\DefaultTTL
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Tcp1323Opts
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\EnablePMTUDiscovery
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\TcpUseRFC1122UrgentPointer
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\TcpWindowSize
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\SackOpts
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\*\MTU

I think the layout of a .os file is fairly self explanatory, and the Autoit3 source code is included in the download.

After doing some testing I found that NetworkMiner and Satori could still guess the OS by sniffing the DHCP queries from the client. It seems Windows XP and Vista embed "MSFT 5.0" in the queries as the Vendor ID, and the only way I've found to change this is to use a HEX editor on dhcpcsvc.dll. I wrote the tool "dhcpcsvc patcher.exe" to make this easier, but you should use this tool only at your own risk (it's in the zip file along with OSfuscate). The patcher looks for the HEX equivalent of "MSFT 5.0" (4d53465420352e30) in dhcpcsvc.dll, it then replaces the string with the 8 byte string of your choosing and writes it out to "patched-dhcpcsvc.dll" created in same folder as dhcpcsvc.dll. Reboot using a LiveCD with NTFS support (Linux or BartPE), backup dhcpcsvc.dll and rename patched-dhcpcsvc.dll to dhcpcsvc.dll. DO THIS AT YOUR OWN RISK!!! It could screw up your system, and while it seems to work in XP and Vista I've not tested it as much as I would like. You will most likely have to turn off System Restore to make it work.

Even after changing the DHCP Vendor ID, NetworkMiner and Satori still seem to be able to detect the OS by the DHCP query. Please let me know if you can figure out a way to fix this. Windows CE has the registry value:

HKEY_LOCAL_MACHINE\Comm\Adapter Name\Parms\Tcpip\DhcpOptions

and NT 4 had:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dhcp\Parameters\Options

but the the above key still exits in Windows XP/Vista, it doesn't seem to work (I deleted them all and the fingerprint was the same). Eric Kollmann was kind enough to point me to some Windows API calls that could help:

DhcpRequestOptions
DhcpRegisterOptions
DhcpSetMSFTVendorSpecificOptions

But the only way I can think of that they would be useful is if I implemented my own DHCP daemon. As of right now, if you don't want DHCP to give you away your best bet it to disable it, sniff the network for valid IP information and assign your IP manually.

rbevxhng8i
Experiment, do tests before and after you run OSfuscate, have fun and let me know how to improve it.

More:

http://www.irongeek.com


No comments: