By: Ben Doyle
A technique that can be used by an intrusion analysts when trying to find out information about the source of an incident is to use passive fingerprinting. Upon research on the Internet, I found that there are a number of good papers on passive fingerprinting . However, apart from using ICMP echo request data, there is little material that looks at using protocol payload to try passively fingerprint the source. I decided to take a closer look at the telnet protocol and its command option negotiation to see if these negotiations can be used to create a signature for default telnet clients on operating systems.
The reason why I chose the telnet protocol, was because potential intruders may use the reconnaissance technique of telneting to a server, to grab the telnet banner from the daemon. If a server is stilling using the default telnet banner for that operating system, then the intruder can use this information to determine what operating system their target is (therefore focusing the type of attacks that should be tried). Because it is thought that telneting to grab a banner is low cost (i.e. it does not give the intruder away), there is a chance the attacker may not protect themselves as well at this stage of their reconnaissance. Therefore if we can determine something from this telnet connection, may it be worth a lot more to intrusion analysts in determining the true source of an attack.
What is Passive Fingerprinting?
A common technique intruder’s use when conducting reconnaissance is OS (Operating System) fingerprinting. Because the operating system developers interpreted the RFC’s (Request For Comment http://www.rfc.net) that define the protocols for TCP/IP differently, each operating system has ended up with its own set of “quirks” when responding to certain conditions. These “quirks” can then be used to create a signature (“fingerprint”) for that operating system under certain TCP/IP communication conditions. Fyodor has written a seminal paper on some tests that can be performed using crafted TCP/IP packets, and depending on the response you can determine the remote operating system. Using this concept, a number of tools have been created to allow a person to remotely “fingerprint” a system to try to determine the operating system. Some of these well-known tools are:
Nmap - http://www.insecure.org/nmap.The concept of active fingerprinting (i.e. you are actively sending data to determine the operating system by the response) can be applied passively by an intrusion analysis when reviewing a captured data-stream. Because each operating system has its own “quirks”, it has been found that you can determine signatures/fingerprints by the default settings used in TCP/IP headers and in some ICMP message types. The act of trying to determine an operating system from these default settings is called Passive Fingerprinting (i.e. you are not sending any data to the remote site in question to determine a signature, but using its communication behavior to do so).
There are a number of TCP/IP fields that passive fingerprinting tools tend to focus on. Following is a list :-
IP TTL - This is the Time-to-Live field in the IP header. Different operating system have different default TTL values they set on outbound packets. There is a good paper on default TTL values created by SWITCH (Swiss Academic & Research Network).
IP DF - This is the Don’t Fragment field in the IP header. A number of IP devices set the DF field on by default. So the use of this field for passive finger printing is of limited value. IP TOS - This is the Type-of-Service field in the IP header. Because it has been found that what TOS is set tends to be govern a lot more by the protocol then the operating system, it is also of limited value.
TCP Window Size - It has been found that TCP Window Size can be a useful way to determine the sending operating system. Not only the default size that is set to an outbound packet, but also how the window size changes throughout a session.
Other fields that can also be used to passively determine the IP device of a packet are:- IP ID numbers, TCP selective acknowledgment (SackOK), and TCP maximum segment size (MSS).
There are currently three main open source tools that can be used by the intrusion analyst to help with passive fingerprinting. Below is a table that lists the tools, where you can find them, and also the source file that contains the fingerprint database.
From the discussion above you can see that the main resources used currently for passive fingerprinting are details found in the headers of the TCP/IP packet. There are a few papers that talk about using the ICMP data payload to passively fingerprint data, but apart from this there is little discussed about the potential of using other payload data to help correlate passive fingerprinting analysis. A paper from Crimelabs Research does discuss fingerprinting using application data. Specifically, it outlines briefly, ways to passively fingerprinting mail, usenet, web and telnet clients.
The rest of the paper will expand on the research done by Crimelabs Research, on passively fingerprinting telnet clients (default operating system telnet clients) to determine we are able to use this technique to help correlate fingerprint analysis from the TCP/IP headers.
The Telnet Protocol
The telnet protocol is a well-defined TCP service that by default is served from port 23. The concept and requirements for the telnet protocol were first outline in RFC854. Telnet offers the service of a virtual terminal interface between systems that assumes a common terminal encapsulation. This concept is described as a “Network Virtual Terminal” (NVT) in RFC854. The idea is to provide a common terminal framework that different end point terminal devices can use to display data. Therefore not needing a dedicated server daemon to talk to a specific client terminal type. (i.e. having a dedicated server terminal daemon for a remote VT100 terminal, and having a separate daemon for a remote ANSI terminal).
Because telnet clients and daemons may wish to enhance certain functionality’s upon the basic telnet requirements, the idea of “options” was build into the telnet protocol. By using an option, a more enhanced client can request from a daemon the use of a larger character, and the daemon will respond if it can enable the requested option. The negotiation of options are used by the keywords WILL, WON’T, DO and DON’T. If an option needs greater flexibility when negotiating then the to end points must first agree to use the option with the pervious four keywords, and then they can use a more specific syntax to finalise the implementation. To avoid option negotiation loops the following rules apply:-
Description of the Telnet protocol commands WILL, WONT, DO and DON’T
There are currently 42 different options defined in RFC1700 (“Assigned Numbers”) for the Telnet protocol. The majority of these options are defined themselves in separate RFC’s. Below is a modify copy of the Telnet option table that can be found in RFC1700
Telnet Options numbers (decimal and hexadecimal) and associated types.
Using the above information we should now be able to decipher a packet dump that shows a telnet option negotiation. We will use the following packet dump below:-
45c0 0037 0002 0000 ff06 63bd 0a1b 0106I have colour coded the packet dump above to make it easier to decipher. The first section of 20 bytes is the standard IP header. Following the IP header we have another 20 bytes which make up the TCP header. In the header we can see that the client source port is 11778 [0x2e02] and the destination port is 23 [0x0017], which is our defined port for the telnet service. Following the TCP header we have the TCP payload which contains the Telnet data. This packet capture only has Telnet command option negotiation data in it. You can see 5 sets of 3 byte Telnet commands. They are:-
The following table deciphers the all the Telnet command sequences seen in the example packet capture.
The Telnet Commands and Options found in the Example Packet Capture
The above description of the Telnet protocol should give you a basic understanding of how Telnet command options are negotiated and what those options are.
The Theory of Passive Fingerprinting with Telnet Data The paper from Crimelabs Research, regarding fingerprinting telnet clients, suggested that each telnet client has a unique way it negotiates with a telnet daemon. This is even the case between two different telnet clients running on the same source system. Crimelabs Research, also suggests that using the same data, you can fingerprint a telnet daemon by the way it negotiates with a client. Although this may be the case, we will concentrate on fingerprinting the default telnet clients of various operating systems.
Overview of testing structure
To fingerprint various default telnet clients negotiation telnet command options, I used the following test structure.
tcpdump -w <OSname>.dump and port 23
(NB: because this was a test server that did not normally receive telnet data, I could be fairly sure that I was safe using such a broad tcpdump filter. If this was not the cause I would have used a more restrictive filter to ensure I only captured the relevant client connection)
I then repeated the same process (steps 1 to step 4) using a Linux Redhat 6.1 telnet daemon for the clients to negotiate with. This was done to determine differences in the way clients negotiate depending on the telnet command options presented by the telnet daemon.
To easily review the data I used the tool Ethereal which has the ability break up packet data into its various protocol components to make it easier to read.
When reviewing the results of the two rounds of packet capture, I found that for both the telnet client and daemon the first telnet payload sent is always the same. This first packet is the “default” telnet command options that each end always tries to negotiate with the other end. Therefore, if there is enough different between the first packets sent by various telnet clients, then we may be able to use this first packet for passive fingerprinting.
Listed below is the default telnet command options that each telnet client tried to negotiate with. The numbers represents the order in which the command options are requested in, and I have listed the actual commands also (i.e. Do and Will). For example, the Cisco telnet client sends the following in its first packet:-
Do Suppress Go AheadBy looking at the table we can see that we should be able to passively fingerprint the following operating systems (NB: remember I have only tested it with one default client per OS):-
Cisco IOS - specifically the only one that requests the Will Send Location option.
FreeBSD - specifically the only one that requests Encryption Option, also it uses a Do followed by a Will telnet command on this option.
HP-UX - specifically by the type of options and the number of options requested.
Linux Mandrake 7.2 - specifically the options used with the addition option of Will X Display Location
Solaris 2.6 - specifically the use of the option Will Authenticate and Will X Display Location with the other options used.
Windows 2000 - specifically the use of the two options, Will Terminal Type and Will Negotiate about Window Size
Windows NT4 - specifically the use of only the Will Terminal Type option
We can also see from the table that a number of default clients have the same negotiation defaults for their telnet command options. Therefore if we want to fingerprint these systems, then we need to determine if we can find more information to form signatures. Some options that should be looked at are:-
Wrap up outlining how we can use what we found and why if it is worth it. (Part 1)
Wrap up outlining how we can use what we found and why if it is worth it. (Part 2)
Using the results obtained above (and from Crimelabs Research paper), it is feasible for the intrusion analyst to passively fingerprint a remote telnet client connecting to a server. This being the case, for greater assurance, it would be wiser to combine the previous technique with other passive fingerprinting techniques outlined in the first section of this paper. Remember, the telnet protocol is a TCP based protocol, and therefore we can use all the information in the initial TCP Syn packet to try to determine the remote operating system. We can correlate the information discovered in the packet headers with the telnet negotiation fingerprint to see if both results support each other.
Fyodor, “Remote OS detection via TCP/IP Stack Finger Printing”, April 10 1999, http://www.insecure.org/nmap/nmap-fingerprinting-article.html (01 March 2002)
Miller, Toby, “Passive OS Fingerprinting - Details and Techniques”, http://www.incidents.org/papers/OSfingerprinting.php (01 March 2002)
Dayýoðlu, Burak, Özgit , Attila, “Use of Passive network mapping to enhance signature quality of misue network intrusion detection systems”, November 2001 http://www.dayioglu.net/publications/iscis2001.pdf (01 March 2002)
Lasser, Jon, “Passive Aggressive”, 30th Janurary 2002, http://www.securityfocus.com/columnists/57 (01 March 2002)
“Default TTL Values in TCP/IP” , http://www.switch.ch/docs/ttl_default.html (01 March 2002)
Smith, Craig, Grundl, Peter, “Know your Enemy: Passive Fingerprinting”, 4th March 2002 http://project.honeynet.org/papers/finger/ (16 March 2002)
Nazario , Jose, “Passive System Fingerprinting using Network Client Application”, 27th November 2000, http://www.crimelabs.net/docs/passive.html (01 March 2002)
Queso, http://ftp.cerias.purdue.edu/pub/tools/unix/scanners/queso/ (01 March 2002)
Nmap, http://www.innsecure.org/nmap (01 March 2002)
q0f, http://www.stearns.org/p0f/ (01 March 2002)
ettercap, http://ettercap.sourceforge.net (01 March 2002)