iSEC Research Labs

IAM user management strategy

24 Feb 2015 - Loïc Simon
This article is part of the AWS blog post series

Use IAM groups

When granting privileges to IAM users, AWS account administrators should avoid use of user-specific policies. Instead, create groups whose name explicitly defines the members' job functions or responsibilities (e.g. AWS Administrators, Operations, Developers, Accountants), and define the permissions granted within group policies. Doing so will simplify the permissions management process as changes in group policies apply to all members.

When performing AWS configuration reviews, iSEC often discovers IAM users whose privileges have been granted via a combination of IAM user and IAM group policies. It is not uncommon to see IAM users who are granted full administrator privileges in a redundant manner, via both user and group policies. Such configuration creates an avenue for configuration mistakes, as another administrator may believe that terminating an IAM user's membership to the admin group is sufficient. Therefore, banning use of IAM user policies will result in making one's AWS environment less error-prone.

Note: It is on purpose that iSEC recommends using IAM group names that reflect a job title or responsibility. IAM users who do not fit in such groups (e.g. headless users) should not exist. Instead, AWS account administrators should investigate use of IAM roles for EC2. Further details will be discussed in an upcoming blog post.

Create a common IAM group to apply generic policies

Because a number of policies must be applied to all users, iSEC recommends that AWS account administrators create an IAM group that all IAM users belong to. Doing so will allow AWS account administrators to consistently grant privileges and enforce a number of rules.

Note: It is important that all IAM users belong to this common IAM group to ensure that policies are consistently applied. Failure to do so will create gaps in one's AWS environment security posture.

Authorize IAM users to manage their credentials

To begin with, iSEC recommends that AWS account administrators allow all of their IAM users to manage their credentials, and only theirs. With all IAM users belonging to the common IAM group, this can be achieved by applying the following IAM policy (also available on Github to the group.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
                 "iam:*AccessKey*",
                 "iam:*Password",
                 "iam:*MFADevice*",
                 "iam:UpdateLoginProfile"
        ],
      "Resource": "arn:aws:iam::AWS_ACCOUNT_ID:user/${aws:username}"
    },
    {
      "Effect": "Allow",
      "Action": [
                 "iam:CreateVirtualMFADevice",
                 "iam:DeleteVirtualMFADevice"
      ],
      "Resource": "arn:aws:iam::AWS_ACCOUNT_ID:mfa/${aws:username}"
    }
  ]
}

While the above policy is sufficient to allow users to manage their credentials, AWS administrators may consider the following statement as an addition; it allows IAM users to know what the account's password policy is. The complete JSON payload is available in the AWS-recipes repository.

{
  "Effect": "Allow",
  "Action": "iam:GetAccountPasswordPolicy",
  "Resource": "*"
}

Use AWS Scout2 to detect user policies

The default ruleset used by AWS Scout2 includes a rule that checks for user policies and reports the use of user-specific IAM policies as a warning. Detection of user-specific IAM policies results in the IAM menu dropdown containing a "User policies" security risk, as illustrated in the below screenshot.

Screenshot: IAM menu dropdown with a User policies security risk

When clicked-on, this "User policies" link filters the list of IAM users to only display those who have at least one user policy attached. The orange badge indicates a warning and the count of user policies attached to this particular IAM user.

Screenshot: Orange badge indicating that at least one user policy is attached to that IAM user

Check that all IAM users belong to the common group

AWS Scout2 comes with a tool — RulesGenerator.py — that allows AWS account administrators to generate a custom ruleset to tailor the report to their needs. An optional IAM rule requires all IAM users to belong to a common IAM group. In order to enable this rule, the following can be done:

  1. Run the rules generator with the following command line:
    ./RulesGenerator.py --ruleset_name isec --services iam
  2. Answer "yes" to the question "Would you like to ensure that all IAM users belong to a given IAM group?"
  3. Enter the name of your common group (e.g. AllUsers)
  4. Enter "yes" or "y" to confirm
  5. Change the level if desired
  6. Run Scout2

