|Main Archive Page > Month Archives > pen-test archives|
I would like to present a new project of the recon framework. The new release is called telnetrecon:
The telnetrecon project is doing some research in the field of telnet server fingerprinting. The goal is the highly accurate identification of given telnetd implementations. This is very important within professional vulnerability analysis.
Besides the discussion of different approaches and the documentation of gathered results also an implementation for automated analysis is provided. This software shall improve the easyness and efficiency of this kind of enumeration. The main approach is the fingerprinting of the telnet options negotiation initiated by the server part. Some basic ideas of application fingerprinting were discussed in the book "Die Kunst des Penetration Testing" (Chapter 9, Application Fingerprinting, http://www.amazon.de/dp/3936546495/).
Telnet is a traditional tcp service which is served by default on port 23. The initial specification is defined in RFC 854. Telnet stands for terminal emulation over a network. This means an user will be able to connect to a terminal remotely. This makes it possible to remote-conrol a server within the command-line.
The given implementations rose the need for further possibilities. This required the introduction of telnet options. The server and the client should be able to negotiate which techniques and features should be used and which should not. The negotiation of options are handled by the keywords WILL, WONT, DO and DONT.
telnetrecon uses the following technique of fingerprinting the given telnetd implementation. After connecting to a host the server responds with the option demands and requests. These are dissected and compared to the values within the fingerprinting database. As more matches could be found as higher is the accuracy of the mapped fingerprint.
For example the following is the negotiaton the telnet server implementation a Microsoft Windows XP sends back:
Those characters will be translated to their ASCII representation which is easier to analyze and compare them. This will generate the following fingerprint string:
The different demands are dissected by the IAC data byte 255. Then follows the requirement. The first requirement is introduced with the symbol 253 which stands for the option code DO. The requirement itself is 37 which stands for "Authentication Option" as it is discussed in RFC 2941. Afterwards follows another 255 which introduces 251 which stands for the option code WILL. This indicates the desire to begin performing, or confirmation that you are now performing, the indicated option. And so on.
The currently known implementations of telnet fingerprinting, primarily telnetfp by Team Teso, is using a strong identification mechanism. This means the tool is gathering the telnet option negotiation and compare it to the known strings. The identification is only successful if the collected strings are identical. This is the easiest approach which does not require real measurement of fingerprint hits.
However, this introduces the possibility of missing some partially known
implementations. For example if a well-known server has been configured
to announce RSA (authentication type 6) instead of KERBEROS_V5 (type 2).
This is the reason why telnetrecon uses a more modular approach which
was already introduced in httprecon
(http://www.computec.ch/projekte/httprecon/) and later in browserrecon (http://www.computec.ch/projekte/browserrecon/). The different negotiation aspects are handled seperately. This makes it possible to provide the accuracy of not exactly matching fingerprint scans.
The first release of telnetrecon is 0.1 which is not a major release because many features are missing. Especially the fingerprint database is very small and contain two example fingerprints only. Help to improve the project and upload new fingerprints of known telnet daemons.
For further details on telnet fingerprinting see the following documents: