My Confusion Over Local File Inclusion

Absolutely everything on this blog pertaining to the term “hacking” is meant for training and educational purposes only. WE DO NOT ENGAGE IN NOR PROMOTE ANY ILLEGAL HACKING ACTIVITY!

In a world of reels, videos, tutorials, and write-ups, as much as it seems we’re dining at a buffet that’s spread and stretches farther than Interstate 10, there really isn’t a lot of variety among our choices. The flavor of an entree is only exquisite in presentation, design, and delivery.

So I pondered on this and posed the question to myself, “how can I sat a unique flavor out on the buffet table with my contribution?”

The answer ushered an epiphany! From now until infinity, readers of this blog who appreciate lyrics, poetry, and prose are in for a treat. Such will be the manner in which our content will be delivered going forth. It’s our sprinkle of unique contribution to the information and cybersecurity community. We sincerely hope this delightful change will be warmly welcomed by all of our wonderful supporters. You’re awesome and appreciated dearly. Let’s ride!

Local File Inclusion happens when an application that allows user input on the front end isn’t validated properly on the back end. In which case a savvy user who knows a particular file to already be present on the server is able to “include” that file’s name and file path as input on the front-end. For instance, a savy user who knows that the etc/passwd file should be present on a linux server would “include” that file as input. The server would then fetch the file and return it to the user as part of the output. This inclusion is often found in url’s where a parameter variable takes a file name as it’s value. This we’ll see in the examples that follow.

When I initially tampered with LFI and learning how this type of vulnerability could be exploited, it was on a very mechanical level. What I mean by that is although I was able to grab the etc/passwd file per se and so forth, the part that wasn’t particulary clear to me was “path travesal”- that was, until being  faced with a task that required me to think outside of the box to complete it with little help or hints. (And this wasn’t accomplished until I tackled a challenge in HTB Academy’s Certified Bug Bounty Hunter course that covered File Inclusion vulnerabilities, which is presented here as the final challenge in this post.)

The first example covered in this post comes from lab 0x01 of TCM Academy’s Practical Bug Bounty course. As shown in the screen shots below, we have a PHP web application with a drop down feature that allows the user to select an item from a list, fetches the selection from a datasource, then displays the result back to the user.

The first screen shot shows highlighted in the url, the file name – which gives us the type of language the application is using. This is crucially important because if we know what language is being used, we then know how the functions are being constructed within the code.

Back-end languages
use params to
show what’s on the page,
so we can build
dynamic web pages
like a sage.

Reducing sizes
of our scripts
and
simplifying code,
Using params
to specify which
resources get shown.

The next two screenshots depict our front end request being sent over to our proxy, which in this case is Zap. Highlighted is the parameter value in the url that we intend to fuzz.

The second of the two screenshots show the manipulation of the request is being done inside of the Manual Request Editor. (The Manual Request Editor in Zap functions as Repeater would in the Burp Suite Proxy.)

If our functions
are not coded
with
security in mind,
Attackers can manipulate
parameters to find

content
of a local file
that is hosted on the server,
We’re scoping L-F-I
vulnerabilities to merger.

The the screenshots that follow show payload list we chose for our fuzzing attemps. The list here are from the infamous Seclists which is included in the Kali Linux distros by default. If you are on a version of Kali that doesn’t have it included, it can usually be found here available free to download.

(The first couple of screenshots show that we initially chose to use the “pathtotest-huge.txt” as our payload. This was not successful and subsequently we went with the “jhaddix.txt”. The former is only included to highlight the how the many different payloads were constructed- intending to show how the file paths were being traversed, encoded, etc.)

So,
it’s time to take a look,
Let us see what’s all the buzz,
I’ll locate my request
and
the position that I’ll fuzz.

It’s a must to show the haters
cause I know
they don’t believe the kid,
Open Request Editor
it’s something like Repeater is

In Burp,
but I’ll be using Zap
when I be mapping,
web applications
cause
I’m all about this hacking

