OverTheWire Bandit Guide

Previous Level Guide: Bandit Level 15 → 16

Access

SSH: ssh bandit16@bandit.labs.overthewire.org -p 2220

Password: knnW8msaRxaAN7adaEg07rkKnqrQ5Yky

Info

Description: The credentials for the next level can be retrieved by submitting the password of the current level to a port on localhost in the range 31000 to 32000. First find out which of these ports have a server listening on them. Then find out which of those speak SSL/TLS and which don’t. There is only 1 server that will give the next credentials, the others will simply send back to you whatever you send to it. Helpful note: Getting “DONE”, “RENEGOTIATING” or “KEYUPDATE”? Read the “CONNECTED COMMANDS” section in the manpage.
Commands: ssh, telnet, nc, ncat, socat, openssl, s_client, nmap, netstat, ss

Theory

To get the password, the instructions say that we have to search between the ports 31000 and 32000, then there should be only one that wont give you the same response back, that might be important. To find the port, we need to use Nmap, that just maps the ports to see which are active and report them to the user, then use -sV option to also tell us other stuff like their service and version. Then after we found the port using Nmap, we'll use openssl s_client just like the last time to connect to the port interface, give it the password, and get the next password. So the commands should be like this:

nmap -sV localhost -p 31000-32000
openssl s_client -connect localhost:3????

Gonna leave that port with question marks because we don't know the port yet.

Solution

Now you just have to get into the level and do the command:

~$ nmap -sV localhost -p 31000-32000
Starting Nmap 7.94SVN ( https://nmap.org ) at 2024-11-27 04:26 UTC
Nmap scan report for localhost (127.0.0.1)
Host is up (0.00019s latency).
Not shown: 996 closed tcp ports (conn-refused)
PORT      STATE SERVICE     VERSION
31046/tcp open  echo
31518/tcp open  ssl/echo
31691/tcp open  echo
31790/tcp open  ssl/unknown
31960/tcp open  echo

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 162.79 seconds

So as said before, the only port that doesn't give back the same information, aka the ones that don't say echo, is port 31790, or also the only one that doesn't echo back your own responses. So now we just keep going with the SSL command:

~$ openssl s_client -connect localhost:31790
CONNECTED(00000003)
Can't use SSL_get_servername
depth=0 CN = SnakeOil
...
read R BLOCK
knnW8msaRxaAN7adaEg07rkKnqrQ5Yky
Correct!
-----BEGIN RSA PRIVATE KEY-----
MIIEogIBAAKCAQEAvmOkuifmMg6HL2YPIOjon6iWfbp7c3jx34YkYWqUH57SUdyJ
...

If you get something like "DONE" or "KEYCHANGE" or basically anything that is not the private key it's probably because the password starts with a "k", so the server thinks you're doing a command or something like that, so it throws you an error, to prevent this and also make it remove all errors we can use the -quiet option (-quiet specifically goes before -connect for some reason, I really don't know why), so the command comes down to this:

~$ openssl s_client -quiet -connect localhost:31790
Can't use SSL_get_servername
depth=0 CN = SnakeOil
verify error:num=18:self-signed certificate
verify return:1
depth=0 CN = SnakeOil
verify return:1
knnW8msaRxaAN7adaEg07rkKnqrQ5Yky
Correct!
-----BEGIN RSA PRIVATE KEY-----
MIIEogIBAAKCAQEAvmOkuifmMg6HL2YPIOjon6iWfbp7c3jx34YkYWqUH57SUdyJ
...

If this still doesn't work for you, just put echo and a pipe character before the openssl to automatically print the password and not produce as many errors as manual type, but if this doesn't work, then there's definitely something wrong, it's just a lost case:

~$ echo "knnW8msaRxaAN7adaEg07rkKnqrQ5Yky" | openssl s_client -quiet -connect localhost:31790
Can't use SSL_get_servername
depth=0 CN = SnakeOil
verify error:num=18:self-signed certificate
verify return:1
depth=0 CN = SnakeOil
verify return:1
knnW8msaRxaAN7adaEg07rkKnqrQ5Yky
Correct!
-----BEGIN RSA PRIVATE KEY-----
MIIEogIBAAKCAQEAvmOkuifmMg6HL2YPIOjon6iWfbp7c3jx34YkYWqUH57SUdyJ
...

Now, I didn't expect to get a private key, but it doesn't get much different, we just need to create a new file in a temporary directory that the next level's user can access, then paste the private key in there and send it to the next level to enter it. So like we've done before, let's make a new temporary directory to create the file:

~$ mktemp -d
/tmp/tmp.rYDp9jsZkG

~$ cd /tmp/tmp.rYDp9jsZkG

Now you can use either vim or nano, whatever you prefer, I'm just gonna give you a quick rundown of these two. When you create the file with vim you will paste the private key, if it doesn't type anything use the escape key to start writing and try pasting again, then to get out click the escape key and when the cursor looks like is one space behind the last character you will type :wq which is the command for both saving the file and exiting the editor. When you create a file with nano you will paste the private key, then use Crtl+O to save and then Crtl+X to exit nano. Now with these, we can continue with making the file (I will be using vim because I don't have Ctrl in my iPad):

/tmp/tmp.rYDp9jsZkG$ vim privkey

*paste the password in vim editor*
:wq

/tmp/tmp.rYDp9jsZkG$ chmod 777 privkey

ssh -i privkey bandit17@bandit.labs.overthewire.org -p 2220

What I just did there was change the permissions of privkey so that everyone can see it, that way entering the next level wont fail in some weird way.

IMPORTANT: Now that you're inside bandit17, you're gonna want to keep this session open because the only way to enter the next level is with the private key in this level, and that includes everything about the directory and vim/nano file, because it's a temporary directory.