The case of the Confused Deputy!
Disclaimer/note: This article doesn’t qualify for any anti-trust issues because I, the author, am not leading the reader, with movie or sensational references to make them read technical stuff not related to the references, by explicitly providing the warning where necessary!!
Possessed!!
A fancy word often used to express extreme human behavior or acts that involves an object of desire. It is also used in the context of a ‘ghost’ !!
According to Cardinal Medina, “[Possession] has sensational features, in which the devil in a certain way takes over the physical powers of the possessed person. However, the devil cannot control the subject’s free will and thus cannot cause him to sin….”
Prologue
To establish certain context, rules of the game and perspective before embarking on this article, I need to elaborate a few points that will go a long way in understanding the import of this article.
Exorcism
“If you’ve seen the 1973 movie “The Exorcist,” you at least have some idea of what exorcism is about. It has to do with ridding a human being of diabolic possession, it’s typically associated with Roman Catholic beliefs, and if the movie is any indication, it’s very, very scary…”
Source: How Exorcism Works | HowStuffWorksFrom the same source,
“Malachi Martin reveals in the book “Hostage to the Devil” what he considers to be the typical stages of an exorcism…”
Pretense — The demon is hiding its true identity.
Breakpoint — The demon reveals itself.
Clash — The exorcist and the demon fight for the soul of the possessed.
I am using only the three from the four stages in this article to illuminate in the context of “The Confused Deputy” pattern.
Wikipedia defines “The confused deputy” as “…a legitimate, more privileged computer program that is tricked by another program into misusing its authority on the system.”
Much like the deputy to the Priest in the exorcism act in which the deputy (Priest) is explicitly warned by the Priest performing the exorcism to not to listen to the “devil” whatever be the threat, incitement and to stick to the book, literally speaking!!
The layman’s context
That the latest news going around about the Windows 11 headline feature of hosting Amazon Android Apps being a “I know a guy who knows a guy…” only partially provides a context.
What actually completes the context is the hilarity in the imagery of Windows possessed by an Android apk! This imagery is provided in accordance with the many commenters on the review videos found on the internet.
But it does seem that since 2020, our world has been “possessed” and it seems to be permeating our routine lives as well!
The technical context — The Confused Deputy
The actual inspiration for the title of this article stemmed from my experience in the CDK code that I was working on when I had the Eureka! moment and which led me to a GitHub issue in which someone had commented on the likelihood of the Confused Deputy pattern but I could not find the GitHub issue comment when I tried to search again to credit in this article !
A more technical explanation can be found on this article.
An excerpt from the same source,
“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.”
The Construct that I was working on had to assume a role!
Like the “devil” that possesses the girl in “The Exorcist” movie.
Enter the Sandman!
Impersonation is nothing new for .Net developers as since the turn of the century, Asp.Net developers have been using it.
But this was not Asp.Net, this was Aws CDK.
In the Aws CDK, the major chunk of stuff gets done through Constructs.
An Aws Construct is a well-architected, open source extension of the Aws CDK. source: Aws docs
A construct is written in Typescript (Other languages don’t matter in the context of this article, as my reference is to a programming construct that is very C# specific).
“The bindings for other supported languages use this backend and toolset.” source: Aws docs
Where I am leading you on to, dear reader, is a similar realm as the confused deputy’s in the “exorcism” picture who, classically, is prepped by the Priest to not listen to the “possessed soul” but to stick to the book, literally speaking!!
For you, the non-technical reader or the uninitiated to the aws cdk, I am the possessed soul from this point on in the article!!
Technical stuff
To keep the coherence level of the article and the tangential references within manageable limits for the technically inclined reader, let me pull up some code to establish the context.
To demonstrate step-by-step the problem leading to the Confused Deputy security glitch, I am using an IAMRole CDK stack that needs to define some IAM Role properties for a class called “IAMRoleProps” class that inherits from the base RoleProps class.
So far so good!
The build passes. BUT, when the stack is deployed to Aws, the CDK runtime cannot resolve a required property — assumedBy NOT AssumedBY as in the class above!!
Where did the camel-cased “assumedBy” come from?
This is the point where the devil reveals itself after pretense!
The answer is in the error message itself in the above console screenshot.
From the usage of the “@” symbol in @aws-cdk/aws-iam-RoleProps, we can safely say that it is a TypeScript library.
But there is no typescript library in the C# application so where did it appear from?
It appears that internally, as evident in the same screenshot, there is a JSII runtime class that needs to serialize/deserialize the C# type arguments passed to it because it does not understand the .Net implementation of the base Aws CDK Construct!!
And changing the casing to camel casing does not help either!
The confused deputy pattern begins to unfold at this point because the .Net build passes as the derived class has implemented the inherited member!!
This is the reason for the need for IRoleProps because inheriting from the RoleProps class simply results in a confused deputy class!
And isn’t it fascinating that the workaround is through a class called the DeputyBase class that acts as the deputy!!
“When implementing an interface in .net, in order for the instance to be able to go to Javascript, the user must extend
Amazon.Jsii.Runtime.Deputy.DeputyBase" source:DotNet: user-defined classes implementing JSII interfaces must extend `Amazon.JSII.Runtime.Deputy.DeputyBase` · Issue #1029 · aws/jsii · GitHub
Needless to highlight the change from RoleProps to IRoleProps…since we all know that a class cannot inherit from more than one class and so, the switch to the interface, IRoleProps. And as mentioned earlier, the JSII runtime needs the “deputy" to infer the .net type into a Javascript type otherwise, CDK cannot synthesize the stack successfully.
To get back to the article’s context, I commented out the AssumedBy value assignment from the stack class,
to reaffirm that there is indeed the typescript class working behind the C# code!
So, after uncommenting and redeploying the stack, one gets the stack deployed.
To get back to the point mentioned earlier that defined The Confused Deputy problem,
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.
I used the Constructs example on “Aws Lambda to Aws Secrets Manager” provided in the Aws Constructs page.
To cut a long story short, this is where the “Assume” role that grants (or could grant) additional access not originally meant for the role can make the glitch emerge!!
Epilogue
Clash — The exorcist and the demon fight for the soul of the possessed.
Probably, the Exorcist pattern is the right solution to adopt if one ever gets into the Confused Deputy Security glitch!!
