Breaking into the Vault: A Mind-Blowing Local File Inclusion in a Major Enterprise Application 🔥💻

Goutham A S
3 min readSep 24, 2024

--

Introduction:

Picture this — I’m sitting in front of my screen, caffeinated to the max ☕, and digging into the inner workings of a large enterprise’s web application. This isn’t just any ordinary company; we’re talking about one with millions of users, tons of sensitive data, and security that’s supposedly tighter than Fort Knox 🏰. But, as always, the deeper I dive, the more I realize: there’s always a way in.

That’s when I stumbled upon a Local File Inclusion (LFI) vulnerability so complex, so intricate, it’s like trying to find the secret entrance to a hidden treasure chest buried within layers of convoluted code 🗝️. Buckle up, because this is going to be a wild ride.

The Setup ⚙️

So, I start off poking around the typical areas — user inputs, URL parameters, the usual suspects. Nothing too crazy at first glance, just another day in the life of a bug bounty hunter. Then, I noticed an endpoint that seemed to dynamically load resources based on user input:

GET /corporate/resources/view?file=report_2024.pdf HTTP/1.1
Host: bigcorp.com

Simple enough, right? Just a basic endpoint to fetch PDF reports based on filenames. But, my hacker sense 🕵️‍♂️ was tingling — this smelled like a potential LFI waiting to happen.

Cracking the Code 🧩

The typical LFI attempts like /etc/passwd were going nowhere. BigCorp had implemented filters that made standard exploitation laughably futile 😑. I had to think deeper, so I did what any self-respecting hacker would do – I started fuzzing the hell out of that parameter.

After numerous dead ends, I realized they were using some kind of obscure, internal routing system. Basically, the file parameter was being run through several layers of sanitization. But, here’s the kicker — each sanitization layer had subtle bugs that could be bypassed if you hit them just right. It was like peeling an onion, except each layer reeked of over-engineered security mechanisms 😅.

The Ingenious Payload 💡

I finally struck gold after some trial and error when I crafted a request that bypassed the internal routing filters. Here’s what worked:

GET /corporate/resources/view?file=../../../../../../proc/self/environ%00 HTTP/1.1
Host: bigcorp.com

That’s right — I wasn’t just reading files; I was now deep inside the guts of the app’s environment variables 😈.

But the game didn’t end here. Oh no, things were about to get way more fun.

Pivoting into the Vault 🔐

Accessing the environ file let me extract a juicy detail: the application was using a hidden admin API endpoint that could only be accessed by internal services. It looked like this:

POST /internal/admin/exclusive_endpoint HTTP/1.1
Host: api.bigcorp.com
Authorization: Bearer <MagicToken>

The token was supposed to be secure, but guess what? I LFI’d my way to an access token embedded deep within the environment variables 💣.

I sent a request with this stolen token:

POST /internal/admin/exclusive_endpoint HTTP/1.1
Host: api.bigcorp.com
Authorization: Bearer MagicTokenFromEnviron

Boom 💥! I now had access to internal admin functionality that could manipulate server-side file operations. I could upload, modify, or delete files at will.

The Grand Finale 🎉

Using the admin endpoint, I gained access to internal configuration files, databases, and even parts of their CI/CD pipeline. Now, most LFIs would stop here, but I didn’t. Remember, I wanted to do something epic 🤓.

I realized I could modify a specific server script used by their internal DevOps team. By injecting my payload into one of these scripts, I set up a remote code execution (RCE) vector that was triggered during their next deployment cycle 🚀. They literally deployed my shell without even realizing it.

The Takeaway 🧠

This isn’t your everyday LFI — this is a multi-stage exploit that required knowledge of internal systems, multiple bypasses, and even abusing environment variables to steal tokens. This attack combined elements of LFI, privilege escalation, and RCE to compromise the entire application stack.

In the end, I notified BigCorp, and they patched everything, but the thrill of unearthing such a complex vulnerability? Unmatched 😎.

Conclusion:

So the next time someone tells you LFI is “just about reading local files,” send them this blog. I promise, they’ll be rethinking everything they know about application security after reading about this vault-breaking vulnerability 🏴‍☠️.

P.S. Never underestimate the power of obscure bug combinations, and always keep pushing the boundaries. You never know what treasure lies just beneath the surface 💼🔎.

--

--

Goutham A S
Goutham A S

Written by Goutham A S

Assistant Manager - Information Security | Ethical Hacker | Penetration Tester | Blogger | SAST | DAST | API Security | AWSOps | AZ-500 | Reverse Engineering

No responses yet