Lab 07 — Bandit 15 to 20: TLS, port scans, and borrowed privileges

In Lab 05 you sent the password to a local port with nc. Level 15 looks the same, except the service on port 30001 only talks over an encrypted TLS connection. nc sends plain text, so the service never understands you. You need a client that does the TLS handshake first.

$ openssl s_client -connect localhost:30001 -quiet

When it connects, paste your current password and press Enter. The reply is the next one. ncat --ssl localhost 30001 does the same job if you prefer it.

Why -quiet matters. Without it, s_client treats a line starting with certain letters as a command to itself — R renegotiates, Q quits, k updates keys — instead of sending it. If your password happens to start with one, it never arrives. -quiet switches that off and hides the certificate chatter.

Why this matters. HTTPS, SMTPS, LDAPS and a dozen others are ordinary plain-text conversations wrapped in TLS. openssl s_client is how you talk to any of them by hand — and how you read a server’s certificate when something about it looks wrong.

Level 16 gives you a range — ports 31000 to 32000 on localhost — and nothing else. Several of them are listening. Most just echo back whatever you send. One speaks TLS and answers the password with something useful. Your job is to find it without trying a thousand ports by hand.

$ nmap -sV -p 31000-32000 localhost

the shape of what comes back — your port numbers will differ
PORT      STATE SERVICE      VERSION
3xxxx/tcp open  echo
3xxxx/tcp open  ssl/echo
3xxxx/tcp open  ssl/unknown
...

Read the SERVICE column. Plain echo is out — no TLS. ssl/echo speaks TLS but only repeats you. The one nmap can’t name is your candidate. Connect to it exactly as in step 01, swapping in its port, and paste the password:

$ openssl s_client -connect localhost:PORT -quiet

The right port answers with a private key — a block starting -----BEGIN RSA PRIVATE KEY----- — instead of a password. That key logs you in as bandit17. Copy the whole block, both marker lines included, and save it on your own Linux machine, then lock it down and use it from there:

$ nano bandit17.key

$ chmod 600 bandit17.key && ssh -i bandit17.key -p 2220 bandit17@bandit.labs.overthewire.org

Why this matters. -sV is the difference between “something is listening” and “this is what it is” — the same flag from Lab 01, now doing real work. Mapping which services run on a machine you are already on is a standard move after getting a foothold, and a standard thing for defenders to watch for.

As bandit17 you have two files, passwords.old and passwords.new. They are nearly identical. The password is the one line that changed.

$ diff passwords.old passwords.new

diff prints only the lines that differ. Lines starting < come from the first file, lines starting > from the second. You want the > line — it is in the new file.

Heads up. When you log in as bandit18 you will be thrown straight back out with a goodbye message. That is not a mistake on your part — it is the next step.

Why this matters. “What changed?” is one of the most useful questions in security. Config drift, a tampered file, the one line an attacker added to a startup script — comparing a known-good copy with the current one finds all of them.

Someone has edited bandit18’s .bashrc — the script that runs when an interactive shell starts — so that it logs you out immediately. You can’t fix it from inside, because you never get inside. So don’t ask for a shell at all.

$ ssh -p 2220 bandit18@bandit.labs.overthewire.org cat readme

Anything after the hostname is a command for ssh to run on the other end. It logs in, runs cat readme, prints the result and disconnects — no interactive shell, so the part of .bashrc that kicks you out never fires. Use ls in place of cat readme first if you want to look around.

Why this matters. Running one command over ssh is how most automation, backups and deployment scripts work. And the lesson cuts the other way too: a login script is a convenience, not a security control. Anything it “blocks”, someone can walk around.

bandit19’s home directory holds a program you can run but did not write. Look at its permissions:

$ ls -la

Where you would expect an x in the owner’s permissions, there is an s. That is the setuid bit: whoever runs the program, it runs with the owner’s rights — here, bandit20’s. Run it with no arguments to see how it wants to be used, then prove who it makes you:

$ ./bandit20-do id

Look for euid — the effective user — in the output. Now use those borrowed rights to read the one file you could not read as yourself:

$ ./bandit20-do cat /etc/bandit_pass/bandit20

Why this matters. setuid is how an ordinary user can change their own password in a file only root may write. It is also one of the classic ways to escalate privileges: a setuid program that lets you run other commands hands you its owner’s rights. Checking for unexpected setuid binaries is on every Linux privilege-escalation checklist for exactly this reason.