Summary

Amazon Workspaces was incorrectly interpreting an AWS managed policy which resulted in allowing a read-only permission user to hijack a legitimate workspace. The attacker could force a password reset to the new account and compromise that particular Amazon Workspace, even though the credentials for the account only had read only access. AWS have mitigated the vulnerability, and this post is a quick summarization of the events leading to the patch.

Technical analysis

I first came across Workspaces when exploring an internal project at Deep Secure. Workspaces is an Amazon managed Desktop As A Service (DAAS) solution. Whilst playing with Workspaces, I noticed that it was possible to edit a user who is currently has an account on the workspace with my admin account. Nothing special here I first thought — it is simply used to update the details of the users first name, last name and email address. However, once the project had gained some traction, it came to the point of adding an admin read only account for auditing purposes. AWS has handily exposed a ready made IAM policy which has all the capabilities required to view all resources (but not modify) within the console.

Workspaces permission on the default read only access account

Workspaces permission on the default read only access account So, I now have a ReadOnlyAccess administrator IAM user. If I randomly try to turn off EC2 instances, I will be returned an authorization error. There are many reasons to use read only user policies — for example sending data to an external logging service: https://docs.datadoghq.com/integrations/amazon_web_services/?tab=allpermissions

Edit user popup within the Amazon Workspaces environment.

For these reasons, it means that a single AWS account may often have many read only access IAM users with varying permissions dependent on the service each user needs to access. So, with that in mind I came back to the edit user button within the Workspaces console. It was possible to edit any of the attributes despite only having a read only account:

So, I was able to change the email address of the workspace user from my work email to my personal one, without having appropriate permission. I still needed valid credentials to access the IAM user — so an average Joe Bloggs could not change the email address, but one logged in with the ReadOnlyAccess policy (either via the CLI or the console) could do so.

This meant that I could then force a password reset, and divert the corresponding password reset email across to myself (as the attacker). I could then log in with the attackers’ email address onto the Workspace environment with no obvious changes within the AWS Workspaces console, other than a new email address assigned to that user. At this point, I’m automatically granted the permissions of that workspace to view the users’ encrypted contents on the virtual hard disk and access other services (such as WorkDocs) that the workspace could be using. This access would only happen if the AWS resources were already provisioned to that particular Workspace account.

Mitigation

I contacted AWS security with a brief summary of the vulnerability that I had found. Below is a short timeline of the mitigation process: 7th May: Initial Contact was made

7th May: Response with confirmation of receipt

13th May: Investigations in process and timeline to mitigate the delay

19th May: Initial deployment of a fix, phased deployment had begun

1st June: Deployment of fix complete

Conclusion

Overall a quick response and regular updates, with a total mitigation across all AWS regions in only three weeks. Whilst it is not the most exciting or attention-grabbing vulnerability, it shows that the general patching capability of using a major cloud service far outweighs anything that is “home baked” on premise or using lift and shift. It is only improved further when using managed services like DAAS or PAAS, where you exploit the full capabilities of the cloud infrastructure provider with their quick patching times.