|
operating system detection applications
The rest of this document will assume familiarity with the basic theory behind remote OS detection. Readers who wish to read up in this area may wish to refer to [2]. [why arp?] Firstly, the protocol is well established. Secondly, ARP is distinct from other protocols in that it is broadcast-based. This makes for some interesting possiblities on switched networks, especially those with shared link-layers across multiple VPN or VLAN segments. Thirdly, unlike other protocols, such as TCP[3][4] [5], ARP has not yet been publicly beaten-to-death in the remote OS detection arena. ARP has limitations in remote OS detection too, however. These include the requirement to share a link-layer with your target and the simplicity of the protocol (and thus lack of fingerprinting characteristics). Further compounding this latter problem is the fact that ARP is normally at the bottom of the protocol stack - therefore significantly differing implementations could potentially have devastating effects upon higher level networking. [fingerprinting approach] There are two ARP characteristics that I have used to discern between operating systems. Both of these are based upon causing 'adverse' circumstance to the target machine, forcing it to display relatively unusual behaviour. The adverse circumstance is inducing an ARP request from the target machine to a nonexistant host on the same ARP-utilising link-layer (eg: Ethernet, FDDI) as yourself. [the setup] The aforemetioned circumstance is brought about by spoofing[6] a packet of a higher-level protocol. The spoofed high-level packet is forged to appear as though it came from a nonexistant host on you and the target's link-layer, and is targeted at the target machine. The situation is thus:
When the packet arrives at TARGET (purporting to be from NONEXISTANT), TARGET will try to find out who on earth NONEXISTANT is by issuing one or more ARP requests. Normally, an ARP request is issued to a host that you are sending data to, requesting that host's hardware address. The request is keyed with your IP and hardware addresses, and the requested party's IP address. When such an ARP is answered, both the sender and receiver have their peers' IP and hardware addresses, and higher-level communication can begin. Because the spoofed higher-level packet is sent without such a precursory ARP request from NONEXISTANT, TARGET has no idea who is talking to it, and resorts to asking (how rude!). So the situation has now evolved...
Now, as the ARP request that TARGET generates goes unanswered, one of two things happens.
In the first case, we can do no fingerprinting with the techniques that I have implemented -- we're stuffed. In the second case, we are able to fingerprint. [taking the prints] The situation has changed again ... the target has repeated its ARP request.
We now have exposure to both of the variables that I have successfully used for ARP-based OS detection.
ARP request repeat delays are the time between repeated ARP requests. These may occur once (as in the diagram shown above), or multiple times (as in the diagram shown below).
ARP request repeat delays come in two flavours.
Constant ARP request repeat delays, such as Linux's one second delays, stay the same regardless of how many times the same ARP request has been re-issued. Varied ARP request repeat delays, such as OpenBSD 2.5's (note: this is unconfirmed, and is based solely on a tcpdump that I did about six months back), depend upon how many times the same request has been re-issued. For example, the first ARP request repeat delay may be smaller than the second ARP request repeat delay. [implementation] I have implemented a program called 'Induce-ARP' as a proof-of- concept. It is perl based, and uses the Net::RawIP module. At the moment, it can reliably destinguish between 'Windows or OpenBSD 2.6', 'Linux' and (untested) 'OpenBSD 2.5'. As the program includes a time-based fingerprint scheme, I am expecting the fingerprint database to develop rapidly as fingerprints are contributed. Please download the program and run it past your machines... contributors will receive full credit unless otherwise requested. You can always obtain the most recent version of the source from Packetstorm. To contribute fingerprints or code, please email me -- concept@ihug.com.au. [references]
|