Authentication Bypass via Email Domain Suffix Manipulation
Introduction
Authentication is the process of verifying the identity of a user, system, or entity to ensure they are who they claim to be before granting access to resources. This process involves presenting credentials, like usernames and passwords, and validating them against a trusted source. Authentication is a crucial security measure, helping to protect systems, data, networks, and applications from unauthorized access and potential attacks.
However, there are multiple ways authentication can be bypassed. Sometimes, it can be due to SQL injection,SSRF, IDOR, default login credentials, access control bugs, and even blind XSS can help to bypass authentication.
Vulnerability Discovery
In this write-up, I will explain how I found this bug in detail.
A few months ago, I found an interesting internal application via recon. Initially, I left that domain because there was a strict login enforced via the front-end, and I did not see much to test. I tried a few things like default credentials and analyzed the JavaScript files but didn’t find much.
Another day, I decided to test it again.
I started playing with the registration and login fields and collected all the HTTP requests. Then I noticed something interesting — a prefix was added to the entered email address.
In the frontend, I entered:
Then, I replaced the domain part to via http request using the burp suite:
Since it was checking emailSuffix only. Like redacted.com and other internal domains.
I checked my email, and to my surprise, it was successfully registered! I received the confirmation email and was able to verify the account.
At first, there wasn’t much to see just the application field to submit an application. But after sending an application, I tried to modify it to other users’ applications.
And… I was successfully able to access other users’ applications too!
Additionally, after submitting an application, it was supposed to be approved by admins.
But what if we could approve those applications ourselves?
Well, I was able to self-approve my own application!
Normally, after submitting an application, it should require approval from another admin. However, due to insufficient access controls, I was able to assign the request to myself and approve it without any oversight, effectively bypassing the intended approval workflow.
This kind of vulnerability can lead to privilege escalation and unauthorized access, especially in systems where approvals are meant to act as a safeguard.
Moreover, via different API endpoints, I was able to leak all internal information — users, admins, partners — including sensitive documents, devices information and more.
While using the frontend, I could only access applications. However, using the API endpoints, I was able to perform full CRUD actions as an admin — meaning I had full privilege over the system.
Impact
- Full authentication bypass
- Unauthorized access to all users’ and admins’ sensitive data (PII exposure)
- Ability to perform CRUD operations as an admin
- Access to internal documents and applications
- Ability to self-approve critical workflows (e.g., applications)
Key Takeaways
- Always validate and sanitize user input, even at the backend.
- Never trust only the frontend for authentication or input handling.
- Secure API endpoints separately with proper access controls.
- Regularly audit registration and authentication flows for unusual behavior.
- Small bugs like email domain mishandling can lead to major security breaches.
Timeline:
Reported →17 Mar 2025 16:46:10 UTC
Triaged →18 Mar 2025 22:46:19 UTC
Resolved →15 Apr 2025 16:02:17 UTC
Comments
Post a Comment