EC2 Instances without an IAM Profile

EC2 Instances without an IAM Role attached either do not have permissions to securely interact with AWS Services or they host long term credentials that are prone to compromise

Details ¶

AWS allows EC2 instances to have an IAM role attached, providing permissions for applications and services on the instance to access other AWS services like S3. Additionally, AWS Cloudwatch offers a client to send instance logs, such as OS and access logs, to the centralised Cloudwatch Logs service.

Centralising logs in Cloudwatch Logs enables for consolidate all logs from instances across your AWS account into one location for parsing, analysis, and alerting. This approach also prevents log tampering on compromised instances, as attackers cannot alter logs directly to cover their tracks.

Another use case for an IAM role is enabling AWS Systems Manager (SSM) as an alternative to SSH connectivity. This allows for mass management of multiple instances simultaneously through the AWS SSM client, facilitating easier and more secure administration alongside a number of other benefits we cover in this documentation.

Whilst it’s not necessary to use AWS services for these purposes it is far more common to have the full suite of AWS services for log shipping, application permissions and more. If log shipping, instance connectivity and management are managed by separate tooling then AWS IAM Roles are not needed on EC2 instances and it would be more secure to not attach any profiles to the intended instances. However, this is a rare setup, therefore we consider EC2 instances without an IAM Profile to have no log shipping, to be hosting hard coded or other long term access credentials for AWS services and to be managed by tools utilising direct network access. This is usually the case and we consider this a High risk vulnerability as a consequence due to the risk of lost logs, no monitoring and long term credentials stored on a machine that is potentially managed by tools with direct network access.

Remediation ¶

SkySiege’s AWS Vulnerability Scan automatically detects this vulnerability across all AWS Regions with the report delivered the same day.

The technical act of connecting an IAM Profile to an AWS instance is simple, however, there are security concerns over what permissions that profile has. Best practice would ensure that the following considerations have been included in the final design:

• Minimal permissions for the IAM Role granting the least amount of privilege to the applications hosted on the instance
• Distribution of the software required to utilise AWS services such as Cloudwatch Logs exports or AWS SSM Connectivity. This usually requires standardised user data at a minimum but ideally a machine image build and distribution pipeline
• Configuration of IMDSv2 exclusive software and permissions. Read more on this consideration under the documentation for test A-EC2-3
• Control of additional AWS Resources such as naming conventions and log retention periods for logs shipped to Cloudwatch Logs
• Management and configuration of additional software required for activities such as log shipping, for example, configuring the Cloudwatch Logs Agent on each instance

Determining this process and governance including what tools to select can be significant. However, with the use of pre-provisioned tools and a pre-defined strategy it is easy to get from an unmaintained set of instances to a fully monitored and controlled estate in a rapid time period. Contact our architectural team for guidance on securing your cloud: