T A L E O F C H A I N I N G B U G S F O R A C C O U N T T A K E O V E R S B Y : H A R S H B O T H R A 

W H O A M I ? Application Security Enthusiast and Learner Triage @H1 | Core Lead Pentester @Cobalt.io | Community & Product Growth @Akto.io Author – 2 Books | Learn365 | SecurityExplained Blogger | Content Creator| Speaker Bugcrowd All Time Top 200 

A G E N D A Account Takeovers – Vulnerability Class or Impact? Ignored Vulnerabilities – Low Hanging Fruits Tale of Chaining Bugs for Account Takeovers 

P O L L O N T W I T T E R @ H A R S H B O T H R A _ A C C O U N T TA K E O V E R S V U L N E R A B I L I T Y C L A S S O R I M P A C T ? 

I G N O R E D V U L N E R A B I L I T I E S – L O W H A N G I N G F R U I T S Open Redirection CRLF Injection GraphQL Introspection Missing Cookie Security & HTTP Security Headers Host Header Injection API Fuzzing (Lack of Rate Limit on Path) Lack of Server-Side Validation External SSRF Prototype Pollution Deeplink Misconfiguration OAuth Misconfiguration HTML Injection 

T A L E O F C H A I N I N G B U G S F O R A C C O U N T T A K E O V E R S GraphQL Introspection to Account Takeover Host Header Injection to Account Takeover CRLF to XSS leading to Account Takeover Open Redirection to Account Takeover 

G R A P H Q L I N T R O S P E C T I O N T O A C C O U N T TA K E O V E R Bug Description: - The application allowed an unauthenticated user to access and run Introspection Queries (Informative – In General). - After digging and visualising their GraphQL operations, I found a couple of interesting operations allowing to Get User ID by Email and Generate Auth Token using Email. - Authenticated with Attacker User and Performed the Operation using /graphql endpoint to query victim user's ID and later tried using it to get the Auth token but it didn't work. - Next, tried Logical Manipulation (or Parameter Pollution) and supplied IDs like attackerId, victimId and it returned Victim's Auth Token. 

G R A P H Q L I N T R O S P E C T I O N T O A C C O U N T TA K E O V E R ( C O N T ' D. . . . ) Bug Description (Cont'd...): - Using victim's auth token, changed their email address to Attacker Controlled Email and reset their password and had full control of their account. Severity Bump: Informative to Critical Program & Platform: Private Program (Out of Platform) Reward Issued: $$$$$ (5-Digit) 

H O S T H E A D E R I N J E C T I O N O N E M A I L C H A N G E T O A C C O U N T TA K E O V E R Bug Description: - The application shared the same interface for external and internal users. The point of validation was the internal user's had their accounts with @company.com and some extra privileges. - I had access to one of their GSuite account as part of a Pentest engagement. - I tried Host Header Injection (mainly on password reset as we all do) but no luck on any endpoints. - Next, I fuzzed the application using Collaborator Everywhere and observed that this email change endpoint was reflecting the External Host via X-Forwarded-Host header. - Using the attacker account (external user), I requested an email change for [email protected] with attacker controlled Host. 

H O S T H E A D E R I N J E C T I O N O N E M A I L C H A N G E T O A C C O U N T T A K E O V E R ( C O N T ' D . . . ) Bug Description (Cont'd...): - I was able to steal the confirmation token and use it to change email to my attacker (external user) account. - Relogged in and got the privileges escalated to internal user dashboard that allowed to reset the password for any external user. Result: Mass Account Takeover Severity: Critical Program and Platform: Private (Through Pentest) Award: Bonus in $$$$ 

C R L F T O X S S L E A D I N G T O A C C O U N T TA K E O V E R Bug Description: - The application was vulnerable to Self Cross-Site Scriptingvia Non-Existing Cookie Parameter. (Informative). - Fuzzed the application and found it vulnerable to CRLF Injection through double encoding. - Used CRLF Injection to Inject the Non-Existing Cookie Parameter and Created a PoC like: something.com/=cookie: - XSS was executed successfully (Medium) - Now, further created a PoC to steal session token as the JWT was passed in the Cookies as well and there was no HTTPOnly flag. - Successfully Hijacked User's Session – Changed Email – Reset Password – Full Account Takeover. 

C R L F T O X S S L E A D I N G T O A C C O U N T T A K E O V E R ( C O N T ' D . . . ) Result: Full Account Takeover Severity: Informative to Critical Program and Platform: Private Award: $$$$ + $$$ (Bonus) 

O P E N R E D I R E C T I O N T O A C C O U N T TA K E O V E R Bug Description: - The application had multiple sub-applications and it used Auth Code to authenticate the sub applications and it was possible to access the sub-applications allowing account takeover. - The redirection to sub-application was using OAuth flow and had redirection parameter that sent the auth token to the sub-application - Found an open redirection that allowed to steal the auth token of the application. - Attacker was able to successfully access the sub application. (High) - Later, I also found an privilege escalation that allowed access from Sub-App to Main-App but that's a different Privilege Escalation Story. 

O P E N R E D I R E C T I O N T O A C C O U N T T A K E O V E R ( C O N T ' D . . . ) Result: LimitedAccount Takeover Severity: High Program and Platform: Private Award: $$$ 

O T H E R I N T E R E S T I N G AT O V E C T O R S • HTML Injection to AWS Metadata Leak leading to AWS Takeover • Insecure Deeplink allowing Account Takeover • Password Reset Poisoning to Account Takeover • Mass Assignment Leading to Account Takeover • IDOR leading to Account Takeover • Lack of Server-Side Validation in Email during Registration leading to Account Takeover 

N E X T P L A N S ? W I L L L A U N C H A N U P D A T E D M I N D M A P O N D I F F E R E N T T E C H N I Q U E S F O R A C C O U N T T A K E O V E R 

S U M M A RY 

T H A N K YO U F O L K S !