Preventing Nimbostratus Attacks on AWS

A formless layer that is almost uniformly dark gray

Security researchers and bad guys alike are beginning to turn their sights onto AWS. Recent conferences have given light to a number of AWS specific vulnerabilities and new tools to exploit these vulnerabilities. Nimbostratus is a proof-of-concept (PoC) fingerprinting and exploitation tool for AWS developed by Andres Riancho. It uses application vulnerabilities and AWS insecure settings to pivot and escalate Cloud access. The following is an exploratory investigation of security issues raised by the Nimbostratus toolkit and Paper.

The Chained Attack

The Nimbostratus toolkit exploits known application and infrastructure vulnerabilities and is dependent on a chain of vulnerabilities to gain system level privileges on an AWS hosted instance and Administrator level access on the hosting AWS Account. The following is an account of how these vulnerabilities can be linked together.

At a high level the chain of vulnerabilities is as follow: 1) An Application vulnerability is exploited to proxy the Metadata service. 2) The Metadata service is leveraged to retrieve IAM credentials. 3) Credential permissions are enumerated. 4) Compromised IAM credentials are used to write an SQS message that will 5) execute code via a vulnerable SQS application on the target instance. 6) Other IAM credentials are retrieved from the compromised instance to 7) create an Administrator IAM user.

HTTP Request Proxy Vulnerability

To get a foot hole in AWS, Nimbostratus depends on an application level vulnerability to proxy requests. Request proxying is common in web applications to reach backend resources (or other resources behind the DMZ), however, application proxying is rarely implemented with a whitelist of available resources. In the PoC, Nimbostratus authors use such a vulnerability to retrieve the AMI ID and other confidential information from a vulnerable server.

meta

In addition to the AMI ID, the meta-data service divulges other sensitive information:

  • AWS Region
  • IP Address
  • Instance Type
  • Instance Profile Credentials

Although gaining the initial foot hole depends a very specific vulnerability in the PoC, it is not inconceivable that other similar vulnerabilities such as command injection could be exploited for this very purpose.

Dumping Instance Profile Credentials

Instances often have profiles attached to them. From the AWS Identity and Access Management documentation: An instance profile is a container for IAM roles. Instance profiles are used to pass role information to an Amazon EC2 instance when the instance starts. When you use the Amazon EC2 console to launch an instance with an IAM role, the console displays a list of roles, which is populated with instance profile names.

This means that in order for the instance to make use of its IAM role, it must first retrieve its own credentials, this can be easily done by leveraging the meta-data service. E.g., curl http://169.254.169.254/latest/meta-data/iam/security-credentials/<profile name>. An application vulnerability that proxies the Metadata service can be exploited to divulge instance profile credentials.

// img here, it’s coming

Note the Access Key ID, Secret Access Key and Security Token are easily retrievable.

Enumerating IAM Permissions

Given the Access Key ID, Secret and Token, the Nimbostratus toolkit can be used to enumerate permissions available to the IAM user:

// img here, it’s coming

Although not entirely clear here, these credentials can be used to read & write to SQS.

Exploiting SQS for Arbitrary Code Execution

The next step in the chain of exploitation in the PoC was to exploit a vulnerable SQS client running on the target instance. A number of Messaging applications exist that make working with Amazon SQS easier. One such application which prides itself in its ease of use is the Celery Project, from the Celery Project Website: Celery is a simple, flexible and reliable distributed system to process vast amounts of messages, while providing operations with the tools required to maintain such a system. It’s a task queue with focus on real-time processing, while also supporting task scheduling…

Although Celery may be easy to use, its authors admit that parts of it, e.g., the pickle serializer, are inherently insecure because its lazy use of evaluating data as code. The result of such evaluation makes gaining of system level privileges on any host using the Celery’s serializer, given compromised SQS credentials as describe above, possible. All an attacker needs to do is to inject a message formatted with python commands that return a shell to a listening server.

IAM Privilege Escalation

Once there is a clear path for arbitrary code execution on a Cloud host, gaining system level privileges is trivial. The Cloud instance in the PoC can now be searched for additional IAM credentials and if it just so happens that there are other IAM credentials with specific permissions that allow privilege escalation, an IAM Administrator account can be created. IAM privilege escalation is possible when a user has IAM-capabilities that allow her to create other IAM users. More specifically, they need these IAM permissions:

  • CreateUser
  • CreateAccessKey
  • PutUserPolicy

The compromised credentials can be used to create a user that has all access to all services.

Conclusion

Although the vulnerabilities exploited in the Nimbostratus paper are setup by the authors, they do convey that seemingly low risk vulnerabilities can be used to gain system level access and take control of an AWS account. None of the vulnerabilities demonstrated here are overly complex and are often seen in Industry applications.

Attack Prevention Strategies

Web Application Vulnerabilities

The key takeaway is that application security is the first line of defense; Threat Modeling, Static & Dynamic testing, and Penetration testing if performed during the development lifecycle are proven to reduce the number of vulnerabilities that could expose infrastructure to attack.

Use an Alternative to the Metadata Service

Secrets are often passed in through the instance profile or user-data through the Metadata service; all instance profile and user-data is available to any user or process running on the instance. There is no way to delete these secrets after instance startup, so anybody who has access to the instance can simply request http://169.254.169.254/latest/user-data. Needless to say, but this practice should be discouraged, and use an alternative method for transferring credentials should be employed.

Disable the Metadata Service

A strategy that may help constrain the Metadata service is to make it inaccessible by null routing it. The Metadata service can be disabled by adding a reject route at the end of the user-data, this effectively ensures that only root can re-enable the services. E.g.,

# route add -host 169.254.169.254 reject

Non-root users would first need to get appropriate authorization before they could enable and read from the service.

Don’t Eat Celery

Beware of third party messaging tools that consume data and treat it as code. Tools such as Celery that use eval methods for parsing data are unsafe and their use is discouraged.

Other high level recommendations

  • Always make use the Principle of Least Privilege
  • Always use IAM credentials instead of root account
  • Use Different users for different tasks
  • Audit users and groups

References

http://andresriancho.github.io/nimbostratus/

http://andresriancho.github.io/nimbostratus/pivoting-in-amazon-clouds.pdf

http://blog.codento.com/2012/02/hello-ec2-part-2-locking-it-down/

http://docs.celeryproject.org/en/latest/index.html

Leave a Reply

Your email address will not be published. Required fields are marked *

Time limit is exhausted. Please reload the CAPTCHA.