Like,
I’m all about my macking
but
this subject isn’t loving,
it’s time to see some action
so let’s get back to this fuzzing….

What is it, what’s of it?
don’t act like you ain’t heard this,
Open up the SecList
so that I can pick my wordlist…

L-F-I,
path to test,
huge t-x-t,
I am not the threat actor
so why you sweating me?

But,
that did not work,
so I’ll think I’ll go
with Jason Haddix
when hacking
web applications
some say he’s the baddest.

Next to NahamSec
but I bet those two
do not compete,
Look in on my results
and
check to see if they’re complete.

The Request
and The Response,
yes, now
I can see the etc,
it sounds like etsy
password file so
best that they don’t test me.

It’s just
a basic sample
of a simple L-F-I,
Now provide
a P.O.C
so those who triage can see why….

Finally, as you can see in the above screenshot, our payload was executed and we were successful in our endeavor. Highlighted on the left is our Request and the payload that was successful. Highlighted on the right is our Reponse where we now have the etc/passwd file returned to us.

Note– Although obtaining the etc/passwd file isn’t in and of itself a vulnerability giving that the file is “readable” by all users of the system. It once was in olden days as this was where passwords were indeed stored….in plaintext format. Nowadays passwords are stored encrypted in the etc/shadow file which is only readable by the root user. However, the etc/passwd file is still “useful” to an attacker as it reveals users on the system as well as “human users” on the system which, if there are users on the system who have weak passwords, this could greatly aid an attacker in executing a successful brute-force attack.

Now we’ll have a look at another example.

Our next example is from HTB Academy’s CBBH course.

Let’s say we came across a page like the following. In this hypothetical scenario, our initial task is to find the name of a user on the system that starts with the letter “b”.

Again, in the screenshot we see the parameter and file type of the application highlighted in the url.

Just as we did before we’ll find the parameter to target in our request, send the request to the Request Editor in Zap (again, if you’re using Burp Suite you’ll send the request over to Repeater), find a wordlist of payloads to use, then execute our fuzzer.

In this example we’ll also be using the “LFI-jhaddix.txt” payload list found in the SecLists wordlist.

As you can see in the screenshot below, we were able to retrieve the /etc/passwd file from the application.

It’s important to point out that while multiple payloads from the list would’ve achieved the same result, the payload that’s highlighted contains the “least” amount of directories. It’s good practice to use the least amount of directories in your payloads when submitting your Proof Of Concepts. That will make your findings more clearer for the person who’s doing the triaging on your submission.

(The following screenshots show our Response inside of our proxy as well as how the same Response would appear on the front side of the application.)

Moving on to our final example, our task here was to find the “flag.txt” located in the usr/share/flags directory.

Now that we know that a LFI vulnerability exist and we are able to exploit it to read files already present on the server, all we need to do to locate the flag is to use the same logic that we applied previously to read the /etc/file.

I’d like to point out here that since this was a task from HTB Academy that awards the user cubes for solving it, in order to not violate the rules of the site, and better still, not to spoil the challenge for anyone doing this task, I’ve obscured the full payload that I used in the url and also the flag itself returned on the front. However, I’ll do my best to provide a bit of a hint.

The way I approached it was I didn’t change anything I’d done previously that worked and I just built upon that same logic, exactly where I left off.

In other words, knowing the directory (or path) where the previous payload worked, I crafted a new payload out of the criteria provided in the task.

Perhaps the biggest hint I can provide is that you will not need a payload list but you will need to think outside the box of what you’ve learned thus far about exploiting LFI vulnerabilites.

That’s going to wrap this one up. If you’ve made it this far, thank you very much for reading this post. I hope you were at least able to take something away from it to be of benefit to you in your quest for hunting bugs. At the very least I hope you’ve been entertained. If so, that’s excellent, please share, subscribe, and come back for more. If no, you’re welcome to hit us up and let us know how we can improve.

May peace and blessings be upon you all throughout your journey. Not just in cybersecurity, but also in life.

Hack On, Ladz & Gentz!