An OSCP journey without using METASPLOIT — HTB Shocker#4

So, Day 4 lands on Friday 24th April, Still in lockdown and without a view of ending anytime soon. Therfore to keep spirits high we continue on the jouney to OSCP 2020 prep in 60 days without using metasploit (the best we can) I will try and do and week summary of all the useful concepts that the last few boxes have taught us .

10.10.10.56

Recon

two ports open on intial scan

For port 80 I run Nikto and Dirbuster against the host.

I googled CGI Bin

Now we know that “cgi-bin” utilises scripts, I attempted to locate any scripts/files that may be in this “cgi-bin” directory, I also found this quite helpful (https://serverpilot.io/docs/how-to-create-a-cgi-bin-directory/) The below shows me running the dirb tool with my custom script to search for file extensions. Note you have a the simular text file with these extentions in the following path “/usr/share/dirb/wordlists/(vulns)” I have updated mine through time with various different other fuzzing lists through doing bug bounty, heres a useful github repro with some fuzzing payloads https://github.com/danielmiessler/SecLists/tree/master/Fuzzing

Dirb found /cgi-bin/user.sh

I also like to use “FFUF” (https://github.com/ffuf) for fuzzing it was alot quicker than dirb and I prefer the colourful output, makes seeing “200” response codes alot easier.

200 response code for .user.sh

Viewing the contents of “user.sh”

Downloading the contents of the found script

Content of script

After about an hour to an hour and half wasted on rabbit holes and enumeration I finally starting to make some sense of the pathway in.

Google for cgi-bin vulns

After seeing results for the common vulnerability that was identified back in 2014 called “Shellshock” and considering the name of this box is “shocker” light bulbs shone bright, so I did a quick scan to identify for Shellshock and other web based vulns.

Shellshock is a bash remote code execution vulnerability. This vulnerability affected web servers utilizing CGI (Common Gateway Interface), which is a system for generating dynamic web content. This usually involved directories such as /cgi-sys, /cgi-mod, /cgi-bin, etc. /cgi-sys and /cgi-mod do not exist on the web server. cgi-bin does

NOT vulnerable to heartbleed

Now let us test shellshock. Shellshock is a security bug causing Bash to execute commands from environment variables unintentionally. In other words if exploited the vulnerability allows the attacker to remotely issue commands on the server, also known as remote code execution.

To test for Shellshock I found this awesome tool a while back called Commix http://commixproject.com

This tool identifies the user agent header is vulnerable to code injection shell shock vulnerability

The tool is quick to identify the user agent header is injectable, it also asks me if I want some form of shell however this is training for the OSCP therefore we should take some time to understand how to exploit this manually .

I Used Curl to echo the content of the passwd file via RCE

Having access to the passwd file is pratically game over. This confirms we have code injection the first thing I like to do is view if netcat is installed as it makes life easy transfering files.

Netcat is present on the machine under /bin/nc

Shellshock reverse tcp shell payload

We caght an unstable shell.

Now I have a shell a the user “shelly”, I need to elevate to root. Use the sudo -l command

Perl Reverse Shell

I am Root

search for which languages exist on the box

Python3 is present in /usr/bin

python3 -c 'import pty; pty.spawn("/bin/bash")'

Gives us a more interactive stable shell. I navigate to /root/root.txt

33 chars same lenght as md5hash :)

Bonus Section Real World Gaining a Meterpreter shell via MSF

If you havnt used meterpreter before now may a good time to go back and exploit this via metasploit so the practice is there for real world (should you ever come across shell shock in the wild?!) https://www.rapid7.com/db/modules/exploit/multi/http/apache_mod_cgi_bash_env_exec

msf > use exploit/multi/http/apache_mod_cgi_bash_env_exec
msf exploit(apache_mod_cgi_bash_env_exec) > show targets
    ...targets...
msf exploit(apache_mod_cgi_bash_env_exec) > set TARGET < target-id >
msf exploit(apache_mod_cgi_bash_env_exec) > show options
    ...show and set options...
msf exploit(apache_mod_cgi_bash_env_exec) > exploit

I thought this box was pretty epic as we had to manually exploit shellshock which is a very well known vulnerability therefore its would be very easy to use metasploit to gain a meterpreter shell which is what you would probably do in the real world should you come across this vulnrability which is unlikely.

Summary

• Insecure web misconfiguration allowed attackers to identify critical files within directories. Although the access to “/cgi-bin” was restricted using fuzzing techniques it was possible to identify “user.sh” for more info visit https://owasp.org/www-project-top-ten/OWASP_Top_Ten_2017/Top_10-2017_A6-Security_Misconfiguration

Security Misconfiguration A6 OWASP 2017 highlighted text shows unprotected files

• The web server was executes bash commands on a system that isrunning a version of Bash that was vulnerable to the Shellshock vulnerability. This allows attackers to gain initial access to the system. To remediate patches should be applied for more info on shell shock read up on, https://owasp.org/www-pdf-archive/Shellshock_-_Tudor_Enache.pdf
• Insecure configuration and lack of privelege seperation. Once I gained a shell a the User “Shelly” Shell

Thats 4 machines in 4 days a total of 8 flags found, 4 users and 4 Roots, all exploited manually without using metasploit. I hope you learned something from this box, this was my favourite so far. Keep hacking stay safe.