Juice-shop: Add Two-Factor-Authentication Challenge

[bkimminich]

Storyline

Add "extra security" with optional 2FA based on U2F

Libraries

There are existing node libraries for U2F:

• https://www.npmjs.com/package/u2f-api
• https://www.npmjs.com/package/u2f
• https://www.npmjs.com/package/node-u2f
• https://www.npmjs.com/package/authdog
• ...

Or TOTP:

• https://github.com/Daplie/browser-authenticator
• https://github.com/Daplie/node-authenticator

Challenge options

1. Check if one of the available modules has (or had in some older version) a known vulnerability and make its exploitation a challenge
2. Use one of the modules but make it possible to bypass 2FA somehow (real-life examples where it was implemented wrong would be great)
3. Implement own U2F module in a totally unsecure way

Credits

Idea from @ViktorLindstrm during soldering workshop with @conorpp's U2F kit

[bkimminich]

Problem: U2F will only work with an https server!

[bkimminich]

Alternatively use https://github.com/Daplie/browser-authenticator for TOTP-based 2FA?

[bkimminich]

Feature: Implement 2FA via TOTP. To not lock out users who lost their phone, "enhance" _Forgot Password_ to ignore 2FA for that user during the reset but do not delete the TOTP secret in the process. Instead, display the same secret (as QR token) to the user again after re-setting the password. The user can import the same secret as before into the TOTP app. Changing the 2FA secret is possible via _Change Password_ dialog and will ask for current 2nd factor PIN, then generating a new secret. Disabling 2FA works in the same way.

Threat: An attacker can abuse _Forgot Password_ to gain knowledge of the current secret, then log in as another user and change that user's 2FA secret.

Challenge: e.g. "Change or disable Bjoern's Two-Factor token."

[bkimminich]

Additional resource: https://www.nist.gov/itl/tig/back-basics-multi-factor-authentication

[J12934]

I really like the idea of having 2FA related challenges. I'd love to start working on that.

I'm not (yet 😉) an expert in 2FA system, so please correct me if i got something drastically wrong)

Feature: Implement 2FA via TOTP. To not lock out users who lost their phone, "enhance" _Forgot Password_ to ignore 2FA for that user during the reset but do not delete the TOTP secret in the process. Instead, display the same secret (as QR token) to the user again after re-setting the password. The user can import the same secret as before into the TOTP app. Changing the 2FA secret is possible via _Change Password_ dialog and will ask for current 2nd factor PIN, then generating a new secret. Disabling 2FA works in the same way.

I like this challenge idea, thought i would prefer the challenge to not be around a implementation flaw in the 2FA flow.

I would love the challenge to show that the 2FA implementation is only as strong as the storage of the secret. As soon as the attacker is able to access the secret they are able to generate the 2FA tokens just as well as the user. And there does't seem to be a great way to store these secrets. In contrast to passwords where you can store them pretty easily as hashes, which isn't possible with the secrets because the plaintext is required for the token verification.

This is something which i didn't knew (until yesterday 😅) and would love to have the challenge showcase this directly. To do this I'd like to implement it like this:

Feature
Standard 2FA implementation using totp (would go with this library otplib), which allows the user to protect their account with a second factor, which is required on login. The secrets are stored together with the other user details in the user table.

Challenge
"Log in as ${user_xy} without changing their password or 2 Factor Authentication secret."

Suggested solution:

1. SQL Union select on user table to access the 2FA Secret of the User
2. Attacker then needs to setup a totp generator to generate the tokens. e.g. by crafting a totp:// string and using a google authenticator.
3. Attacker logs in as user, skips password verification by sql injection
4. Attacker enters generated totp token and gets logged in.

This would make probably harder to solve as it relies on other challenges to be solved first, but would (at least for me) better showcase the problems with the otp secrets. Especially because the attacker would need to research how to generate tokens from the secret.

[bkimminich]

@J12934 I like your attack path idea a lot! Much more realistic that way! 👍

[J12934]

Got some work done on it today:

The login does already work ( it's still missing tests and some refactoring on the server).

Currently only activated 2FA on my (J12934) account. Haven't added a challenge yet.

[bkimminich]

Awesome work on #826 @J12934! I tweaked the challenge name, category and hint a bit and also moved the challenge over to user "wurstbrot" to actually make it independent of the _DLP Tier 2_ challenge as you already noticed.

[lock[bot]]

This thread has been automatically locked because it has not had recent activity after it was closed. :lock: Please open a new issue for regressions or related bugs.