Account Linked Domains Takeover

During a recent security assessment of an advertising platform, I discovered an intriguing functionality inherent in the application’s domain management system. When a user registers with a company domain (e.g., @domain.com) instead of a personal email, the application automatically links their account to a group associated with that domain. This setup means that the first user with @domain.com to register becomes the owner of the domain.com group, and any subsequent users with the same domain automatically join that group.

After initial testing, I began exploring what might happen if I altered my email address partway through registration. Specifically, if I changed my email on the Single Sign-On (SSO) platform after confirming my account on the advertising platform but before the group creation step, I wondered if I could link an unauthorized domain to my group.

However, this process wasn’t straightforward — I needed to re-sync the email change from the SSO platform to the advertising platform. Fortunately, I had previously discovered an API endpoint that enabled me to sync user emails. This endpoint would allow me to synchronize the email update with the advertising platform just before completing the group creation step.

Here’s the workflow I devised to take advantage of this flaw:

Register an Account on the SSO Platform: Start by creating a new account using a disposable @domain.com email address (e.g., from sharklasers.com, provided by Guerrilla Mail). This disposable email serves as a way to test domain linking without using a real corporate email.Sign Up on the Advertising Manager: Using the SSO account created in the first step, sign up on the advertising platform. At this point, the platform recognizes sharklasers.com as a unique domain and prepares to assign it to a new group under my control.Confirm the Email on the Advertising Manager: The advertising platform sends a confirmation email. Upon confirming, the domain (sharklasers.com) is associated with my organization, making me the owner of any accounts using this domain on the platform.Change the Email on the SSO Platform: Before completing the group creation on the advertising platform, return to the SSO platform and change the email to an unauthorized domain (e.g., @unauthorized.com). The SSO platform does not require email re-verification, making this step possible without any additional confirmation.Sync the Email Change Using the Advertising Platform’s API: With the email updated in the SSO, use the following API request to sync the new email with the advertising platform:curl "https://redacted.com/graph/analytics" -X POST -d "{\"operationName\":\"SyncUserEmailWithAccount\",\"variables\":{},\"query\":\"mutation SyncUserEmailWithAccount { syncUserEmailWithAccount { success __typename } }\"}" -H "Content-Type: application/json" -H "Authorization: Bearer Your-Token-Here"

6. Complete the Group Creation on the Advertising Platform: Once synced, i proceeded with group creation. Now, the advertising platform incorrectly associates the unauthorized domain (unauthorized.com) with my organization, allowing me to control all future users who sign up with that domain.

After submitting a detailed report and carefully analyzing the impact and exploitability, the final result was that the report was marked as informative by the advertising platform’s security team. While the vulnerability highlighted a flaw in the domain verification flow and allowed some degree of control over user associations, the team determined that the overall impact and risk were not sufficient to classify it as a security issue requiring remediation

Even though it wasn’t accepted as a valid security risk, it was still rewarding to have figured out a way to bypass the domain verification flow and exploit the group association process. This experience highlighted the potential of leveraging unverified email syncs and automatic group assignments. Had I been able to infiltrate other groups or access more sensitive areas, the impact could have been significantly greater. It’s a reminder of how even “informative” discoveries can lead to deeper insights and potentially higher-impact vulnerabilities with a bit more exploration.

I hope this write-up has provided you with a fresh perspective on exploring application workflows and finding creative approaches to test for potential vulnerabilities. Even when reports don’t lead to bounty rewards, there’s always something valuable to take away from the experience. Thanks for reading!