cyberblog

Proof of Concept: Using Wireshark to demonstrate Telnet's vulnerability

Telnet is a client-server protocol used to establish a connection to TCP port 23, allowing remote communciation between computers. It's been used since 1969, and for a long time, it stood as the default way to access remote networked computers. But, as the years pass, technology becomes deprecated, and needs to be replaced.

The issue is that, by default, Telnet does not encrypt any data sent over the connection (not even passwords), so it is vulnerable to eavesdropping. Since Telnet is at risk from network-based cyberattacks, such as packet sniffing sensistive information, it is often targeted by attackers, compromising privacy.

Packet sniffing over Telnet using Wireshark

I wanted to play around with two virtual machines, so I used them in this simple experiment. First things first, I prepared the VMs in VirtualBox, installing Windows 10 Enterprise on one of them, and Ubuntu 22.04 on the other.

In order to simulate a private communication between the two machines, I attached the VM's network cards to an internal network (intnet). Normally, VirtualBox uses a device driver on your host system that filters data from your physical network adapter. This is called bridged networking, and it's used so that the VM can directly communicate with the outside world. But with internal networking, that outside world is limited to other VMs on the same host which connect to the same internal network.

Technically, anything that can be done using internal networking, can also be achieved using bridged networking, but there are security advantages to internal networking. Since in bridged networking mode, traffic and log data flow through the physical interface of the host system, you can attach a packet sniffer to the host interface and log all traffic that goes over it. So we use internal networking to ensure that two VMs on the same machine communicate privately, hiding their data from the host system and the user.

There is no central configuration to create an internal network, it is just identified by name. Once there is more than one active virtual network card with the same network ID, the VirtualBox support driver implements a complete Ethernet switch, supporting broadcast/multicast frames and promiscuous mode (which allows the VM to connect to the physical network and receive network packets).

Once ensured both machines can connect to intnet, we can manually assign them an IPv4 address and subnet mask.

To verify that the VMs are able to reach eachother, we can make them ping one another.

Note #1: On Ubuntu, I had to run su - to escalate privileges and further run sudo apt install net-tools in order to use ping and ifconfig.

Note #2: I disabled Windows Firewall on my Windows 10 VM, otherwise my Ubuntu VM would not be able to transmit any packets to it.

In order to proceed with the experiment, I downloaded PuTTY and Wireshark on the Windows VM.

• PuTTY is an open-source terminal emulator, and we are using it as a Telnet client, though it supports several network protocols, including FTP, SSH, Telnet, SCP, rlogin, and raw socket connection.
• Wireshark is an open-source packet analyzer, and we are using it to analyse communications between the two VMs.

I also checked that I had Telnet on the Ubuntu machine by running sudo dpkg -l | grep telnet (although, a telnet client should come standard with Ubuntu).

Finally, it was time to use PuTTY to gain remote access to the Ubuntu machine via telnet.

I logged in using the credentials of the Ubuntu account - the username linuxline and the password qwerty.

I had started capturing traffic on Ethernet 2, the interface corresponding to the internal network we have previously set up. Next, I applied the filter tcp.stream eq 0, and followed the TCP stream to see the packets being transmitted between the two IP addresses.

We can see the entire conversation in ASCII. And sure enough, there is the password in cleartext!

SSH - Telnet's alternative

SSH (Secure Shell Protocol) is a cryptographic network protocol that was designed for Unix-like operating systems in order to replace Telnet and other unsecured remote Unix shell protocols, such as rsh (Berkeley Remote Shell). Its first version was released in 1995, and since then, it occupies port 22 (between 21 (FTP) and 23 (Telnet)).

Much like Telnet, SSH applications are based on a client-server architecture. But unlike the former, SSH uses public-key cryptography to authenticate the remote computer and allow it to authenticate the user. In simple terms, it makes its connection using that key, which is obtained when you make a certificate. You distribute the keys to whoever is allowed in the conversation, creating an encrypted channel.

Conclusion

In the end, we close or filter ports that aren't necessary, or that expose our system. Therefore, it is recommended that port 23 be closed - disabling Telnet tightens and protects our system security.