Note: If you have already run Scout2 and do not wish to download the latest IAM configuration, use the following command to run an offline analysis:

./Scout2.py --ruleset_name isec --services iam --local

The following screenshot illustrates the IAM menu dropdown containing a security risk when IAM users do not belong to the configured common group.

Screenshot: IAM menu dropdown when IAM users do not belong to the common group

When clicked-on, this link filters the list of IAM users to only display those who do not belong to the common IAM group. A colored warning sign appears, warning about this issue.

Screenshot: Orange badge indicating that at least one user policy is attached to that IAM user

Conclusion

Strict management of IAM users and tight control of their privileges is key in maintaining a secure AWS environment. When followed, the above recommendations should enable AWS administrators to manage IAM users with improved efficiency and lower the chances of overly privileged users to exist.

Do not use your AWS root account

23 Feb 2015 - Loïc Simon
This article is part of the AWS blog post series

What is the AWS root account?

The AWS root account is the account that was used — or created — when signing up with Amazon Web Services. This account has full access to all resources in the account and it is not possible to alter this configuration.

Risks of using the AWS root account

Using the AWS root account means that there is potential for its compromise. In particular, iSEC noticed that AWS customers who use the AWS root account tend to do the following:

  1. Share credentials between employees.
  2. Disable Multi-Factor Authentication (MFA) for convenience.

Shared credentials, aside from increasing the risk of compromise during the sharing process, render credential rotation impractical due to the need for the newly-generated secret to be known by multiple parties. Sharing the AWS root account also undermines any effort towards using IAM and leveraging the fine-grained access controls it offers. Finally, shared credentials result in loss of the attribution ability, which makes auditing harder and may prevent successful investigation.

AWS Identity and Access Management (IAM)

AWS IAM allows account administrators to create users for every employee and grant them access to a limited set of services, actions, and resources. This allows AWS account administrators to apply the principle of least privilege, which dictates that a given user should only be able to access the information and resources that are necessary for them to perform tasks they are responsible for. Additionally, use of IAM allows AWS users to rotate credentials and revoke privileges without impacting other employees.

AWS account administrators should create an Administrator IAM group, grant administrator privileges to this group, and create individual IAM users for each employee in charge of administrating the AWS account. When done, the AWS root password should be rotated and stored in a safe manner. Furthermore, additional credentials such as access keys and certificates should be deleted.

Important security consideration about the root account

AWS users should always enable MFA on their root account, even when the password is securely stored; it is important to realize that the password reset for the root account process only requires access to the email address associated with this account. This means that, without MFA, your production environment is only as secure as an email.

Announcing the AWS blog post series

22 Feb 2015 - Loïc Simon
This article is part of the AWS blog post series

Starting this month, iSEC Partners will start a series of blog posts related to AWS. The goal of these blog posts will be to:

  • Discuss common security gaps in AWS environments
  • Discuss common security gaps in the architecture of applications deployed in the cloud
  • Describe methods and tools used to identify these security gaps
  • Share tools and scripts that facilitate daily and secure work with AWS
  • Share AWS policies that help improve the security posture of AWS environments

To share material, iSEC created a new public AWS-recipes repository on GitHub. The tools and policies shared in this repository will be discussed and explained in dedicated blog articles.

Because iSEC has been assessing the security of clients' AWS environments for several years, we have a number of ideas and articles in the pipe awaiting to be written and published. Without further ado, we will start this series with articles that discuss Identity and Access Management (IAM) common issues and best practices, and will present a strategy to improve one's security posture when using AWS.

CA Alternative Whitepapers

11 Feb 2015 - Braden Hollembaek

Academic co-authors Adam Bates, Joe Pletcher, Tyler Nichols, Dave Tian and iSEC engineer Braden Hollembaek had a pair of interesting papers published at the 2014 Conference on Computer and Communications Security and the 2014 Internet Measurement Conference, respectively.

