Ridibooks 1 Click ATO

This is a write up of my experience with the Ridibooks bug bounty back in 2023.

Ridi approved the public disclosure of this report.

About the Ridibooks bug bounty

Ridibooks runs a bug bounty program that rewards reports of security vulnerabilities in its own services.

It seems to be one of the few Korean web bug bounties where public disclosure is allowed.

By the standards of Korean web bug bounties, for Low to Medium severity it seems to pay out fairly well(maybe)

(When I sent in my first valid report they also gave me one of Ridi's e book readers, though I'm not sure that still happens these days.)

Interestingly, you can check who got paid how much.

Looking at the hackers.yaml history, this bounty has been picked clean over the years, so fresh bugs are scarce, but I'd recommend watching newly shipped features closely.

Timeline

TL;DR

• When a logged user opens a link crafted by an attacker, the attacker's SNS account gets linked to the victim's account, allowing login to the victim's Ridibooks account.
• The attacker can then change the account's email, password, and ID in sequence and remove the linked social logins, reaching a complete Account Takeover (ATO).

• The starting point is a CSRF. Just opening a link the attacker crafted links the attacker's SNS account to the victim's Ridi account.
• On Ridibooks, entering the My Account page requires reconfirming your password. However, with just an arbitrary value (code), after an error occurs, the My Account page could still be reached.
• Without password reconfirmation, SNS account linking and email change requests were possible.
• By chaining the vulnerabilities the email can be changed to the attacker's, and from then on the password can be reset through the legitimate features of "Find ID -> Find Password."
• Finally, removing the existing social-connect and changing the ID completes a Full ATO that is hard to recover.
• Summarized as a diagram, it looks like this.

Vulnerabilities & features

• Breaking the flaws that make up the chain down by role, it comes together like this.

Vulnerabilities

• [V1] Social-connect CSRF: through the social-connect endpoint, the account of the user who clicked the link could be linked to someone else's social account.
• [V2] Password reconfirmation bypass: due to poor error handling on the endpoint, the password reconfirmation could be bypassed to reach the My Account page.
• [V3] Email change: the account email can be changed without password reconfirmation or a second factor.

Features

• Find ID / Find Password (GraphQL): both are normal account recovery features.
• The thing is, because V3 has already changed the email to the attacker's, these legitimate features work as is for the attacker.

Classification

[V1] Social-connecting CSRF

• On Ridibooks, there's a feature to manage SNS linking within the My Account page.

• You can link a Kakao, Naver, Google, or Apple account to your Ridi account, and logging in with a linked SNS lets you enter that Ridi account.

• The normal linking flow was designed like this.

reconfirm password -> reach My Account page -> click SNS link ->
log in to the other platform's account -> run the linking endpoint -> complete

• A logged in user is supposed to confirm their password once more before reaching the management page, but the problem is that the endpoint actually handling the link works regardless of that context.
• Since this request is made without any ownership verification, it can occur from just opening a link.
• So the attacker goes through the normal process to create a social-connecting URL but does not actually send the request.
• Log in to the other platform's account -> obtain the social linking URL.

• When a logged in victim opens that link, the request goes out under the victim's session and the attacker's SNS account is linked to the victim's Ridi account.

• Once linking is done, the attacker could log into the victim's Ridibooks account through their own SNS account.

[V2] Password reconfirmation bypass

• As shown below, reaching the My Account page requires a password reconfirmation step.

• If you call it with an arbitrary value (like 123) in the code parameter, an error occurs partway through the linking process.
• But at that point, instead of being sent to an error page, you can reach the /account/modify (My Account) that state points to as is.

• As a result, you can enter a sensitive page without knowing the password.

[V3] Email change without password reconfirmation

• As confirmed in [V2], an email change normally follows the order My Account -> enter password -> change email.
• However, while logged in, you can call /v1/account/verification/send-email directly and change the email info without entering a password.

• The attacker visits their own mail, clicks the link, and the email can be changed.

[Features] Find ID -> Find Password

• Since the email is already the attacker's, the takeover is carried out through the Find ID & Find Password features that Ridibooks provides.

• The screenshot is edited, but the actual ID value was delivered to the attacker's mail just fine.

• Requesting a password reset with the ID and the attacker's email sends the reset link to the attacker's mailbox.

• The attacker opens the link and can set a new password.

Full chained vulnerability

• In the end, the 1 click Account Takeover I reported to Ridibooks is as follows.

1. The attacker creates a social-connect link with their own SNS account and lures a logged in Ridibooks user into clicking it.
2. When the victim clicks the link, at that moment the attacker's SNS is linked to the victim's account. (= [V1])
   • If a vulnerability like XSS exists in the service, it looks like account takeover would be possible with just the [V3] email change request, without the [V1] social-connecting CSRF.
3. The attacker then immediately changes the email to the attacker's address. (= [V3])
   • A path of entering My Account directly via the [V2] password reconfirmation bypass and changing the email is also possible.
4. Using their own email, the attacker gets ID via Find ID and resets the password via Find Password.
5. To keep the victim from recovering the account, the attacker removes the existing social-connect, and if the right to change the ID remains, changes the ID as well.
6. This isn't a simple session hijack; with the ID, email, password, and linking all changed, ownership of the account itself moves over, so it can be seen as a complete ATO.

PoC video

Closing

For those who expected deep technical web analysis, this may have felt a bit plain.

But because it's an attack that ties together a few ordinary flaws, I think it's more practical.

From what I've seen, ATOs tend to come from chaining authentication and authorization gaps, big and small, more so than from any single bug.

Flaws that each rate Low to Medium can escalate into account takeover and similar issues the moment they connect.

My thanks to the Ridi security team for taking the report, fixing it, and readily approving the disclosure.