In this post I bring you one of the first protocols in the history of the Internet: the Telnet protocol. This will be a short post as this protocol is not very complex, but I needed to include it in this section as the client is very useful during a pentesting.
In general telnet (RFC854) has been used to open a session with a UNIX machine, so that multiple users with an account on the machine, connect, log in and can work using that machine.
However, this protocol is hardly used today. One of the simplest questions I usually ask in job interviews to candidates who want to join my current company is the following: Suppose a developer tells you that they have a server and plan to manage it using the telnet protocol. Does this seem appropriate to you? Would you recommend using some other protocol?
Obviously the answer I expect is a categorical no. This is because all the user names and passwords needed to enter the machines will travel through the network as plain text, as the telnet protocol is not encrypted. Anyone on your network who is listening in will be able to intercept all the information you send with this protocol.
In fact, the SSH protocol was created specifically to replace Telnet and provide a secure alternative for server maintenance and management. Since decades Telnet has been replaced by Secure Shell. If you want to discover the main SSH vulnerabilities and how to use this protocol to your advantage during pentesting, I recommend that you take a look at this post.
The telnet service provides you with a shell. The port on which this protocol usually runs is port 23. But in this post I will also tell you about the telnet client, the tool that allows direct connection to different protocols.
The telnet client is a tool for manually entering the different services running on a machine. You can use telnet to access any port and check what is there.
For example, you can use telnet on port 22 and see the SSH service header, telnet on port 25 and send commands from the SMTP messaging service:
This is also possible with other tools such as netcat, however there is a slight difference that can make trying to connect to a protocol via telnet work while via netcat does not, and vice versa.
Let’s look at an example. Below is a server where there is a service on port 4386 that nmap has not recognized. Let’s connect to telnet:
As we can see, this service allows us to execute queries to a database, and we can connect via telnet. However, let’s see what happens if we try to connect with nc or ncat:
Although they are also tools that can be used to make these connections between servers, we see that when we send the help command we do not receive any more response, so we have to abort the session. In my experience it is common for this to happen, so it is a good idea to test the services with different tools during a pentesting session.
But now let’s find out why this actually happens. To do this we will analyse the traffic with wireshark. This is what we get when we type the “help” command when using telnet:
With telnet you send 0d 0a and with nc you only send 0a. In ASCII code, 0a corresponds to \n (new line) and 0d to \r (carriage return).
Telnet sends when you press enter, while netcat only sends. The protocol is waiting for the carriage return as well, so with netcat it doesn’t work and with telnet it does.
In conclusion, whenever you find a strange port while pentesting, try using the telnet client to get more information about that port, because that way you can see first-hand the information sent to you by the service that is running. This way you may be able to get useful information such as the header that reveals what service it is and its version. But if it doesn’t work, don’t forget to try similar tools like netcat.
Do you have an email? Don’t miss next week’s post, in which I will talk about the vulnerabilities of the SMTP, POP3 and IMAP protocols.