simple-login / app

The SimpleLogin back-end and web app
https://simplelogin.io
GNU Affero General Public License v3.0
5.04k stars 421 forks source link

[Security] Remediate 2FA bypass with hashed recovery code #2132

Closed ghisch closed 3 months ago

ghisch commented 3 months ago

Hello

I am writing to report a security vulnerability I discovered in the Simple Login service, specifically in the 2FA recovery code authentication mechanism. The issue allows an attacker to bypass 2FA using hashed recovery codes directly, potentially leading to unauthorized access if the database is previously compromised (ex: leak).

Summary

The vulnerability allows an attacker to bypass 2FA using hashed recovery codes stored in the database. If an attacker gains access to the database, they can use the hashed recovery codes to bypass 2FA, posing a significant security risk.

Steps to Reproduce

  1. Create an Account: Register a new account on the Simple Login service.
  2. Enable 2FA: Enable 2FA on the account to generate recovery codes.
  3. Logout: Log out of the account.
  4. Attempt Login: Log in with the correct password but do not complete the 2FA step. Instead, use a recovery code.
  5. Database Access: Access the database and execute the following SQL query:
    SELECT * FROM recovery_code;
  6. Retrieve Hashed Code: Identify a row associated with your user_id and copy the value from the code column.
  7. Authenticate with Hashed Code: Paste the copied hashed recovery code into the web form for recovery code input.
  8. Successful Login: You are logged in without completing the intended 2FA process.

Impact

The ability to use hashed recovery codes for authentication poses a severe security risk. In the event of a database leak, attackers can directly use the stored hashed recovery codes to bypass 2FA and gain unauthorized access to user accounts, which undermines the security provided by 2FA in the first place.

CVSS 3.1

CVSS Base Score: 8.9 (High) Vector String: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N

Suggested Remediation

(As proposed in the PR) Do not compare the raw input from the user with the hashed recovery code. Only compare the hashed input of the user with the hashed recovery code.

More info

After reporting this vulnerability through the recommended way, I received a message stating

If an attacker has access to the DB, they can easily impersonate a user account. As SL isn’t E2E, the security key acts rather as MFA and not as an encryption key.

While it is true that access to the database presents a significant security risk, the primary concern here is the misuse of stored hashed recovery codes. The vulnerability allows an attacker with database access to use hashed recovery codes directly for authentication, effectively bypassing MFA. This lowers the bar for exploitation compared to requiring an attacker to reverse-engineer or crack hashed values (which is why you hash something in the first place). If an attacker gains access to the database, limiting the usability of hashed values for direct authentication provides an additional hurdle. Properly securing recovery codes by ensuring they can only be used in their unhashed form increases the overall security posture and makes it harder for attackers to exploit compromised data.

Thank you for your attention to this matter.

Feel free to edit if you feel the ned.

acasajus commented 3 months ago

Thanks for your patch 👍