You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If you have ForceChangePassword on a user, you can fully compromise the user by resetting the password and logging in as the user. However, if the user is disabled, you cannot log in. You can enable the user if you have GenericAll on the user, but not with only ForceChangePassword. So the attack path is broken.
We should find a better way to handle inbound edges on disabled users, in the cases where the edge permission does not allow the attacker to enable the user.
Stopping from generating edges like ForceChangePassword on disabled users would not be a good solution, as we still want users to be able to audit all ForceChangePassword permissions.
The text was updated successfully, but these errors were encountered:
StephenHinck
changed the title
Better way of handling inbound edges on disabled users
Don't create ForceChangePassword edges against disabled users
Feb 29, 2024
If you have ForceChangePassword on a user, you can fully compromise the user by resetting the password and logging in as the user. However, if the user is disabled, you cannot log in. You can enable the user if you have GenericAll on the user, but not with only ForceChangePassword. So the attack path is broken.
We should find a better way to handle inbound edges on disabled users, in the cases where the edge permission does not allow the attacker to enable the user.
Stopping from generating edges like ForceChangePassword on disabled users would not be a good solution, as we still want users to be able to audit all ForceChangePassword permissions.
The text was updated successfully, but these errors were encountered: