Single-click account takeovers are made possible by taking advantage of quirks in OAuth
It is possible to perform single-click account hijacking by abusing the OAuth process flow, a security researcher has found.
OAuth, also known as Open Authentication, is a framework for managing identities and securing online areas across third-party services. Rather than leverage an account username and password combination, for example, service providers can utilize OAuth to provide temporary and secure access tokens.
However, in some scenarios, attackers can abuse OAuth implementations to steal these tokens and perform one-click account hijacking.
On July 6, Frans Rosén, Security Advisor at Detectify, walked us through several potential attack vectors and how organizations can mitigate the risk of compromise.
Rosén describes these scenarios as “dirty dancing”. Attackers can abuse OAuth ‘dances’ – their authentication processes and how they manage communication between a browser and service provider – by combining response-type switching, invalid states, and redirect URI programming “quirks” to steal user information such as authorization codes or tokens.
However, as highlighted in MITRE’s latest 2022 Common Weakness Enumeration (CWE) Top 25 Most Dangerous Software Weaknesses list, made public at the end of June, these attacks are still common and a threat to users worldwide.
Abusing the sign-in flow
The solutions implemented by browsers to reduce the risk of these attacks includes Content Security Policy (CSP) and Trusted Types, which allow the software to reject data values that could lead to DOM XSS and credential hijacking.
However, the researcher says that OAuth’s sign-in flow, used by companies including Slack, Facebook, and Twitter, can potentially be ‘broken’ for the same impact.
It should be kept in mind these types of attacks aren’t easy to perform and, as Rosén says, involve a ‘grind’ involving an examination of source code and a knowledge of how OAuth’s dances work.
Breaking the chain
To steal tokens, an attacker must first break the chain between the system issuing tokens and a service provider consuming them.
This can be achieved by changing the state-value in use through a specially crafted link, sent to a potential victim as a sign-in page, but which uses the valid state of the attacker.
Once a victim has signed in and is redirected back to a website, the ‘dance’ is interrupted, as there is no valid state for the user. The user will then be shown an error message, and if the attacker is able to leak data and URLs from the error page, the researcher says that the threat actor “can now sign in with their own state and the code leaked from the victim”.
It can also be possible that response-type, response-mode switching, and redirect-uri path abuse could be used to intercept connections and cause unexpected behavior, although changing these pathways is difficult.
“In a proper OAuth-dance using code, in the last step to acquire the access token from the service provider, the redirect_uri must also be provided for validation to the service provider,” Rosén explains.
“If the redirect_uri that was used in the dance is mismatching the value that the website sends to the provider, no access token will be issued.”
The researcher tested out different attack methods and achieved one-click hijacking. One exploit involving Apple OAuth sign-in was reported on May 12.
There are other quirks that attackers can also exploit to compromise OAuth and grab leaked URLs. These include performing an XSS attack on the third-party domain that receives URL data during authentication and abusing APIs intended for fetching URLs. Domains without sufficient origin checks, for example, may be at risk of exploitation.
“Due to the fact that each OAuth provider allows so many different response types and modes, it becomes quite tricky for a website to cover all different cases,” Rosén says.
To mitigate the risk of attack, the researcher recommends reviewing the OAuth 2.0 Security Best Current Practice guide, making sure that pages rendered for OAuth’s authorization response do not contain third-party resources or links, and users should also consider only allowing limited OAuth response-types and modes.
“You might not use any vulnerable third-party scripts today, but if anyone in your organization introduces anything new through Google Tag Manager or similar, or if the third-party scripts change, you can prevent any future potential token leakage,” Rosén commented.