Bandit LVL 13-16

December 31, 2021

#SSL #SSH #NC #nmap #bandit #overthewire #linux #cli

Level 13 –> 14

In this level, we were given:
– “a private SSH key that can be used to log into the next level”

Upon examination, there was a RSA key in the file sshkey.private. The goal is to use this key to login to the next level.

_What is immediately different about how we are asked to log in here vs previous levels?

Previously, we had to exit the connection and SSH into the server using the next username and password. This time, we must use the next username and RSA key.

To log in using a private SSH key, we use:
ssh -i sshkey.private bandit14@localhost

We are staying on the same server (localhost) so we don't need to specify the port number.

Level 14—>15

We are asked to submit data to port 30000 on localhost in order to retrieve the next password.

The utility nc (netcat) allows us to “read or write data across network connections using the TCP or UDP protocols”. The basic syntax is: nc [options] host port

The data we needed to send is a file called bandit14 so we used: less bandit14 | nc localhost 30000 to solve this level.

QUESTION: Can I log into LV15 from within the server?

Yes! It worked to use SSH bandit15@localhost! Yay for learning to be more efficient!

Level 15 –> 16

In this level, we are asked to submit “the password of the current level to port 30001 on localhost using SSL encryption”.

Tools to explore: openssl, client_s

s_client will connect to “a remote host using SSL/TLS.”

QUESTION: why does it specify that it connects to a remote host? What about connecting to a service on localhost?

What I tried (unsuccessful):

openssl s_client -connect localhost:30001

I knew this wouldn't work because I wasn't sending the password. But it did say CONNECTED. Unfortunately, it kept waiting for something and I wasn't sure how to interpret this so I looked up a hint online. It turns out it was waiting for a password! There was no password prompt so I didn't think to try sending any input. Had I tried sending _anything at all, I would have received a wrong password message and realized what was happening!

LESSON LEARNED: TRY EVERYTHING!!!

The answer turned out to be: openssl s_client -connect localhost:30001 $PASS (with the password string saved in $PASS)

Level 16 –> 17

In this level, we have to (1) scan for open ports for a server that listens to SSL and then (2) forward the response credentials to login to the next level.

I used nmap -p 31000-32000 localhost to scan for the ports on localhost between 31000-32000 (the range given in the instructions). This returned only 5 active ports (yay!):

Starting Nmap 7.40 ( https://nmap.org ) at 2021-12-31 02:52 CET Nmap scan report for localhost (127.0.0.1) Host is up (0.00033s latency). Not shown: 996 closed ports PORT STATE SERVICE 31046/tcp open unknown 31518/tcp open unknown 31691/tcp open unknown 31790/tcp open unknown 31960/tcp open unknown

Then I manually attempted an openssl s_client connection to each port to see if there would be a response.

I found that port 31790 responded with the credentials (an RSA key). I then created a temporary file containing this key and attemped to SSH into the next level using the method from a few levels back: ssh -i lumpo.private bandit17@localhost

Unfortuately, this did not work because I got this warning back:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: UNPROTECTED PRIVATE KEY FILE! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ Permissions 0644 for 'lumpo.private' are too open. It is required that your private key files are NOT accessible by others. This private key will be ignored.

So now my options are to either (1) set permissions for my temporary file so that it is not accessible by others, or (2) find a way to forward the credentials automatically when they are returned from the server.

Trying (1) first:

chmod 600 /tmp/lumpo.private will restrict my file so that the owner (me) has access to read/write but nobody else can do so. Retried sending ssh with private key after adding this permission restriction and success!

What I could have done better?

Instead of manually testing each listening port with openssl s_client, I should have figured out how to automate it because testing manually would not work for a large pool of ports.