In "Securing SSL Certificate Verification through Dynamic Linking", the paper introduces CertShim, a lightweight retrofit to existing SSL/TLS implementations that provides new mechanisms to address: vulnerabilities in legacy software, improper usage of existing libraries, and the swift bootstrapping of new enhancements. This is accomplished by dynamically hooking calls to the certificate validation entry points in the OpenSSL, PolarSSL, and GnuTLS libraries via an LD_PRELOAD shim. The paper also demonstrates CertShim's extensibility by adapting it to work with Convergence, DANE, and Client-Based Key Pinning. CertShim imposes only a modest 20ms overhead for an SSL verification call and, by coarse estimate, hooks the SSL dependencies of 94% of Ubuntu's most popular packages with no changes necessary to existing applications. This work creates a framework to help increase the system-wide security of SSL communications in non-browser software, while simultaneously reducing the barriers to evaluating and adopting alternative proposals to the certificate authority system.

For context leading into the second paper, it should be pointed out that in 2011 Moxie Marlinspike proposed a CA alternative, Convergence, that extends the Network Perspectives system of multi-path probing to perform certificate verification. Unfortunately, adoption of Convergence and other SSL/TLS trust enhancements has been slow.

Some adoption concerns are addressed in "Forced Perspectives: Evaluating an SSL Trust Enhancement at Scale", where the question is asked "What if all certificates were validated with Convergence?" In this paper, a case study of deploying Convergence under realistic workloads with a university-wide trace of real-world HTTPS activity is performed. By synthesizing Convergence requests, it is possible to effectively simulate perspectives-based verification on an entire university. The paper demonstrates that, through local and server caching, a single Convergence deployment can meet the requirements of millions of SSL flows while imposing under 0.1% network overhead and requiring as little as 108ms to validate a certificate, making Convergence a worthwhile candidate for further deployment and adoption.

Links to the papers and source code can be found here:

CertShim Paper: certshim_ccs14.pdf

Source code for CertShim: https://bitbucket.org/uf_sensei/cert-shim

Please keep in mind that CertShim is part of an ongoing research project that relies on unstable function hooks into version-dependent libraries, and as such, should not be used as a production security resource.

Forced Perspectives Paper: forced_perspectives_imc14.pdf

Calculating SQL Permissions

09 Feb 2015 - Peter Oehlert

iSEC Partners is happy to announce the availability of a tool to help those wishing to better secure their database applications and users. It is a simple command line tool that can monitor Microsoft SQL Server for a period of query activity and then return the smallest set of permissions necessary to execute all of the monitored queries.

Unnecessary permissions granted to users and applications can be a significant threat if or when those credentials can be used by an attacker. Maybe a database user who normally only queries a couple of static views leaves their password on a text file on a laptop that gets compromised. Or perhaps an application has a SQL Injection flaw allowing nefarious ne'er do wells to issue arbitrary SQL statements against the database. Both of these cases can lead to painful breaches where large data sets are exfiltrated, modified or even just wantonly deleted. The SQL Permissions tool will help determine the most restrictive set of permissions that are actually needed.

This can be useful for developers of applications, as well as applications that already exist. The key in any case is to execute all of the logic or activities that permissions are desired for, as the tool will only calculate a permission for queries it observes. In some cases, an application developer could do even better by isolating high risk privileges to a different components using different database credentials, thereby segregating the risk that highly privileged operations have. Though the tool cannot help rearchitect an application, it can provide the list of permissions required and reviewing the list can provide a useful look at the necessary permissions.

The tool is now open sourced and available on iSEC's GitHub page. It does not support every kind of potential SQL Statement that can be executed, but covers the most common queries used in runtime application scenarios. The tool uses assemblies only available from SQL Server Profiler, so this will require a SQL Server version that includes Profiler installed locally, even if using trace files. Notably, that does not include the SQL Express editions. These assemblies are not included in the tool, and are not available for redistribution. It has been tested on SQL Server 2012 and 2014, though it likely works on other editions as the underlying profiling and tracing technology has not significantly changed.

Good luck, and have fun locking down everything!