An Investigation Into TOR Pt. 2 - SSH Encryption

SSH (Secure SHell)

 

 

Fig #1

We're looking into TOR, so why did we go over Telnet and why are we now looking into SSH? Well, the answer is that I wanted to show you Telnet's insecurities and SSH's securities before we discuss the behemoth that is TOR. SSH is short for Secure Shell and should be used instead of telnet (although like I said in my previous post, I have seen Telnet used in the workplace!).

What's so secure about SSH? Well, SSH runs on port 22 as standard and encrypts traffic so that a 3rd party shouldn't be able to decrypt and read packets going to and from computers on the network - this is why it's more secure than Telnet. With that being said, there are 2 versions of SSH - v1 and v2. V1 has known vulnerabilities which is why v2 is often the default these days.

SSHv1 has a "remote integer overflow" vulnerability that allowed hackers gain root access, which in turn would let them run code (with root access). Fun fact: This vulnerability in the coding of SSHv1 is in a piece of code that was created to defend against CRC32 exploitation in the SSH1 protocol! Ettercap can decode SSHv1 in real time (Source: Cisco).

SSH1 and SSH2 share the following features:
• Client programs that perform remote logins, remote command execution, and secure file copying across a network.
• An extremely configurable SSH server.
• Several selectable encryption algorithms and authentication mechanisms.
• An SSH agent to cache keys for easy access.

SSH2 added a number of new features to provide a stronger, more comprehensive product. These features include:
• Encryption ciphers, such as 3DES and AES.
• The use of sound cryptographic Message Authentication Code (MAC) algorithms for integrity checking.
• Support for public key certificates.
(Source: Cisco).

So i've used Wireshark to capture an SSH handshake and 'dir' command. Let's see exactly what we've got.

 Fig #2

 What you're looking at above is a PCAP (packet capture) that I captured from SSH'ing from my laptop to my desktop PC. The PCAP consists of just 35 packets and we'll look through them now. At the beginning of this blog post, you saw the "SSH handshake". The first set of packets are the handshake. Let's recall the image at the start of this post:

 

Fig #3

 

 The client (my laptop) was connecting to the SSH server (my desktop PC). There is a TCP 3-way handshake that takes place (SYN, SYN/ACK, ACK). So let's look at this on Wireshark:

 Fig #4

 Packet 1 shows 10.0.0.53 which is my laptop's internal IP address sending a SYN packet via TCP over port 52421 (which is the TCP port). Let's investigate packet #1 a little further:

Fig #5

So i've opened up packet #1 a bit more. We can see here that the laptop (red) has found the PC (yellow) mac address, so they know each other's IP and mac address. The green highlight shows that the client (laptop) sent the SYN packet to 10.0.0.54:22 (the PC's port 22...SSH port).

So if you look at Fig #4 again, you'll see the entirity of the SYN , SYN/ACK, ACK sequence. Once this has taken place, referring to Fig #3, the server tells the client what version it's running and the client responds with that version of client it's running. We can see this very clearly if we analyse packet 4 in Wireshark:

 So we know that we're using FreeSSHd because of the (WeOnlyDo) server version and we know our client (laptop) is using PuTTY 0.63.0.0. Packet 5 & 6 is the KEXINIT negotiation - basically - the client and server negotiate the algorithms they will use to exchange keys along with, bulk data encryption, message integrity, and compression.

The peers will also let each other know the accepted host key types. In this stage they present their supported and preferred methods for the aforementioned functions in comma seperated list form (CSV). Preferred values are distinguished by placing them first in the list (Source: http://www.mnin.org/write/2006_sshcrypto.html).

 Packet 8 is the Diffie-Hellman Key Exchange Initialization - which essentially lets the client and server derive the exact same secret key (symetric encryption). An important thing to note is that the SSHv2 protocol is now in use. It was at this point I ran the 'dir' command from my client to the server - yet I cannot see this command in plain text as it's encrypted. The idea is to stop a 3rd party from listening in and seeing what commands are being run etc.

This does pose an interesting question? Can we decrypt SSH? The answer is: yes. SSH can be decrypted using a MiTM attack (MiTM-SSH) or by creating a rule on a firewall to generate it's own key (not certificate, as SSH uses keys, not certs). This may be a good topic to come back to..

The next post will be about TOR. I thought it necessary to discuss Telnet & SSH before we delve into TOR, as TOR is very complex and a good background on networking/encryption is useful. Thank you for reading. Expect a post about TOR towards the end of this month.