CVE-2024-53553
Authentication Bypass in FOIAXpress® Public Access Link (PAL)
While doing bug bounty on HackerOne back in August, I uncovered a vulnerability in the FOIAXpress® PAL application from OPEXUS, which can integrate with payment solutions, including pay.gov for federal clients. This vulnerability, classified as an Execution After Redirect (EAR) flaw, allows unauthenticated users to bypass authentication mechanisms, potentially spoof emails, and submit requests on behalf of other users.
Discovery Process
I think we all have out own methodology when it comes to bug bounty, so I won’t fill this post with my own. Some things I think would be worth stating are the key events that led to me testing for this specific vulnerability.
Whenever doing research on commercial off-the-shelf (COTs) software, I like to try to find any sort of documentation. These references are a great source of information for attackers. While trying to break the application, we need to know just as much if not more about it than the developers. By reading the documentation, we can figure out what users are “suppose to do”, which might cue us in on what we shouldn’t do - or should to find some bugs. To that point, while there was some documentation avalible online, I couldn’t find anything super useful outside of the applications home and help pages, which did give me some useful hints, such as:
The home page of the application tells us, we “MUST” register or sign-in to make requests through the portal. As per usual when looking through documentation, I noted this down. Because, if the application is telling us we MUST be authenticated to make these requests, and were able to do that without authenticating, then thats a bug!
How it unfolded
-
I captured a request to an authenticated endpoint using Burp Suite.
-
The server responded with a 302 redirect, instructing the client to log in.
-
I intercepted the response and modified the 302 code to 200 OK and forwarded it to the browser.
Gaining Unauthenticated Access
The application now treated me as if I were authenticated, granting access to the submission page.
Manipulating Submission email
Normally, when authenticated, this page will auto-fill the email of the current user, but since we werent authenticated, I could specify any email address in the email field, effectively impersonating another user.
Email Validation Abuse
To further compound the issue, I discovered another endpoint that validated email addresses.
Using this, I could verify valid email addresses on the application before submitting impersonation requests.
Lessons Learned
With this being my first CVE, I have learned a few things I felt may be useful to share with others on a similar journey:
- Understand the submission process for new CVEs before submitting and be patient.
- Vendors can be hit or miss. Do your due diligence as a security researcher and again, be patient.
References
- https://github.com/RoseHacks/Vulnerability.Research/tree/main/CVE-2024-53553
- https://infosecwriteups.com/exploiting-execute-after-redirect-ear-vulnerability-in-htb-previse-92ea3f1dbf3d
- https://www.cve.org/CVERecord?id=CVE-2024-53553