Exploiting OpenSSH 4.7 / OpenSSL 0.9.8 (Metasploitable 2)

Metasploitable 2 is a deliberately vulnerable machine designed by Rapid 7, the company behind the immensely powerful and popular Metasploit Project. The machine is intended to be used for general security training and target practice; a perfect way to spend a lazy Sunday!
The focus for this particular post will be the OpenSSH 4.7 protocol used by the vulnerable machine. This version of OpenSSH is several years old now, but the lessons learned here are still transferable to other services and newer versions. Before diving into the exploit it is necessary to understand the protocol being attacked and why it was vulnerable in the first place.

OpenSSH is the freely available, open-source version of the SSH protocol. SSH itself is a cryptographic network protocol used to connect with network services securely over an un-trusted network. In plain English this means SSH is a secure way to login to servers and embedded devices that support the SSH protocol. While SSH has other uses it is best known for this secure login method. Early versions of OpenSSH had a dependency on a project known as OpenSSL.

OpenSSL is an open source project for the SSL (Secure Sockets Layer) and TLS (Transport Layer Security) protocols. The most widely known and used application of OpenSSL is the HTTPS protocol; it is TLS that is used to secure the communications between a web client and web server. OpenSSH 4.7 used a component of the OpenSSL 0.9.8 library related to the generation of secure asymmetric cryptographic keys. These cryptographic keys could be used to authenticate a client to an SSH server instead of passwords. Under normal circumstances this practice is considered more secure than authentication via password, but it is not without its own security considerations.

At this point a note on cryptographic keys is required. The term 'key' is a reference to either a symmetric or asymmetric key that is used to encrypt data sent between two systems. The actual encryption is performed by well known algorithms, such as Advanced Encryption Standard (AES) for symmetric keys and Rivest–Shamir–Adleman (RSA) for asymmetric keys. Whether symmetric or asymmetric, the keys are generated using mathematical frameworks that rely on large prime numbers and randomness.
When generating a key there are several important guidelines that should be met regarding the security and strength of the key. One such property is that it should never be possible to predict a keys output based on information known about previous keys, or based on predictable random number generation. Any such predictability would make the entire key space vulnerable to attack. OpenSSL 0.9.8 contained a vulnerability specific to predictable random number generation, which in turn impacted all Debian based systems using the 4.7 release of OpenSSH. To understand how this vulnerability is exploited requires a further understanding of asymmetric keys.

Asymmetrical key encryption, also known as Public Key Cryptography, is based on the use of public and private keys. A set of keys consists of one public and one private key that are together known as a key pair. Asymmetrical encryption works on the following principle: if a public key is used to encrypt data, only the corresponding private key should decrypt the data. To this end public keys can be freely exchanged and private keys must be kept secret. 
The correct handling and management of a public/private key pair is known as Key Management. Key Management covers the life cycle of the key pair; creation, usage, storage of the keys, and destruction of the keys. Poor Key Management will inevitably lead to compromised key pairs; a reality that often leads to compromised SSL certificates among other problems.
Public Key Cryptography has several important practical use cases: it is used with the Diffie-Hellman Key Exchange to securely generate symmetric key material for client/server communications, it is used in SSL certificates, it is used in PGP/GPG encrypted email exchanges and also used in some forms of user authentication (such as the type used by OpenSSH).

OpenSSH utilises Public Key Cryptography in a few places. It is firstly used by the SSH client and server when generating symmetric keys that will be used to encrypt the communication session. In this instance the client and server each generate a public/private key pair, exchange public keys, and then use the Diffie-Hellman Key Exchange to securely generate symmetric key material.
It is also used as an optional replacement for passwords. To verify the clients identity the server first sends a randomly generated string of data to the client using the client's public key (it is important to note that the server is aware of the client's public key before this exchange takes place. Assume it has already been securely uploaded to the server). The client responds by decrypting the data (this would only be possible if the client has the exact matching private key), taking an MD5 hash of the data, and sending the hash value back to the server. The server computes an MD5 hash of the same data already sent to the client and compares its hash against the client's hash. Should these two hash values match than the server knows the client is really who they claim to be; if they do not match than the server discontinues the session.

