Researchers: Vulnerabilities Exist In 22 APIs Across 16 AWS Products
AWS resource policies with nonexistent principals that could be abused by hackers looking to guess credentials (Source: Palo Alto Networks)
Researchers have uncovered a vulnerability in 22 application programming interfaces across 16 Amazon Web Services products that can be exploited to compromise basic information of the user and gain access to details of various cloud accounts, according to researchers with Palo Alto Networks’ Unit 42.
These vulnerabilities have been observed across all the three AWS regions -including domains for government services and China – with Amazon Simple Storage Service (S3), Amazon Key Management Service (KMS) and Amazon Simple Queue Service (SQS) all open to being abused, Unit 42 notes.
The vulnerability is contained within a feature that authenticates “resource-based policies” while accessing commonly used services such as Amazon S3 buckets. Resource-based policies permit a specified user to access or perform certain tasks on a resource defined under the policy. It also lays out conditions under which these permissions are applied, the report states.
By taking advantage of this vulnerability, an attacker can gain access to account details, learn about the internal structure of the organization and probably launch attacks against individuals, the researchers warn.
Resource-based policies contain a field called “Principal” which refers to a user or an identity who can access the resource,” according to the report.
“The policy determines the actions that principals can perform on the attached resource. A principal can be an AWS user, role or service. The actions that can be performed depending on the type of service,” Jay Chen, a researcher at Unit 42, notes in the report.
If the Principal field doesn’t contain any identity, then the API call creates an error message, according to the report.
“This convenient feature, however, can be abused to check whether an identity exists in an AWS account. Adversaries can repeatedly invoke these APIs with different principals to enumerate the users and roles in a targeted account, Chen notes.
Also, the victim account cannot observe these attempts because all the API logs and error messages would appear at the hackers’ end where resource policies are exploited.
“The ‘stealthy’ property of the technique makes detection and prevention difficult. Attackers can have unrestricted time to perform reconnaissance on random or targeted AWS accounts without worrying about being noticed,” researchers add.
AWS validates every field included in the policy before it gets applied to a resource. This measure is implemented to avoid human error, as the validator makes sure that specified principals exist and all the assigned actions are supported by the service, the report notes.
If an attacker decides to provide an invalid username or role name in the principal field, the authentication process fails. Unit 42 researchers mention that one of the best practices to implement a secure authentication process is to avoid providing correct account-specific information on error messages. This is something that AWS currently does incorrectly.
The AWS validator, however, leaks such information in the error message, according to the report.
“The AWS policy validator explicitly reveals if the specified principal exists or not. An adversary could use the error messages to check whether a user or an IAM role exists in a targeted account.”
The next issue is if this process is repeated numerous times, it allows threat actors to compile and understand the number of identities in the victim’s account.
A spokesperson for AWS could not be immediately reached for fiurther comment about the findings.
Precautions and Conclusion
Since there are no observable logs in a potential victim’s account, it is tough to detect and restrict fraudsters from cataloging identities but practicing good IAM security measures can help in tackling such threats, Unit 42 notes.
Researchers say that while it is difficult to stop attackers from enumerating roles or identities in AWS accounts, the cataloging process can be made tougher and one can keep tighter surveillance on malicious activities.
Unit 42 recommends following several steps to mitigate this issue:
- Reducing attack surface by blocking inactive users and roles;
- Adding random codes to usernames and role names to make them harder to guess;
- Making sure that no additional users are created to the AWS account by logging in with identity provider and federation;
- Monitoring all identity authentication activities;
- Implementing two-factor authentication for every user and IAM role.
Other AWS Threats
In June, security firm Cado reported that a cryptomining botnet had the capability to steal Amazon Web Services user credentials (see: Cryptomining Botnet Steals AWS Credentials).
If the infected Docker container or Kubernetes installation runs on top of an AWS infrastructure, the botnet would then scan for unprotected credentials, make a copy of the username and password and then upload those to the command-and-control server operated by the cybercriminal gang, according to the report.