Summary
Token reuse in invitation URLs leads to access control bypass via the use of a different enrollment flow than in the one provided.
Patches
authentik 2022.11.4, 2022.10.4 and 2022.12.0 fix this issue, for other versions the workaround can be used.
Impact
Only configurations using both invitations and have multiple enrollment flows with invitation stages that grant different permissions are affected. The default configuration is not vulnerable, and neither are configurations with a single enrollment flow.
Details
The vulnerability allows an attacker that knows different invitation flows names (e.g. enrollment-invitation-test
and enrollment-invitation-admin
) via either different invite links or via brute forcing to signup via a single invitation url for any valid invite link received (it can even be a url for a third flow as long as it's a valid invite) as the token used in the Invitations
section of the Admin interface does NOT change when a different enrollment flow
is selected via the interface and it is NOT bound to the selected flow, so it will be valid for any flow when used.
Workarounds
As a workaround, fixed data can be added to invitations which can be checked in the flow to deny requests. Alternatively, an identifier with high entropy (like a UUID) can be used as flow slug, mitigating the attack vector by exponentially decreasing the possibility of discovering other flows.
PoC
- Create two
enrollment flow
( enrollment-invitation-test
and enrollment-invitation-admin
) in the admin interface (as you normally would)
- Make
enrollment-invitation-test
assign the test
group to the user when signed up
- Make
enrollment-invitation-admin
assign the admin
group to the user when signed up
- Generate an invitation URL via the admin interface
- Bind the
enrollment-invitation-test
to it
- Use the url to signup but change the
enrollment-invitation-test
part in the URL to enrollment-invitation-admin
- The URL is still valid (even though the admin interface has NOT chosen that flow to be bound to that invitation)
- Sign up, you're now an admin
For more information
If you have any questions or comments about this advisory:
Summary
Token reuse in invitation URLs leads to access control bypass via the use of a different enrollment flow than in the one provided.
Patches
authentik 2022.11.4, 2022.10.4 and 2022.12.0 fix this issue, for other versions the workaround can be used.
Impact
Only configurations using both invitations and have multiple enrollment flows with invitation stages that grant different permissions are affected. The default configuration is not vulnerable, and neither are configurations with a single enrollment flow.
Details
The vulnerability allows an attacker that knows different invitation flows names (e.g.
enrollment-invitation-test
andenrollment-invitation-admin
) via either different invite links or via brute forcing to signup via a single invitation url for any valid invite link received (it can even be a url for a third flow as long as it's a valid invite) as the token used in theInvitations
section of the Admin interface does NOT change when a differentenrollment flow
is selected via the interface and it is NOT bound to the selected flow, so it will be valid for any flow when used.Workarounds
As a workaround, fixed data can be added to invitations which can be checked in the flow to deny requests. Alternatively, an identifier with high entropy (like a UUID) can be used as flow slug, mitigating the attack vector by exponentially decreasing the possibility of discovering other flows.
PoC
enrollment flow
(enrollment-invitation-test
andenrollment-invitation-admin
) in the admin interface (as you normally would)enrollment-invitation-test
assign thetest
group to the user when signed upenrollment-invitation-admin
assign theadmin
group to the user when signed upenrollment-invitation-test
to itenrollment-invitation-test
part in the URL toenrollment-invitation-admin
For more information
If you have any questions or comments about this advisory: