It occurs to me that I’ve never actually talked about my dissertation software project which in September I completed for my Masters degree in Computer Security.
First a little background information. There exists a program called Nmap which primarily functions as a network mapper and security scanner, it is able to scan ports and help administrators determine possible holes in their system. It is popular and in some ways is the de facto standard to use for analysing network security nowadays.
An auxiliary feature of this program is the ability for it to send around a dozen carefully crafted probe packets to a remote host, analyse the responses (if any), then match these responses to a database to determine the operating system used and by extension the hardware in some cases. These specific responses are called a fingerprint. This analysis technique is called operating system fingerprinting and the methods used are detailed here. All sorts of tests are performed, from simple ones such as whether the host responds, checking certain fields are filled with the correct data etc, to more complex ones such as analysing the randomness of sequence values.
The aim of my project was to determine how much these results can be skewed to our advantage. The motivation for this is to prevent any system information from being revealed to a malicious user and thereby allowing them to use a system-specific exploit against us, such as the recently discovered method of remotely BSODing a Windows Vista/7 machine (which has thankfully been patched now).
To defend against this two separate programs were created. The first was a user-level program written in C# whose job it was to parse the Nmap fingerprint database to create a list of usable fingerprints. This information is displayed in a GUI and when one is selected it is processed and stored as registry values for use by the second program.
The second program works at the kernel-level as a driver written in C. It uses the Windows Filtering Platform API, this allows it to analyse incoming packets for probe packets, drop them then construct raw outgoing packets as responses. It drops the incoming packets to prevent Windows itself or any applications from replying and influencing the results. Raw packets (i.e. packets which we have complete control over) can’t ordinarily be constructed from within Windows, but kernel-level programs receive special privileges in that regard.
This solution enabled standard communication to still occur between the computer and outside networks as only detected probe packets would be dropped, though there is always the possibility that a regular packet would be incorrectly identified as a probe packet this is unlikely as there is usually no payload data in probe packets.
I’ll leave it there for now as this post has gotten a bit long. I’ll talk about it more soon.