Cloud Security , Cybercrime , Fraud Management & Cybercrime

AWS Flaw Allows Attackers to Find Users' Access Codes

Researchers: Vulnerabilities in 22 APIs Across 16 AWS Products
AWS Flaw Allows Attackers to Find Users' Access Codes
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 on the user and gain access to details of cloud accounts, according to researchers at Palo Alto Networks' Unit 42.

See Also: What Sets MSP Leaders Apart from MSP Laggards?

These vulnerabilities have been observed across all the three AWS regions -including domains for government services and China - with Amazon Simple Storage Service, or S3; Amazon Key Management Service, or KMS; and Amazon Simple Queue Service, or 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 could 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" that 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,” the researchers add.

Exploited Feature

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 researchers sa.

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."

If this process is repeated numerous times, it allows threat actors to compile and understand the number of identities in the victim’s account, Unit 42 says.

A spokesperson for AWS could not be immediately reached for comment about the findings.

Mitigation Steps

Because there are no observable logs in a potential victim's account, it's difficult to restrict fraudsters from cataloging identities, but using good IAM security measures can help in addressing such threats, Unit 42 notes.

Researchers say that while it's difficult to stop attackers from enumerating roles or identities in AWS accounts, the cataloging process can be made tougher and users can maintain tighter surveillance of malicious activities.

Unit 42 recommends the 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.


About the Author

Chinmay Rautmare

Chinmay Rautmare

Senior Correspondent

Rautmare is senior correspondent on Information Security Media Group's Global News Desk. He previously worked with Reuters News, as a correspondent for the North America Headline News operations and reported on companies in the technology, media and telecom sectors. Before Reuters he put in a stint in broadcast journalism with a business channel, where he helped produced multimedia content and daily market shows. Rautmare is a keen follower of geo-political news and defense technology in his free time.




Around the Network

Our website uses cookies. Cookies enable us to provide the best experience possible and help us understand how visitors use our website. By browsing databreachtoday.com, you agree to our use of cookies.