April 25, 2018

AWS Security Vulnerabilities

By Martin Hollstein

Addressing Common AWS Policy Security Misconfiguration Vulnerabilities

The shared responsibility model presented to infrastructure, developer, and security teams is a complex topic when first introducing the idea to newer AWS teams. When building infrastructure, AWS teams no longer need to concern themselves with hardware and physical network security of their services. However, teams must use good practices when it comes to policies of said services. While most teams grasp the basic Security Group, Route Table, Private versus Public subnet, and ACL concepts, there is a real lack in practice when implementing hardened policies for AWS resource and IAM policies.

For simplicity, the examples in this article will focus on AWS SNS (Simple Notification Service) resource policies and IAM policy configurations. However, it is important to audit all AWS resource policy types, IAM policies, and Organization policies.

A Common Issue

For most projects, policies usually start and stop with one IAM policy for SNS that looks something like the following.

{ 
    "Version":"2012-10-17", 
    "Statement":[{ 
        "Effect":"Allow", 
        "Action":["sns:Subscribe”, “sns:Publish”], 
        "Resource":"*" 
    }]
}

This policy is attached to the role used for EC2 instances, ECS services or users that require the need to subscribe or publish to SNS topics. While this allows restricting anything with a role with this policy, it does not restrict anything else with more elevated policies to access SNS resource.

Why is this a problem?

Bad single layered polices like the above example increase attack surface. It implicitly introduces increased permissions to all IAM roles and accounts, weakens resource control via IAM policies, and fails to cover policies from external accounts.

Thin policy layers applied at the wrong levels can increase the attack impact of a malicious user. By not applying fine grained policies at the right level, a change to just one policy can allow all actions to be executed on the SNS resource. Such attacks can lead to scenarios where CloudTrail or CloudWatch SNS monitoring topics are deleted to cover up inappropriate access, network events, or SNS message loss.

As the previous issues and example explained, using only one IAM policy implicitly grants a wide range of permissions on the SNS resource. Any policy configured with more permissions on the SNS resource, such as “sns:DeleteTopic”, can do what it wills upon any SNS resource.

The last point is exaggerated more with the complete lack of control on the SNS policy. Any bad actors can do what they will with the SNS resource if the appropriate role or policy is applied. Mind, bad actors can be internal (disgruntled developers) or external (breached EC2 instance).

Finally, SNS resources can be configured to allow external accounts to interact with the SNS resource. In this case, the SNS resource is at the mercy of the other AWS account IAM policy configurations for the actions that can be taken on it. This bodes ill for the SNS resource owner as the external IAM policy could be more permissive than the IAM policies in the resource’s account.

Despite IAM policies defaulting to implicit denial in order to control AWS resource access, open policies on resources such as SNS allow for a large attack surface.

Solutions

There are several solutions to prevent accidental security and data mayhem in AWS. By following some simple guidelines, one can achieve relatively tight control over users, roles, and resources. Use of good IAM policy resource fields and explicit resource policies can lead down the path to a secure AWS environment.

First and foremost, administrators of the AWS account and IAM policies must define a policy and role that can be used to edit IAM policies. Then, the same group of people would deny IAM policy editing for all others. This would prevent a developer or bad actor accessing IAM and elevating permissions. Depending on the organization, the IAM policies for IAM Roles will be different, so it is difficult to provide hard and fast rules for which actions should be allowed. Instead, review what users of the AWS account within the organization need to do and build the policy specific to those needs. One can define finer grain controls if these policies only allow the users to enact on very specific resources using the Resource field in the IAM policy.

Next, policies on resources should not only be applied to the IAM policies for roles, but on the resource itself. For instance, rather than allowing any user or service to do anything with the SNS service, one might apply specific actions for specific resources:

{ 
    "Version": "2012-10-17", 
    "Statement": [ 
        { 
        "Sid": "AllowSpecificTopicSubscriptions", 
        "Action": [ 
            "sns:ConfirmSubscription", 
            "sns:Subscribe", 
            "sns:Unsubscribe" 
        ], 
        "Effect": "Allow", 
        "Resource": [ 
            "arn:aws:sns:*:123456789012:TopicA", 
            "arn:aws:sns:*:123456789012:TopicB", 
            "arn:aws:sns:*:123456789012:Pub_*" 
        ] 
        }, 
        { 
        "Sid": "DenySNSManagement", 
        "NotAction": [ 
            "sns:ConfirmSubscription", 
            "sns:Subscribe", 
            "sns:Unsubscribe" 
        ], 
        "Effect": "Deny", 
        "Resource": [ 
            "arn:aws:sns:*:123456789012:TopicA", 
            "arn:aws:sns:*:123456789012:TopicB", 
            "arn:aws:sns:*:123456789012:Pub_*" 
        ] 
        }
    ]
}

This policy would be a good example to apply to roles that are interested in subscribing to SNS topics. Beyond that, the Allow statement’s Resource condition specifies exactly which topics in any region, within the specific account, users of this policy can subscribe to. Notice that the last Resource statement allows subscriptions to any topic in any region in this account that are prefixed with “Pub_”. This would be useful if there are internal, external, or department specific SNS topics one can subscribe to.

Conversely, if there are SNS topics for internal incident responses, called TopicC, consumers of this policy would not be able to subscribe to it. One other very important point is that this policy removes all publishing and management permissions. Furthermore, this policy can be enforced by applying a topic policy to block any action from any AWS account external to one’s own AWS account:

{
    "Version":"2012-10-17", 
    "Id":"AccountPrivateTopic", 
    "Statement":[ 
        { 
            "Sid":"DenyAllExternalAWSAccounts", 
            "Effect":"Deny",            
            "Principal": {"AWS":"*” }, 
            "Action”: [ 
                "SNS:GetTopicAttributes", 
                "SNS:SetTopicAttributes", 
                "SNS:AddPermission", 
                "SNS:RemovePermission", 
                "SNS:DeleteTopic", 
                "SNS:Subscribe", 
                "SNS:ListSubscriptionsByTopic", 
                "SNS:Publish", 
                "SNS:Receive" 
            ], 
            "Resource":"arn:aws:sns:{YourTopicRegion}:{YourAccountAWSAccountId}:{YourTopicName}" 
    “Condition": {"StringNotEquals": {"AWS:SourceOwner": "{YourAccountAWSAccountId}} 
        }
    ]
}

Note that one will need to add in an Allow statement for one’s own AWS account to manage the Topic. Going a step further, there is also the ability to control Topic Delivery Policies.

Conclusion

In the end, there is often a large IAM policy and resource policy control gap in most immature AWS environments. This can lead to severe security holes within account management, service access, and resource integrity. This is easily remedied by properly written and layered policy statements for IAM and resource policies. There is a wealth of information in regards to actions, conditions, resources, and other policy properties found in the docs as well as tools to help build and validate such policies.


Looking for some help integrating with AWS? Centare has a talented team of AWS certified professionals to help.

Martin Hollstein - AWS Certified Solutions Architect

About Martin Hollstein

Martin is an experienced full stack software developer, consultant and AWS Certified Solutions Architect.