iSEC reviews SecureDrop
23 Mar 2015 - Valentin Leon
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.
Recognizing and Preventing TOCTOU Whitepaper
03 Mar 2015 - Christopher Hacking
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
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
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
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
to the group.
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
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
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:
- Run the rules generator with the following command line:
./RulesGenerator.py --ruleset_name isec --services iam
- Answer "yes" to the question "Would you like to ensure that all IAM users belong to a given IAM group?"
- Enter the name of your common group (e.g. AllUsers)
- Enter "yes" or "y" to confirm
- Change the level if desired
- 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.
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.
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:
- Share credentials between employees.
- 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
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
- 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.