Confused Deputy

Photo by Jack Finnigan on Unsplash

The confused deputy problem is a form of security privilege escalation that can be encountered in various forms when implementing security mechanisms.

The generic goal of administrators is to hand out the least amount of privileges. The goal of attackers is to gain as much privileges needed to gain access to sensitive information.

In a simple example, someone writing a web service might open a REST endpoint which accepts a list of permissions or an auto-incrementing number that represents different roles or identities of users requesting data.

A user who has access to the system can begin forging different requests with different identifiers compared to their original assigned identities and roles used when initially signing into the system. This confuses the service into thinking they are someone else or have a different list of roles than what was originally granted during the sign on.

In another scenario, the user originally has access and roles but it is later restricted or revoked from the system. Different data cache mechanisms or leaked keys (such as automated backups) are still able to obtain access to the server side resources.

A real world example is Slack awarded a bug bounty based on expired SAML assertions still being accepted which could be used to gain access to parts of the system. Slack not only allowed authentication on expired tokens but was also allowing permissions resources the original token was not allowed to have.

One turtle shell to combat the problem is to sign authentications and authorizations using HMAC and Non-repudiation using short expiration times encoded in the signature. This can be SAML tokens, JWT tokens, AWS Security Token Systems, etc… with strict checking of the expiration times, correct clock synchronization, revocation lists, etc… It is preferable if those systems can fail closed if possible but that’s another turtle shell.

Another way in which this problem can show up is 3 legged OAuth2. 3 legged OAuth2 (in a nutshell) are dialog prompts used to ask users if 3rd party systems can have access to sensitive data using security dialog prompt(s). The 3rd parties never have access to user passwords and only have access to sensitive information the user explicitly grants. The OAuth2 security provider gives these 3rd party applications signed tokens with an audience flag set to the their client_id. All 3rd party applications need to check each sent token to ensure the audience flag is equal to their unique client id . If a 3rd party does not check then another malicious or compromised 3rd party application who has user tokens for their service can begin requesting access on the user’s behalf for other service resources.

In a dynamic 3rd party registration situation it is best for down stream services to check for themselves that tokens are intended for them. Some security system techniques allow for directional checks for misbehaviors (either intentional or accidental) and then …

• Revoke tokens being routed to incorrect services in case of key leakages or bad actors obtaining keys to limit them being passed to additional services.
• Suspend 3rd party applications who are suspected of not checking for the audience flag. OAuth2 providers can auto-provision audit tokens with audience flags set to false values to see if requests are being accepted or rejected.
• Revoke a 3rd party application who is sending tokens to incorrect services through downstream services reporting audience flags from other services since they will have the client_id within them. Although if found to not be true, the 3rd party application requesting the review might be revoked for the attempted malicious behavior of auto-revoking other 3rd party systems.