Description
Description
While setting up a new SaaS-like product offering at Defense Unicorns and testing Social Logins, @bburky found an interesting attack vector that might expose users for phishing attacks.
This is very close to an account takeover, but a (weird looking) verification email goes to the victim account (not the attacker). This probably could be successful with some phishing along the side too:
1. Assume [victim@defenseunicorns.com](mailto:victim@defenseunicorns.com) is an existing registered (admin or whatever) account 2. Attacker self-registers a [attacker@example.com](mailto:attacker@example.com) user with user/pass (not social) and completes email verification. Attacker then logs out of Keycloak 3. Attacker does a new social login (I tested with Google) for [attacker@example.com](mailto:attacker@example.com) 4. This triggers "first-broker-login" in Keycloak. The user is prompted to confirm merge accounts.... a. The attacker clicks the "review profile" button. This page shows all the info provided by the Social login provider... and it's editable?!?! The attacker modifies their email to be [victim@defenseunicorns.com](mailto:victim@defenseunicorns.com) b. The attacker is prompted to merge their account with [victim@defenseunicorns.com](mailto:victim@defenseunicorns.com), they click "add to existing account" c. Attacker is shown "you need to verify your email address to link your account with Google Social Login" i. This email is sent to [victim@defenseunicorns.com](mailto:victim@defenseunicorns.com) (NOT [attacker@example.com](mailto:attacker@example.com)), this prevents this from being zero-interaction. ii. The email sent has a link expiring in 5 minutes, and does include the [attacker@example.com](mailto:attacker@example.com) name in the text iii. It's not unreasonable to assume some phishing (and a more phishy attacker email address) could convince a user to click this link iv. A very similar Keycloak web page is shown to the victim with a "click to proceed" link 5. If the link is clicked, the attacker gains access to the victim account
As point 4.iii highlights, the victim receives an email that doesn't contain the attacker email address. It is very easy to get caught with this phishing attack.
Discussion
No response
Motivation
The primary motivation for adding an extra layer of protection is to defend users from accidentally getting caught with this attack.
Details
After reviewing Keycloak code, the Review Profile Action is performed in the default first broker login.
According to the Keycloak manual (here), there are a few ways we can set it up:
When ON, users are presented with the profile page requesting additional information to federate the user’s identities.
When missing, users are presented with the profile page if the identity provider does not provide mandatory information, such as email, first name, or last name.
When OFF, the profile page does not display unless the user clicks in a later phase on the Review profile info link in the page displayed by the Confirm Link Existing Account authenticator.
There’s 4th option to disable this step entirely, here’s the description of this option directly from the help popup:
WARN: In case that user clicks ‘Review profile info’ on link duplications page, the update page will be always displayed. You would need to disable this authenticator to never display the page.
In my opinion, there should be one more option in the Review Profile section that presents the screen to the user but doesn't allow him to modify the "required" attributes. With this option, this attack vector would be neutralized as an attacker wouldn't be able to change his email (and other fields such as First Name, Last Name etc). At the same time, it's absolutely find to add other non-required fields (e.g. Rank, Organization etc).