$600 Vulnerability: My First Bug Hunting Journey

This happened about (more than) a year ago, so I don’t really have all the documentations of what happened. All parties involved have given me permission to share this story with you all.

Source: trust me bro.

I was just browsing around the internet, looking for some online *REDACTED* tools/utility site, until I stumbled upon this website.

At first glance, there doesn’t seem to be anything wrong with it. That is, until you actually convert a file. Something immediately sets off an alarm in my mind, all because of this one tiny insignificant thing:

You don’t see it yet? It’s the parameter. Why’s the file parameter in force_download.php pointing to something that looks like a directory? Well, I tested that theory and tried accessing the upload/ directory, to my surprise, the file was there.

“Well, there’s no way this parameter is unfiltered, right? Just out of curiosity, what would happen if I, say, changed the parameter to index.php instead?”

…, wha-

Part 1: Path Traversal

What is a Path/Directory Traversal vulnerability? Well, as the name suggests, it’s a vulnerability in web applications that allows an attacker to be able to arbitrarily read files on the web server.

When this happens, sensitive information (like server config files) is located on the outside of the web directory. That’s why this attack is also called “dot-dot-slash” (../), or backtracking.

The code that was used in force_download.php must’ve been something like this:

I immediately contacted the website’s owner to inform them about the vulnerability I had randomly stumbled upon. I later realized the website was owned by a larger company.

Thankfully, they responded within an hour, thanking me and asked if I could do a thorough penetration test (pentest), as their website had been hacked several times before.

Part 2: Boring Stuff (Reflected XSS, SQL Injection)

This is probably the simplest part of all, because all I did was run a broad vulnerability scan on all the listed in-scope sites that the company gave me. I usually use Burp Suite and Nuclei to handle all the automation and go from there.

Even though a high number of them are false positives, a lot of them are still true positive. This is mostly because the company is using an old CMS framework, the only solution is just to upgrade the CMS to a newer version.

Part 3: Arbitrary File Read (CVE-2022–44268)

Now this is where it starts to get interesting. CVE-2022–44268 is a vulnerability caused by ImageMagick. There’s actually another part of it, CVE-2022–44267, a vulnerability also caused by ImageMagick’s PNG parsing, but it’s a Denial of Service attack, not so interesting.

This arbitrary file read vulnerability is caused by ImageMagick trying to read a “Profile” tEXt (Textual data) chunk (read here for PNG specs — it’s a lot to take in), and tries to insert the chosen image profile into the PNG. The only problem is that, well, an attacker can control the Profile tEXt, hence, arbitrary file read (read here for further vulnerability breakdown).

I just inserted a Profile tEXt chunk using python with the help of png library, and set the payload for which file I want to read, in this example I used /etc/passwd.

And after sending it to the website for converting, resizing, or basically anything that requires ImageMagick to parse this PNG, I got an innocent image back. But, if you look deeper into the image (funnily enough using identify, part of ImageMagick itself):

I got a load of hex characters on “Raw profile type” key, and if you try to decode it:

Voila! You got the content of /etc/passwd just by uploading an image. This method could read any file as long as ImageMagick has the required permission to read it.

Part 4: LaTeX Injection

At this point, I haven’t actually found any critical vulnerability the company wants me to find — an RCE vulnerability (I couldn’t get an OS shell from the SQL injection). So I stopped mindlessly poking around and tried to approach it more methodically.

Kindly enough, they gave me a list on which endpoint was accessed the most on the day they got hacked. One of them stood out amongst the others.

“What’s LaTeX?”

Apparently, LaTeX is a programming language for document typesetting, weird, I know. They used it as a service for online LaTeX editor on their website. This, on a glance, didn’t look like much, but the keyword “programming language” is so interesting not to check out.

“Who, in their right mind, would expose an old programming language, that is running on their server?”

And I finally looked it up, “LaTeX Injection”, it actually exists, the man, the legend, the myth itself.

“Well, let’s just copy this weird-looking command and see what happens.”

“Ah, phew, it’s filtered. Time to look for the other endpoints, I guess.”
“…”
“What’s this? Replace a character with it’s Unicode hex value? Surely that won’t work, righ-”

Yeah, so…, that works. After a bit more digging, I also found out that almost every single parameter in the request to convert LaTeX to image is susceptible to LaTeX Injection.

And for the finale, I just crafted a malicious PHP payload to be written wherever this LaTeX is called from. At first I thought it might be a challenge to find where this TEX file is located, but apparently it’s just somewhere on the upload/ folder where the file is going to be downloaded.

Part 5: Resolution

In total, for all critical, medium, and low severity vulnerabilities I’ve found, I cashed out around $600. That is considered low for a cyber security job, but considering how new I was and this is not some major corporation, I’d say all parties are happy with what they get.

With all that being said, I hope this story could inspire people to get into tech, especially cyber security and bug hunting. Remember kids to always hack ethically. So, get out there, stay curious, and make the internet a safer place — one bug at a time.