Threat Evasion for aws:multifactorAuthPresent condition using Cloudshell

Hello, astonishing hackers and security researchers out there. I hope you all are doing well. While auditing one of the aws infrastructures I realized any privileged user could perform sensitive actions like deleting, creating and launching services without the need to enter MFA which is enforced on the account. So in the case where the security credentials of the user are being comprised and assuming these credentials anyone can perform soul-destroying actions. This by itself is a security issue and I would like to name this “Sensitive actions without MFA”.

Further Thinking

Now the question arrives how does this increase the security of one's infrastructure? what security does this possibly add? (nice thinking)

Brainstorming

Sensitive actions without MFA

So now let us consider a scenario where the access keys of a privileged user are being exposed and if any bad actor/adversary would configure the access keys and perform some soul-destroying actions on aws infrastructure. To prevent sensitive actions from being carried out from aws cli we can configure a condition where users with MFA enabled can only perform these actions which means we can only perform sensitive actions from the console. Let me demonstrate it

• Creating a lambda policy where ListFunctions and GetAccountSettings call need the user to have MFA enabled.

Lambda IAM policy

• With the policy enforced, we can list out the lambda functions from the aws console

Listing lambda functions from aws console

• When we try to list lambda functions using programmatic access we get an Access Denied.

Listing lambda functions from programmatic access

Can I bypass “aws:multifactorAuthPresent”: true?

Well, my initial instinct was “no, how could anyone possibly bypass it?”. After some research, I came across Christophe's blog Retrieving AWS security credentials from the AWS console. That’s when I thought about trying something different.

Attack Vector

Inspired by Christophe's blog I thought about generating session tokens from the cloud shell and assuming the session token to check if we were able to bypass the MFA condition.

• Generating session tokens from cloudshell

Generating session tokens from cloudshell

• Listing lambda functions with the session token generated earlier

Listing lambda function from session token assumed

With this approach, we were able to bypass “aws:multifactorAuthPresent”: true.

Note: We can generate the session token irrespective of the privileges assigned to us for generating credentials.

Logging

One of the most important aspects of the cloud is logging and we wanted to check if the action of generating a session token would be logged. We started the cloudshell and checked the CloudTrail for events history. We came across an event named “PutCredentials”.

CloudTrail logs

Further researching on this event we realized it just passes the console credentials to the cloudshell environment.

PutCredentials in cloudshell

The silver lining is that this action is not being logged. The session token generated using cloudshell can be called “ghost session keys” that no one would ever get to know about.

Mitigation

One of the best mitigation steps would be to ensure cloudshell access is given to users who have the requirement and the least privilege principle should be followed.

Kindly note this issue was reported to AWS before publishing. Please feel free to reach out to us for any recommendations and clarification. Thank you!