As part of our projects with the Open Technology Fund, such as the review of TrueCrypt, iSEC Partners audited Freedom of the Press’ SecureDrop.

SecureDrop is an open-source whistleblower submission system that media organizations use to securely accept documents from anonymous sources. It allows anonymous informants to send electronic documents without fear of revealing their identity. SecureDrop was originally developed by the late Aaron Swartz. The Freedom of the Press Foundation has since taken over development of the software.

SecureDrop is a mature application that was built with a security mindset from the early stages. It uses the Tor network, segregated servers, and air-gapped Tails live operating systems to preserve privacy and anonymity. The design is well thought-out and SecureDrop has undergone two prior, public security penetration tests which covered most of the low-hanging fruits. We reviewed both the application stack and code base, specifically the changes since the 0.2 release. We also provided defense-in-depth recommendations for the web application and stack configuration.

Freedom of the Press Foundation released an article covering the research. You can also find the complete, public version of the report on our GitHub repository. We would like to thank the Open Technology Fund for making this engagement possible, and the Freedom of Press Foundation team, which was incredibly helpful. iSEC hopes that SecureDrop will continue to bring secure communication between journalists and their sources in the future.

Time-Of-Check-to-Time-Of-Use (TOCTOU) vulnerabilities have been known for decades, but are still frequently discovered in modern code. This diverse class of vulnerabilities can occur on any platform or architecture, across many types of systems. These vulnerabilities are not well understood in the development industry. Even when recognized, attempts to mitigate the threat often just move it, rather that solving the issue.

TOCTOU vulnerabilities occur where a developer has tried to avoid a security risk by checking the validity or trustworthiness of an attacker-controlled resource that, if it were malicious, could result in undesirable behavior. If the check passes, the resource is trusted and used. If an attacker is able to tamper with the resource between check and use, then whatever security the check was intended to provide can be bypassed, exposing the system to threats such as elevation of privilege. Depending on the scenario, there are a number of possible mitigations to TOCTOU vulnerabilities.

iSEC Partners has published a whitepaper that aims to help software engineers recognize and avoid TOCTOU vulnerabilities. The paper is aimed at architects, developers, and testers, and covers identifying and mitigating TOCTOU vulnerabilities. We provide examples for a number of scenarios where TOCTOU vulnerabilities may be found, with explanations and suggested fixes. Although it is not possible to cover every possible TOCTOU scenario, we provide the knowledge necessary to recognize potential TOCTOU risks in any context, and determine the best mitigation.

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.

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.

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</pre>
1. Answer "yes" to the question "Would you like to ensure that all IAM users belong to a given IAM group?"
1. Enter the name of your common group (*e.g.* AllUsers)
1. Enter "yes" or "y" to confirm
1. Change the level if desired
1. 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](/images/aws/awsscout2-iam-user-commongroup-1.png)

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](/images/aws/awsscout2-iam-user-commongroup-2.png)

### 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.

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.