(This image was created with the assistance of DALL·E 2)
OAuth Achilles, The Secrets Behind One-Click Account Takeover
Welcome back to our blog series: Vulnerability of the Month! With this series we would like to give you insights into our and our hackers’ daily work and talk about vulnerabilities. By doing so, we hope to help spread important security knowledge about specific vulnerabilities, how to find them, techniques used and by doing that raise awareness to all the vulnerabilities that may still be out there.
If you want to learn more about the series and why we do it this way, please have a look at the first blog post available here: https://www.bugbounty.ch/votm-jan-23/
Author: this month’s blog post was authored by Cindy Yang
Credits: this month’s vulnerability was reported by the hacker supr4s
Context of the Bug Bounty program
- A time-limited, budget-limited private program
- In scope are multiple cloud-based systems of the customer
- Time between launch of the program and submission of the report: ~1.5 months
Why this vulnerability
It can happen to any of us! By gaining unauthorized access with just one click by the victim, an attacker can exploit personal data, manipulate online presence, and cause significant disruptions.
The system affected
A website with an account section and a shop – and with the capability to link accounts coming from another, 3rd party system.
The vulnerability as described by the hacker
First, in order to understand everything, you need to know what OAuth is.
OAuth (Open Authorization) is a way for you to securely give permission to an app or service to access your information without sharing your username and password. It’s like giving a friend a limited key to your house without giving them the master key.
Imagine you want to link your account on the customer website (let’s call it website A) to another website (website B). You initiate the process on website A. It redirects you to website B’s login page where you securely enter your credentials. After logging in, website B asks for your permission to grant access to website A. Once you grant permission, website B generates a unique access token for website A. This access token acts as proof of your authorization without exposing your login details.
During the above process, to ensure that the response goes back to the right person who made the request, a state parameter is commonly used. This parameter is usually a random value created by the client application, and it’s designed to be unique for each authorization request. Its purpose is to keep track of the initial request and match it with the corresponding response.
Things can go bad when the state parameter is missing. Let’s dig further through the process below.
Create two accounts on website A, one for the attacker (attacker@example.com) and the other for the victim (victim@example.com), and one account for the attacker on website B.
The processes are as follows,
- Attacker logins his account using attacker@example.com on website A.
- Attacker links his account with his website B account. Notice when doing so, a Get request will be made. By looking at the request, we notice that there is no state parameter, which allows a CSRF attack.
- The attacker can now generate a CSRF PoC, which is a link to a form that automatically submits a request to website B’s OAuth authorization endpoint. Once he tricks the victim to click on the link, the victim’s account will be linked to the attacker’s website B account without his knowledge. Below is an example of a CSRF PoC.
- Now once the attacker login using his website B account on website A, he will be redirected to the victim’s account. To take over the victim’s account, he must change the email address of the account.
Impact analysis
The criticality is limited because of the precondition to trick the victim to click on the crafted link. But once the victim clicks on the link, his or her account on website A will be linked to the attacker’s account on website B. Later, the attacker can take over the victim’s account by changing the email address without knowing the current password.
Let’s work together!
Interested in the topic and working with our customers and hackers on such vulnerabilities? We’re hiring – please get in touch:bugbounty.ch/en/jobs!
Interested in finding vulnerabilities? We’re always looking for new hacking talents – please register yourself here: bugbounty.ch/hacker!
All previous Vulnerability of the Month:
