Security is often a big concern when it comes to cloud computing. According to the Cloud Security Alliance (CSA), traditional security issues under the responsibility of cloud service providers (CSPs) are now less frequent, in contrast with those related to design, strategy and architecture decisions.

While AWS is responsible for properly securing the infrastructure implementing the cloud services, it is the customer’s responsibility to ensure that all resources and services are deployed and configured in a secure fashion.

Carve approaches cloud systems as an engineer would, in order to understand the inputs, outputs and processes that comprise the system to identify possible security misconfigurations and deficiencies.

These are the top three issues that we report to our customers on AWS application security assessments:

Excessive permissions

When reviewing IAM policies, we often find entities (users, groups, roles) being granted more permissions than they need, violating the principle of least privilege. This can result in service violation, data breaches and resource exploitation.

It is also fairly common to have permissions defined for individual IAM users instead of groups. While simply modifying the user policy may seem faster, arranging users in groups is more convenient in the long run, as it eases both permission management and review, making possible to quickly tell which users are allowed which permissions just by looking at the group they belong to.

Furthermore, using customer managed policies instead of inline policies also helps to produce a clean, secure and easy to maintain IAM environment.

In addition, when identities are already being managed outside of AWS, it is recommended to use IAM identity providers instead of IAM users or groups. For instance, using AD connector it is possible to integrate AWS with Microsoft Active Directory, then map Active Directory identities to IAM roles.

Other useful AWS features when designing corporate policies are permission boundaries and service control policies, which can be used to restrict the effective permissions of identities and organization elements, avoiding potential mistakes resulting in excessive permissions being granted.

Overly permissive security groups

Security Groups are security filters/perimeters which operate within a specific VPC, controlling inbound and outbound traffic. They allow all outbound traffic by default. Additionally, the default security group allows all inbound traffic between its members.

During a security group configuration review it is common to find broad IP and port ranges allowed, as well as exposed extraneous services to the public Internet. This unnecessarily expands the attack surface and does not align with the best practices: in addition to any inbound traffic to public services, only specific traffic to/from known destinations/sources should be allowed for the Security Groups. Failing to do so can result in attackers easily fingerprinting the exposed services at best, and having their vulnerabilities exposed at worst.

Additionally, it is a good idea to perform regular clean-ups and audits to ensure there are no unused security groups and users can only change a particular security group in a given region. AWS Firewall manager can help in automating some of these tasks, by auditing security groups rules and usage.

Public S3 buckets

In November 2018, Amazon released the “S3 block public access” feature, along with visual hints indicating whether an S3 object allows for any degree of public access. However, world-readable/writable buckets is still a high-risk issue. Because S3 is one of the oldest AWS services, a considerable number of S3 buckets remains improperly configured, granting any user with list, read or, in some cases, even write access. This has caused serious data leaks and compromises in the past (Alteryx leak, NSA, Verizon just to name a few), and continues doing so (Attunity: Netflix, TD Bank, Ford, etc.).

Carve uses proprietary tooling to assist in discovering security misconfigurations across deployments, based in our experience testing S3 buckets across dozens of AWS deployments. Amazon recommends taking the following actions to protect S3 resources:

  • Ensure that no unintended public access is possible
    • Use Amazon S3 block public access
    • Use wildcard identities and actions with care
    • Beware of “Any authenticated AWS user” in ACLs
  • Implement least privilege access
  • Roles grant short-term access and should be used for applications and AWS services that require access to S3, as well as when providing access to externally authenticated users (identity federation) or third parties.
  • Enforce encryption in transit and consider encryption at rest. The latter is often overlooked and can help reduce risk by encrypting the data with a key that is stored in a different mechanism than the one storing the data itself.