As previously mentioned, the Debian implementation of OpenSSH 4.7 / OpenSSL 0.9.8 contained a vulnerability related to predictable key output. The vulnerability is specifically within the Pseudo Random Number Generator (PRNG) used by OpenSSL 0.9.8. The PRNG generated predictable numbers as opposed to truly random and unpredictable numbers, limiting the number of unique public/private key pairs that could be created. This meant that attackers could precompute every possible public/private key pair within OpenSSL 0.9.8 and brute force a Debian based server running OpenSSH 4.7. This is precisely the attack that will be demonstrated on Metasploitable 2's OpenSSH server. 

Every vulnerability assessment begins with reconnaissance and research. Given that it's already quite clear what service is being targeted and why, it is appropriate to start considering the exploit that will be run. As the vulnerability being targeted is in the OpenSSL library and not the OpenSSH code, I'll begin by assessing the exploits available on Kali Linux against OpenSSL:

There are three exploits available for the predictable PRNG vulnerability. Each is written in a different language; Perl, Python and Ruby respectively. Before running any of these exploits it is wise to read the code - every line of it. An exploit will often be deliberately broken in some way to prevent the wrong kinds of people from using it. Other times there may simply be a bug in the code that returns unexpected results, as is the case with the Ruby script.
Opening the Ruby script in a text editor immediately reveals an interesting comment left by the exploit-db team:

The update link leads to the online code repository GitHub, and in this instance to a code commit that fixes a bug in the Ruby script. The bug returned false positives immediately after running the script, indicating that a vulnerable key had been found when really no keys had been tested in the first place. 

My knowledge of Ruby is certainly not comparable to my knowledge of Python, so to run the exploit I will use the Python script. After reading through the code it became clear that the exploit was not deliberately broken, but it did require the use of an external resource - a file named 'debian_ssh_rsa_2048_x86.tar.bz2'. This file contains 2048 bit RSA keys that were generated using the vulnerable OpenSSL 0.9.8 library. With the file downloaded, it is possible to run the exploit against the vulnerable host:

The Python script is called with a number of parameters. The first is the location of the RSA key file, the second is the IP address of the target, the third is the user to attempt logging in as, the fourth specifies the port to connect on and the fifth specifies how many threads to run the script with. The keys in the file will each be tested against the host until finally a match is found:

The RSA key that has been matched is the private key associated with the root users public/private key pair. It's possible to now login as the root user on this server and enjoy unrestricted access to it. Executing the following command allows me to login to the server with the vulnerable RSA key:
ssh -lroot -p22 -i /root/Documents/meta2/rsa/2048/57c311... 192.168.242.10 

The observant reader may have noticed that the metasploitable server is using Ubuntu and not the vulnerable Debian system that was previously mentioned. The Ubuntu distribution is based on Debian architecture, meaning that Ubuntu was also affected by the OpenSSL 0.9.8 PRNG vulnerability.

The exploit itself is really quite simple - a file of known keys is tried against an SSH server until a matching key is found. This is essentially the same concept used in every type of brute force attack, regardless of the protocol being attacked. The defence mechanisms are also the same: limit user login attempts and restrict access to the server using IPtables or other similar firewall utilities. It is also possible to password protect the private key in a public/private key pair for an additional layer of security. In this particular instance it would have also been necessary to update the OpenSSH/OpenSSL packages and generate new keys that are not vulnerable.

The real value in spending time on the Metasploitable 2 machine is not so much running the exploits as much as it is taking the opportunity to learn more about how a given service works and what made it vulnerable in the past. This type of knowledge is invaluable and helps create the kind of mindset needed when defending servers from malicious actors.





Links used for research:
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2008-0166
https://www.debian.org/security/2008/dsa-1571
https://security-tracker.debian.org/tracker/CVE-2008-0166
https://www.exploit-db.com/exploits/5632/
https://www.digitalocean.com/community/tutorials/understanding-the-ssh-encryption-and-connection-process
https://utcc.utoronto.ca/~cks/space/blog/tech/SSHAndSSLAndHeartbleed
https://utcc.utoronto.ca/~cks/space/blog/linux/DebianSSLConsequences
https://github.com/audibleblink/exploit-database/commit/493261ebfe1faae83ebe32d5518b87a8bb93e1e5
https://github.com/audibleblink/exploit-database/blob/493261ebfe1faae83ebe32d5518b87a8bb93e1e5/platforms/linux/remote/5632.rb