Summary
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).
Queso - http://ftp.cerias.purdue.edu/pub/tools/unix/scanners/queso/
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.
| Tool Name | Source Location | Fingerprint DB |
| Ettercap | http://ettercap.sourceforge.net | etter.passive.os.fp |
| q0f | http://www.stearns.org/p0f/ | p0f.fp |
| Siphon | http://gravitino.net/projects/siphon/ | osprints.conf |
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:-
- A host can only request a change in options. A host cannot use option negotiation to announce what options it is currently using.
- If a host gets a request to implement an option that is already in use, then it will ignore the request.
- If party A wants to initiate a change in option with party B, then party A has to send the option request at the point where they wish the option to take place in the data-stream.
| Telnet Command | Value | Description |
| WILL <option> | 251 [0xfb] | Use to indicate that you wish to begin using the specified option, or is used to acknowledge the implementation of the requested option (from a DO command) |
| WONT <option> | 252 [0xfc] | Used to indicate that you refuse to use requested option (from a DO command), or that you wish to stop performing the indicated option. |
| DO <option> | 253 [0xfd] | Used to indicate to the other side that you request to use the specified option, or it is used to confirm to that you are expecting the other side to start using the specified option. (requested from a WILL command). |
| DONâT <option> | 254 [0xfe] | Used to demand that the other side stop using the specified option, or that you are no longer expecting the other person to perform the indicated option (from a WONT request). |
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
| Option # | Description | Option # | Description |
| 0 [0x00] | Binary Transmission | 22 [0x16] | SUPDUP Output |
| 1 [0x01] | Echo | 23 [0x17] | Send Location |
| 2 [0x02] | Reconnection | 24 [0x18] | Terminal Type |
| 3 [0x03] | Supress Go Ahead | 25 [0x19] | End of Record |
| 4 [0x04] | Apporx. Message Size Negotiation | 26 [0x1a] | TACACS User Identification |
| 5 [0x05] | Status | 27 [0x1b] | Output Marking |
| 6 [0x06] | Timing Mark | 28 [0x1c] | Terminal Location Number |
| 7 [0x07] | Remote Controlled Trans and Echo | 29 [0x1d] | Telnet 3270 Regime |
| 8 [0x08] | Output Line Width | 30 [0x1e] | X.3 PAD |
| 9 [0x09] | Output Page Size | 31 [0x1f] | Negotiate About Window Size |
| 10 [0x0a] | Output Carriage-Return Disposition | 32 [0x20] | Terminal Speed |
| 11 [0x0b] | Output Horizontal Tab Stops | 33 [0x21] | Remote Flow Control |
| 12 [0x0c] | Output Horizontal Tab Disposition | 34 [0x22] | Linemode |
| 13 [0x0d] | Output Formfeed Disposition | 35 [0x23] | X Display location |
| 14 [0x0e] | Output Vertical Tabstops | 36 [0x24] | Environment Option |
| 15 [0x0f] | Output Vertical Tab Disposition | 37 [0x25] | Authentication Option |
| 16 [0x10] | Output Linefeed Disposition | 38 [0x26] | Encryption Option |
| 17 [0x11] | Extended ASCII | 39 [0x27] | New Environment Option |
| 18 [0x12] | Logout | 40 [0x28] | TN3270E |
| 19 [0x13] | Byte Macro | 255 [0xff] | Extended-Options-List |
| 20 [0x14] | Data Entry Terminal | ||
| 21 [0x15] | SUPDUP |
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:-
0a1b 4206 2e02 0017 3cf4 3cfa 8f61 9bd5
5018 1020 41ef 0000 fffd 03ff fb18 fffb
17ff fb20 fffb 21
- ff fd 03
- ff fb 18
- ff fb 17
- ff fb 20
- ff fb 21
- 0xff = IAC
- 0xfd = DO
- 0x03 = Suppress Go Ahead
The following table deciphers the all the Telnet command sequences seen in the example packet capture.
| Example # | Raw Data | Telnet Command | Telnet Option |
| i | ff fd 03 | DO | Suppress Go Ahead |
| ii | ff fb 18 | WILL | Terminal Type |
| iii | ff fb 17 | WILL | Send Location |
| iv | ff fb 20 | WILL | Terminal Speed |
| v | ff fb 21 | WILL | Remote Flow Control |
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.
- Set up a Solaris 8 server that had the default telnet daemon enabled
- Before each telnet connection I set up a separate tcpdump capture using the command syntax:-
- From the command line of the operating system I was testing, I connected to my Solaris 8 test server with the default telnet client.
- Once the client had received the âlogin:â prompt I broke the telnet client, and then stopped the tcpdump capture.
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)
| Operating System | Version |
| Cisco (router) | IOS 12.1 |
| FreeBSD | 4.4 |
| HP-UX | 11.0 |
| Linux | Redhat 6.1 |
| Linux | Mandrake 7.2 |
| SCO | 3.2 |
| Solaris | 2.6 |
| Solaris | 2.7 |
| Solaris | 8 |
| True64 | 4.0 |
| UnixWare | 4.2MP |
| Windows | 2000 |
| Windows | NT 4 |
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.
Results
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):-
Will Terminal Type
Will Send Location
Will Terminal Speed
Will Remote Flow Control
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:-
- What telnet command options wont a client accept
- How does the telnet client respond to multiply requests (e.g. the Cisco client seems to send a separate response (i.e. packet) for each telnet command option requested).
- Can we fingerprint telnet clients by defaults in sub-options. i.e. default Window Sizes (Negotiate about Window Size option), or Terminal Speed?
| Telnet Command Option [Option Number] | Suppress Go Ahead [3] | Status [5] | Send Location [23] | Terminal Type [24] | Negotiate About Window Size [31] | Terminal Speed [32] | Remote Flow Control [33] |
| Cisco | 1. Do | 3. Will | 2. Will | 4. Will | 5. Will | ||
| FreeBSD | 4. Do | 11. Do | 5. Will | 6. Will | 7. Will | 8. Will | |
| HP-UX | 1. Do | 2. Will | 5. Will | 3. Will | 4. Will | ||
| Linux RH6.1 | 1. Do | 8. Do | 2. Will | 3. Will | 4. Will | 5. Will | |
| Linux MD7.2 | 1. Do | 8. Do | 2. Will | 3. Will | 4. Will | 5. Will | |
| SCO | 1. Do | 8. Do | 2. Will | 3. Will | 4. Will | 5. Will | |
| Solaris 2.6 | 2. Do | 9. Do | 3. Will | 4. Will | 5. Will | 6. Will | |
| Solaris 2.7 | 1. Do | 8. Do | 2. Will | 3. Will | 4. Will | 5. Will | |
| Solaris 8 | 1. Do | 8. Do | 2. Will | 3. Will | 4. Will | 5. Will | |
| True64 | 1. Do | 8. Do | 2. Will | 3. Will | 4. Will | 5. Will | |
| UnixWare | 1. Do | 8. Do | 2. Will | 3. Will | 4. Will | 5. Will | |
| Windows 2000 | 1. Will | 2. Will | |||||
| Windows NT4 | 1. Will |
Wrap up outlining how we can use what we found and why if it is worth it. (Part 1)
| Telnet Command Option [Option Number] | Linemode [34] | X Display Location [35] | Authentication Option [37] | Encryption Option [38] | New Environment Option [39] |
| Cisco | |||||
| FreeBSD | 9. Will | 1. Will | 2. Do 3. Will | 10. Will | |
| HP-UX | |||||
| Linux RH6.1 | 6. Will | 7. Will | |||
| Linux MD7.2 | 6. Will | 9. Will | 7. Will | ||
| SCO | 6. Will | 7. Will | |||
| Solaris 2.6 | 7. Will | 10. Will | 1. Will | 8. Will | |
| Solaris 2.7 | 6. Will | 7. Will | |||
| Solaris 8 | 6. Will | 7. Will | |||
| True64 | 6. Will | 7. Will | |||
| UnixWare | 6. Will | 7. Will | |||
| Windows 2000 | |||||
| Windows NT4 |
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.
References (Papers)
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)
References (Tools)
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)
siphon, http://gravitino.net/projects/siphon
