To view older blog posts, please visit the archives section.

Reality check

Like it or not, every software vendor has, at some point, and continues to, publish vulnerable code. This is true no matter the industry, stock value, reputation, or the position of their products on the famous Gartner Magic Quadrant.

You can either acknowledge this reality or choose to live in a world of unicorns and rainbows.

As I was going through my information feed for newly published vulnerabilities this morning, I came across a newly published CVE for a bug that was fixed back in November 2024. I don't generally hold much interest in closed-source, cloud-based software, as the code is not available—even for reverse engineering. But CVE-2024-11146 is a reminder that the size and reputation of a software vendor are in no way, shape, or form a guarantee of either security or insecurity (yes, this goes both ways) of their products.

Now, before we dig in, please be careful and do not twist my words: nothing I have said above, or will say below, implies that any of the products, vendors, or organizations mentioned are "bad" or have, or promote, bad practices in any way, shape, or form. This could be any piece of code. Any.

CVE-2024-11146 is simply one of those examples that should remind us that nothing in life is absolute and that everything can, and should, be questioned.

What's CVE-2024-11146?

CVE-2024-11146, from its description, is best classified as an IDOR-like vulnerability in TrueFiling. It was discovered by Alison Breacher, from what I could find, a researcher associated with CSIRT.global. Here is a copy of the vulnerability description:

"TrueFiling is a collaborative, web-based electronic filing system where attorneys, paralegals, court reporters, and self-represented filers collect public legal documentation into cases. TrueFiling is an entirely cloud-hosted application. Prior to version 3.1.112.19, TrueFiling trusted some client-controlled identifiers passed in URL requests to retrieve information. Platform users must self-register for an account, and once authenticated, could manipulate those identifiers to gain partial access to case information and the ability to partially change user access to case information. This vulnerability was addressed in version 3.1.112.19, and all instances were updated by 2024-11-08."

Warning: Everything that follows is exclusively based on my reading of the vulnerability description. I have not had access to the system itself, nor do I have any privileged information surrounding this vulnerability.

What does this say about the vulnerability?

Basically, the TrueFiling solution is a web-based platform where users submit court-related documents. Additionally, the platform appears to allow users to view documents. When doing so, a URL similar to the following (hypothetical) example could be used:

• https://example.truefiling.imaginarydomain.law/readdocument/myImaginaryUserID/12345

In this example, the endpoint readdocument is accessed, with the user ID (myImaginaryUserID) and a document ID (12345) embedded in the URL. This document is then displayed for the user.

For a regular user and even many programmers, this URL structure seems normal (and really it is). For anyone with security assessment or vulnerability research experience, this URL screams: Try modifying the user ID—there's a chance you might access other users' documents. It practically begs to be tested.

Well, in the case of CVE-2024-11146, it turns out that a very similar URL structure (probably) existed, was tested, and was confirmed to be vulnerable.

Why was the software vulnerable?

Simply put, a piece of software in the document retrieval process trusted user-controlled identifiers in the URL when it should not have, as these identifiers can be manipulated by the user. This issue frequently occurs in large software systems where data is passed between components and too much trust is put between these. Ultimately, the backend system provides the requested information without properly verifying the initial requester's identity. 

Here's an illustrated example relating to this specific case based on the previously mentioned URL:

What's the lesson here?

TrueFiling is developed by a large and reputable software publisher. This software, along with many others from its parent company (I3 Verticals, a publicly traded company under NASDAQ: IIIV), is widely used by government entities in various sectors, including public safety, transportation, and, in the case of TrueFiling, the justice system.

I3 Verticals' clients generally have rigorous software acquisition policies, including security practice reviews of vendors. Yet, even with such policies in place, vulnerabilities—so trivial that even a non-technical user could exploit them (hello, grandma!)—can hide for years, before being discovered, in enterprise-grade software.

Conclusion

Every software contains vulnerabilities. I have been analyzing software for 13 years now, and I have yet to conduct a security review without finding something that could be improved or fixed. Of course, I don't always uncover the "holy grail" of vulnerabilities, but there is always something.

This reality applies to both in-house and third-party software. Every—let me repeat, EVERY—software vendor has to face this truth: somewhere in their code, a vulnerability exists.

Depending on your role, this should mean different things to you. I'll let you draw your own conclusions...

Stay safe!