This post will show another attack vector on the metasploitable operating system. I learned today that when port scanning a machine, nmap by default only scans 1000 ports. "The simple command nmap
nmap -v -sV -p 1-65535 <target ip address>
As you can see, we are given one more open port and service when we set the -p flag in nmap to all possible ports. We will now search metasploit to see if this service is vulnerable to attack.
msf exploit(distcc_exec) > exploit
We then get a shell on the machine.
A quick whoami command shows that we are running as the daemon user. To further compromise this machine we will need to escalate our privileges so that we are able to move more freely on the machine. After some searching through some of the limited files we are able to view, we discover that the read permission bit is set on the authorized_keys file within the /root/.ssh/ directory allowing us to view the contents of the file.
If we are able to brute force this encrypted key, we will be able to login to this server as that user. We are only able to do this because this users key is stored in the authorized_keys file on this server.
We now need to find a tool that will help us brute force this key. After heading over to exploit-db.com and searching for openSSL on linux we find a suitable tool here : http://www.exploit-db.com/exploits/5720/
This tells us that first we must download the list of keys. Since we are able to see the private key, we can just use this downloaded list and grep to find to corresponding public key.
Awesome. We found the corresponding public key. Now all we need to do is try and login to the metasploitable machine through ssh with the public key file using the -i identity file flag.
And we now have root access.
To find out more about this attack, refer here : http://digitaloffense.net/tools/debian-openssl/
Hello,
ReplyDeleteNice thing you explain the ways to hack Metasploitable. These were "left to the reader" at the end of the book "Metasploit The Penetration Tester's Guide". Thanks.
Small correction: in the authorized_keys there are public keys we can see, and the "-i identity" uses as argument the corresponding private key.
From here http://www.eng.cam.ac.uk/help/jpmg/ssh/authorized_keys_howto.html:
"The public key does not need to be kept secret; there is no practical way of guessing the private key that will match it". But in this case, a vulnerability in OpenSSL just made this practical ( http://digitaloffense.net/tools/debian-openssl/)