iSEC Research Labs

Introducing opinel: Scout2's favorite tool

Mon, 03 Aug 2015 11:08:00 +0000

With boto3 being stable and generally available¹, NCC took the opportunity to migrate Scout2 and AWS-recipes to boto3. As part of that migration effort, we decided to publish the formerly-known-as AWSUtils repository – used by Scout2 and AWS-recipes – as a python package required by these tools, rather than requiring users to work with Git submodules. We’ve also added more flexibility when working with MFA-protected API calls and improved versioning across the project.

opinel

To avoid name conflicts, we decided to rename the shared AWSUtils code to a less misleading name: opinel. The opinel package is published on PyPI, and thus can be installed using pip and easy_install. The corresponding source code is still open-sourced on Github at https://github.com/iSECPartners/opinel. As a result, Scout2 and AWS-recipes have been modified to list opinel as a requirement, which significantly simplifies installation and management of this shared code.

Support for Python 2.7 and 3.x

Because boto3 supports both Python2 and Python3, we decided to make sure that the code we build on top of that package has similar properties. As a result, the latest versions of Scout2 and AWS-recipes support Python 2.7 and 3.x. Note that opinel will NOT work with Python 2.6.

Modification of the MFA workflow

As requested by a user of AWS-recipes², we modified the workflow when using MFA-protected API access to no longer store the long-lived credentials in a separate file. As a result, the .aws/credentials.no-mfa file is no longer supported and all credentials are stored in the standard AWS credentials file under .aws/credentials. Usage of the existing tools remains unchanged, but the long-lived credentials are now accessible via a new profile name: profile_name-nomfa. This allows users to work with both STS and long-lived credentials if need be.

If you already had configured your environment to work with MFA-protected API access, you will need to copy your long-lived credentials back to the .aws/credentials file. This can be done with a simple command such as the following:

cat ~/.aws/credentials.no-mfa | sed -e 's/]$/-nomfa]/g' >> ~/.aws/credentials

Support to use assumed-role credentials

With this new workflow implemented, we created a new recipe that allows configuration of role-credentials in the .aws/credentials file. When the following command is run, it uses the credentials associated with the isecpartners profile to request role credentials for the IAM-Scout2 role. The role credentials are then written in the .aws/credentials file in a new profile named isecpartners-Scout2, which is the profile name appended by the role session name.

$ ./aws_recipes_assume_role.py --profile isecpartners --role-arn arn:aws:iam::AWS_ACCOUNT_ID:role/IAM-Scout2 --role-session-name Scout2

Users can then use their favorite tools that support profiles. For example, Scout2 could be run with the following command line:

$ ./Scout2.py --profile isecpartners-Scout2

Note that this recipe supports MFA if the assumed role requires it:

If you never configured your environment to work with MFA, you can provide your MFA serial number (ARN) and current token code as arguments.
If you already configured your environment to work with MFA and stored your MFA serial in the .aws/credentials file, you just need to pass your token code as an additional argument.
Finally, if you already initiated an STS session, you do not need to provide a new token code and can run the command as above.

Conclusion

With the release of opinel, we hope to simplify distribution and management of the code shared between Scout2 and AWS-recipes. Additionally, we significantly modified the workflow and credentials storage when working with MFA-protected API calls, which allows users to use both their long-lived and STS credentials.

IAM user management strategy (part 2)

Tue, 09 Jun 2015 09:20:00 +0000

The previous [IAM user management strategy] (/aws/2015/02/24/iam_user_management.html) post discussed how usage of IAM groups enables AWS administrators to consistently grant privileges and enforce a number of security rules (such as MFA-protected API access). This blog post will build on this idea by introducing category groups and documenting new tools to improve IAM user management.

Categorize your IAM users

For a variety of reasons, applying a single set of security rules to all IAM users is not always practical. For example, because many applications running in AWS predate IAM roles, numerous environments still rely on the existence of headless IAM users. Additionally, third parties may be granted access to an AWS account for a number of reasons but may not be able to comply with the same set of security rules that employees follow. For this reason, NCC recommends using category groups to sort IAM users and reliably enforce appropriate security measures. For example, one group for all human users and a second for all headless users may be created: MFA-protected API access and password management are not relevant for headless users. Furthermore, human users may be categorized into several groups such as employees and contractors: API access can be restricted to the corporate IP range for employees but might not be achievable for contractors.

Note 1: The set of category groups should define all types of IAM users that may exist in your AWS account and each IAM user should belong to one – and only one – category group (they may belong to other groups though).

Note 2: The common group and category groups should be used to enable enforcing security in one’s AWS environment. Policies attached to these groups should be carefully reviewed and grant the minimum set of privileges necessary for this type of IAM user (e.g. credential management for humans).

Example of category groups

The rest of this article describes a number of tools developed and used by NCC to help implement this IAM user management strategy. These tools can be found in the AWS-Recipes repository. We will use our test AWS environment as an example, in which we use three category groups in addition to the AllUsers common group:

AllHumans, the group all employees must belong to.
AllHeadlessUsers, the group all headless IAM users must belong to.
AllMisconfiguredUsers, a placeholder for sample misconfigured users.

We also have an IAM user naming convention that requires usernames to match the following schema:

Employees: firstname initial appended with lastname
Headless user: name of the service prefixed with HeadlessUser-
Misconfigured: description of the misconfiguration prefixed with MisconfiguredUser-

Based on these rules, we created a configuration file stored under .aws/recipes/isecpartners.json, with isecpartners matching the profile’s name. If you do not use profiles, the configuration will be under .aws/recipes/default.json.

{
    "common_groups": [ "AllUsers" ],
    "category_groups": [
        "AllHumanUsers",
        "AllHeadlessUsers",
        "AllMisconfiguredUsers"
    ],
    "category_regex": [
        "",
        "^Headless-(.*)",
        "^MisconfiguredUser-(.*)"
    ],
    "profile_name": [ "isecpartners" ]
}

This configuration file declares the name of the common IAM group and two lists related to the categorization of IAM users:

A list of category groups.
A list of regular expressions matching our naming convention.

Note 1: If you do not have a naming convention in place to distinguish the type of user, remove the category_regex attribute from your configuration file.

Note 2: If a regular expression is only applicable to a subset of category groups, you must ensure that both lists have the same length and use an empty string for groups that cannot be automatically associated (see the AllHumanUsers group in our example).

Note 3: Use of a configuration file is not necessary as all values may be passed as command line arguments. If a configuration file exists and a value is passed as an argument, the value passed via the command line will be used.

Create your default groups with aws_iam_create_default_groups.py

The purpose of this tool is to create IAM groups whose name matches the common and category groups specified in the above configuration file. Running the following command results in four new groups being created if they did not already exist.

./aws_iam_create_default_groups.py --profile isecpartners

(Automatically) sort IAM users with aws_iam_sort_users.py.

This tool iterates through all IAM users and attempts to automatically detect the IAM groups each user should belong to. For convenience, we recommend adding the following to your AWS recipes configuration files:

"aws_sort_users.py": {
    "create_groups": false,
},
"force_common_group": true

This specifies default values for additional arguments to be set when running aws_iam_sort_users.py. Specifically, with these values, running this tool will automatically add all IAM users to the common group AllUsers and will not attempt to create the default groups (not necessary as we already did this). Additionally, this tool checks that each IAM user belongs to one of the category groups. If this is not the case and the username matches a regular expression, the user is automatically added to the matching category group. Otherwise, a multi-choice prompt appears to allow manual selection of the appropriate category group.

Additional advantages of configuration files

Besides helping with simplification of these tools’ usage, this new AWS-recipe configuration file can be used across tools, allowing for more consistent rule enforcement. For example, the aws_iam_create_user.py. tool uses this configuration file and applies the same business logic to add users to the common group and appropriate category group at user creation time. In our test environment, for example, running the following command automatically added the new user to the MisconfiguredUser group:

$ ./aws_iam_create_user.py --profile isecpartners --users MisconfiguredUser-BlogPostExample
Creating user MisconfiguredUser-BlogPostExample...
Save unencrypted value (y/n)? y
User 'MisconfiguredUser-BlogPostExample' does not belong to the mandatory common group 'AllUsers'. Do you want to remediate this now (y/n)? y
User 'MisconfiguredUser-BlogPostExample' does not belong to any of the category group (AllHumanUsers, AllHeadlessUsers, AllMisconfiguredUsers). Automatically adding...
Enabling MFA for user MisconfiguredUser-BlogPostExample...

Conclusion

While efficient and reliable management of IAM users can be challenging, using the right strategy and tools significantly simplifies this process. Creation and use of a naming convention for IAM users enables automated user management and enforcement of security rules.

iSEC audit of MediaWiki

Tue, 21 Apr 2015 12:00:00 +0000

iSEC Partners is happy to announce the public release of our latest project with the Open Technology Fund: the review of Wikimedia Foundation’s MediaWiki. The Open Technology Fund engaged iSEC Partners to perform a source-code assisted security review of MediaWiki, the wiki engine behind Wikipedia, for a duration of two weeks at the very beginning of this year.

MediaWiki is a PHP application that evolved through a long history of patches and code rewrites. The MediaWiki engine not only drives public wikis such as Wikipedia, but it also powers many private or corporate wikis, where only a limited set of users can read and edit, therefore page content must be protected securely. The Wikimedia Foundation also seeks to ensure that their readers cannot be de-anonymized, including controls such as preventing an attacker from correlating which articles a victim reads or whether or not the victim has registered.

Most of the outward-facing attack surfaces have already been reviewed for security flaws due to the exposure of Wikipedia to the Internet. iSEC focused on traditional web vulnerabilities and on eight areas of concern prioritized by the Wikimedia Foundation. The iSEC consultants were able to find a total of fourteen issues, including two of high severity. Most of the high and medium severity vulnerabilities are related to data validation and allow for various common attacks including XSS, DoS, and CSRF. Detailed descriptions of the vulnerabilities, including proof-of-concepts, can be found in the complete report.

The Wikimedia 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 Wikimedia Foundation team for their help and support. iSEC hopes this audit will help MediaWiki continue to bring content securely to countless readers in the future.

Work daily with enforced MFA-protected API access

Fri, 03 Apr 2015 14:10:00 +0000

AWS Security Token Service

The AWS Security Token Service (STS) is the gateway used to create sessions when MFA-protected API access is enabled. This service allows IAM users to retrieve short-lived credentials (i.e access key ID, secret access key, and session token) in exchange for their long-lived credentials (i.e. AWS access key ID and secret key) and their current authentication code. When enforcing MFA-protected API access, as recommended in the previous Use and enforce Multi-Factor Authentication post, IAM users must use these short-lived credentials to access other AWS services.

Challenges with MFA-protected API access

When MFA-protected API access is enforced, managing AWS access keys becomes challenging because configuration files that contain these credentials must be updated regularly. Users must also ensure that they do not lose their long-lived credentials when modifying the configuration files to write their short-lived credentials. In order to help with this workflow, iSEC wrote and released several simple tools in the AWS-recipes repository.

The collection of tools that we will discussed below uses the “new and standardized way to manage credentials in the AWS SDKs”, meaning that SDKs are expecting to read credentials from the .aws/credentials file under the user’s home or profile directory.

aws_recipes_configure_iam.py

The aws_recipes_configure_iam.py tool allows users to configure and store their long-lived credentials in a new, non-standard, .aws/credentials.no-mfa file. In addition to prompting for the AWS access key ID and secret key, this tool also prompts for the MFA device serial number because this information must be provided when making calls to the STS API. Similar to the AWS CLI and SDKs, it supports profile names. The following code snippet is an example of calling this tool to configure a new profile called isecpartners:

$ ./aws_recipes_configure_iam.py --profile isecpartners
AWS Access Key ID: AWS_KEY_ID
AWS Secret Access Key: AWS_SECRET_KEY
AWS MFA serial: arn:aws:iam::AWS_ACCOUNT_ID:mfa/USER_NAME

When looking at the .aws folder, we can see that a credentials.no-mfa file exists and that it contains the credentials that were just entered:

$ ls -l ~/.aws
total 4
-rw-r--r-- 1 loic loic 93 Apr  3 14:00 credentials.no-mfa
$ cat ~/.aws/credentials.no-mfa
[isecpartners]
aws_access_key_id = AWS_KEY_ID
aws_secret_access_key = AWS_SECRET_KEY
aws_mfa_serial = arn:aws:iam::AWS_ACCOUNT_ID:mfa/USER_NAME

Now that long-lived credentials are configured, we can use the next tool to call the AWS STS API and request short-lived credentials that will be used to access other AWS services.

Note: This workflow was modified since the publication of this blog post and the .aws/credentials.no-mfa file is no longer used, refer to this new blog post for further details.

aws_recipes_init_sts_session.py

The aws_recipes_init_sts_session.py tool reads long-lived credentials configured in the .aws/credentials.no-mfa file, prompts users for their MFA code, and retrieves STS credentials (AWS access key ID, AWS secret key, and session token). The short-lived credentials are then saved under the standardized .aws/credentials file to be accessible to the AWS CLI and other tools built with the AWS SDKs. The following code snippet demonstrates calling this tool to request an STS session token:

$ ./aws_recipes_init_sts_session.py --profile isecpartners
Enter your MFA code: 123456
Successfully configured the session token for profile 'isecpartners'.

When looking at the .aws folder, we can see that a standard credentials file now exists as well and that it contains the short-lived credentials:

$ ls -l ~/.aws
total 8
-rw-r--r-- 1 loic loic 576 Apr  3 14:14 credentials
-rw-r--r-- 1 loic loic 179 Apr  3 14:00 credentials.no-mfa
$ cat ~/.aws/credentials
[isecpartners]
aws_access_key_id = STS_KEY_ID
aws_secret_access_key = STS_SECRET_KEY
aws_mfa_serial = arn:aws:iam::AWS_ACCOUNT_ID:mfa/USER_NAME
aws_session_token = AWS//////////SESSION_TOKEN

Now that the short-lived credentials are configured, we can use the AWS CLI or other tools built with the AWS SDKs that read credentials from this standard location. When the STS session expires, users just need to re-run the aws_recipes_init_sts_session.py tool and the standard credentials file will be updated with new valid short-lived credentials.

Note: This workflow was modified since the publication of this blog post and the .aws/credentials.no-mfa file is no longer used, refer to this new blog post for further details.

Conclusion

By using this pair of tools to manage their AWS access keys, IAM users can easily use the AWS CLI and other tools built with various AWS SDKs in environments that have been secured and enforce MFA-protected API access.

Use and enforce Multi-Factor Authentication

Thu, 02 Apr 2015 14:10:00 +0000

What is Multi-Factor Authentication?

When enabled, Multi-Factor Authentication (MFA) provides strong defense-in-depth against compromises of credentials. MFA-enabled users have a device that periodically generates a new authentication code (i.e. one-time password); they need to enter the current authentication code along with their static credentials (i.e. username and password) in order to successfully authenticate. In addition to supporting MFA when accessing the web console (i.e. password-based authentication), AWS also offers MFA-protected API access for users who work with AWS access keys. Through the Security Token Service (STS), IAM users can request temporary credentials in exchange for their long-lived credentials (i.e. AWS access key ID and secret key) and their current authentication code.

Why should one use and enforce MFA?

For companies deploying their application in the cloud, a breach that results in unauthorized access to the management console — or API — is the worst-case scenario. While a number of AWS administrators have realized the importance of enabling MFA when they access the web console, a limited number of them enforce MFA-protected API access. This represents a huge gap in one’s security posture because AWS access keys do not come with as many security features as passwords do:

AWS administrators can enforce password expiration; this is currently not possible for AWS access keys.
While it is probably safe to assume that most AWS administrators do not store their password in plaintext, most of them use AWS access keys. By design, these keys are meant to be stored in plaintext files that are accessed by tools built with the various AWS SDKs.
A lost password is a forgotten password; a lost key is a key stored in a lost file, which may be on an unencrypted storage device (e.g. hard drive or USB Flash drive).

Because AWS access keys are long-lived credentials that are stored in plaintext files, they are more susceptible to compromise than passwords. It is therefore necessary to enable MFA when the AWS API is accessed using these keys and not only when users sign in using their passwords.

How can one enforce MFA?

Unfortunately, at time of writing, AWS does not offer an option to enforce MFA-protected API access via a global setting. Therefore, AWS account administrators must carefully manage their IAM users and develop a strategy to reliably achieve this. In order to enforce MFA-protected API access, iSEC recommends the following:

Create a common IAM group that all IAM users belong to, as discussed in the previous IAM user management strategy post.
Add the following policy (also available on Github) to enforce MFA for all users who belong to this group.

This policy will enforce MFA regardless of how the IAM user authenticated with AWS; it will be effective whether they use password-based or key-based authentication.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "Null":{"aws:MultiFactorAuthAge":"true"}
      }
    },
    {
      "Effect": "Deny",
      "Action": "*",
      "Resource": "*",
      "Condition": {
        "NumericGreaterThan":{"aws:MultiFactorAuthAge":"28800"}
      }
    }
  ]
}

The first statement in the above policy denies all actions if the aws:MultiFactorAuthAge key is not present; this key only exists if MFA is used¹.

The second statement verifies that the validation of the MFA code was performed less than eight hours ago. Temporary credentials may be valid for a duration between fifteen minutes and thirty-six hours². iSEC recommends requiring users to initiate a new session at least once a day.

Note: An “explicit deny” means that, regardless of other policies granted to a user, this deny rule will prevail. More information about the IAM policy evaluation logic can be found in the AWS documentation at https://docs.aws.amazon.com/IAM/latest/UserGuide/AccessPolicyLanguage_EvaluationLogic.html.

Use AWS Scout2 to detect users without MFA

The default ruleset used by AWS Scout2 includes a rule that checks for IAM users who have password-based authentication enabled but do not have an MFA device configured. If Scout2 detects IAM users with password-based authentication enabled and no MFA device, it will document a “Lack of MFA” security risk in the IAM menu dropdown, as illustrated in the below screenshot.

When clicked, this “Lack of MFA” link filters the list of IAM users to display those who have password-based authentication enabled but no MFA device configured. The red “No” following “Multi-Factor enabled” indicates a danger tied to that particular IAM user.

How can one use MFA with command line tools?

Users of the AWS CLI (and other command line tools) have several methods to configure their credentials, such as environment variables, configuration files, or command line arguments. However, updating these settings on a daily basis when MFA-protected API access is enabled is inconvenient. To help facilitate this work flow, iSEC has created a set of Python tools and released them in the AWS-recipes repository. Further details about these tools will be published in the next blog post.

Additional information about MFA with AWS is available in the AWS documentation at https://docs.aws.amazon.com/IAM/latest/UserGuide/Using_ManagingMFA.html.

Conclusion

Enforcing Multi-Factor Authentication for all IAM users is extremely important in order to mitigate the risks of credentials compromise (especially the AWS access key ID and secret). This aspect of security is commonly overlooked and may result in catastrophic damages. By using a strict strategy for management of IAM users and the above IAM policy, AWS administrators may significantly reduce risks of account compromise.

iSEC reviews SecureDrop

Mon, 23 Mar 2015 12:00:00 +0000

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

Tue, 03 Mar 2015 12:25:55 +0000

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.

IAM user management strategy

Tue, 24 Feb 2015 20:49:00 +0000

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:

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.

Do not use your AWS root account

Mon, 23 Feb 2015 08:42:00 +0000

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

Sun, 22 Feb 2015 22:24:00 +0000

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

Wed, 11 Feb 2015 19:25:00 +0000

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

Mon, 09 Feb 2015 11:20:00 +0000

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!

Vulnerability Overview: Ghost (CVE-2015-0235)

Tue, 27 Jan 2015 00:00:00 +0000

Executive Summary

An alert about a severe vulnerability discovered by the Qualys security team was issued on Tuesday, January 27 2015. This vulnerability allows a local or remote attacker to execute code within the context of an application linked with certain versions of the glibc library. The vulnerability is triggered by a buffer overflow in the gethostbyname() function, called when resolving a hostname to an IP.

Immediate patches are required to fix a vulnerability in glibc that allows arbitrary code execution from unauthenticated users. It is necessary to restart computers or processes following patching.

Ghost enables code execution, arbitrary data disclosure, and system compromise from unauthenticated remote attackers. The ways that a system could be vulnerable to this bug are numerous, and no exhaustive list could be compiled. Patching is required immediately, as a proof-of-concept is soon to be publicly released.

What is vulnerable?

This vulnerability has been in production glibc versions since November 2000, and was patched in source code since May 2013:

glibc 2.2 through 2.17 (inclusive) are vulnerable
glibc 2.18 through 2.20 (inclusive) are NOT vulnerable
prior versions of glibc (<= 2.1.3) are NOT vulnerable

Even if you are not directly using the gethostbyname() function, a large number of software packages incorporate the call and are vulnerable.

Service and software that can be exploited include, but is not limited to:

clockdiff
procmail
pppd (SUID root)
Exim Internet Mailer

An exploit has been written against Exim, and a working PoC is soon to be publicly disclosed.

Who is vulnerable?

Organizations that ship applications statically linked against vulnerable versions of glibc, or ship appliances built on Linux distributions that have a vulnerable version of glibc. This includes virtual appliances/virtual machines.
Organizations or end users that have a Linux desktop or server running with a vulnerable version of glibc, or use applications statically linked against a vulnerable version of glibc. This also extends to appliances and virtual machines. Since this vulnerability has been present in glibc for over a decade, out of date or EOL’d devices are likely to be vulnerable as well.

The following Linux distributions contains a vulnerable version of the glibc: ***

</table> *** ## Patching iSEC and Matasano recommend performing the following discovery and remediation steps. ### Discovery First, determine if your Linux is vulnerable. Either consult the [table above](#versions), contact your vendor, or get the version from the version from the library itself. To do the latter, run `locate libc.so.6` to find the location of your libc, then run that file, and it will print out version information. ### Fix If your distribution has patches available, install those patches. Otherwise: * Update to glibc 2.18 or newer * Restart all processes that load the glibc library * Issue new binaries for software statically linked against a vulnerable version of the glibc library. ## Technical Overview The [__nss_hostname_digits_dots()](https://sourceware.org/git/?p=glibc.git;a=blobdiff;f=nss/digits_dots.c;h=e007ef47a41b69437655c26565689be393705a82;hp=2b862956e9a8c39bbccbea982add1d7ab2d16ab2;hb=d5dd6189d506068ed11c8bfa1e1e9bffde04decd;hpb=fef94eab0bd308d5059a2588c753bf9a4926845d) function of the GNU C Library (glibc) is vulnerable to a buffer overflow. This function incorrectly calculates the size of a buffer to allocate, and under certain circumstances, arbitrary data can overwrite adjacent memory resulting in a heap based buffer overflow. While only a maximum of four (4) bytes of memory can be overwritten, it has been demonstrated that this was enough to bypass exploitation mitigations (such as ASLR and PIE) and grant code execution. The `__nss_hostname_digits_dots()` function is usually not called directly but is called from the `gethostbyname()` and `gethostbyname2()` glibc functions. In practice, this can be exploited whenever the hostname passed is long enough (at least 1KB) and passes other sanity checks: * The hostname is composed entirely of digits and dots * The hostname starts and ends with a digit * The hostname must be of the form of `a`, `a.b`, `a.b.c` or `a.b.c.d` ## References * [CVE-2015-0235](http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-0235) * [https://community.qualys.com/blogs/laws-of-vulnerabilities/2015/01/27/the-ghost-vulnerability](https://community.qualys.com/blogs/laws-of-vulnerabilities/2015/01/27/the-ghost-vulnerability) * [https://www.qualys.com/research/security-advisories/GHOST-CVE-2015-0235.txt](https://www.qualys.com/research/security-advisories/GHOST-CVE-2015-0235.txt) * [http://ma.ttias.be/critical-glibc-update-cve-2015-0235-gethostbyname-calls/](http://ma.ttias.be/critical-glibc-update-cve-2015-0235-gethostbyname-calls/) * [http://www.frsag.org/pipermail/frsag/2015-January/005722.html](http://www.frsag.org/pipermail/frsag/2015-January/005722.html) * [https://sourceware.org/bugzilla/show_bug.cgi?id=15014](https://sourceware.org/bugzilla/show_bug.cgi?id=15014) * [https://rhn.redhat.com/errata/RHSA-2015-0090.html](https://rhn.redhat.com/errata/RHSA-2015-0090.html) * [https://launchpad.net/ubuntu/+source/eglibc](https://launchpad.net/ubuntu/+source/eglibc) * [https://security-tracker.debian.org/tracker/CVE-2015-0235](https://security-tracker.debian.org/tracker/CVE-2015-0235)

Ubuntu
10.04 LTS	fix available	fixed in libc6 2.11.1-0ubuntu7.20
12.04 LTS	fix available	fixed in libc6 2.15-0ubuntu10.10
14 and newer	not vulnerable
Debian
6.x - squeeze	vulnerable
6.x - squeeze (LTS)	vulnerable
7.x - wheezy	vulnerable </tr>
7.x - wheezy (security)	fix available	fixed in glib 2.13-38+deb7u7
8.0 - jesse	not vulnerable
dev - sid	not vulnerable
Red Hat Enterprise fix information</td> </tr>
Desktop (v. 5)	fix available	fixed in glibc-2.5-123.el5_11.1
Desktop (v. 6)	fix available	fixed in glibc-2.12-1.149.el6_6.5
Desktop (v. 7)	fix available	fixed in glibc-2.17-55.el7_0.5
HPC Node (v. 6)	fix available	fixed in glibc-2.12-1.149.el6_6.5
HPC Node (v. 7)	fix available	fixed in glibc-2.17-55.el7_0.5
Server (v. 5)	fix available	fixed in glibc-2.5-123.el5_11.1
Server (v. 6)	fix available	fixed in glibc-2.12-1.149.el6_6.5
Server (v. 7)	fix available	fixed in glibc-2.17-55.el7_0.5
Server EUS (v. 6.6.z)	fix available	fixed in glibc-2.12-1.149.el6_6.5
Workstation (v. 6)	fix available	fixed in glibc-2.12-1.149.el6_6.5
Workstation (v. 7)	fix available	fixed in glibc-2.17-55.el7_0.5
RHEL 4 ELS	fix available	fixed in glibc-2.3.4-2.57.el4.2
Mint
13 "Maya"	fix available	Tracks Ubuntu 12.04, should get update from Ubuntu servers
17 "Qiana"	not vulnerable
17.1 "Rebecca"	not vulnerable
Gentoo libc information
stable	not vulnerable	uses glibc 2.19-r1
Arch fixed in all releases since August 2013, discussion here and package info here
anything recent	not vulnerable
Fedora discussion
19 and earlier	vulnerable	uses glibc 2.17 and earlier
20	not vulnerable	uses glibc 2.18
21	not vulnerable	uses glibc 2.20
Mandriva Linux
all	vulnerable	appears to use glibc 2.16
openSUSE vulnerability information
Enterprise 11 & older	vulnerable
Enterprise 12	not vulnerable
openSUSE 13.1 & newer	not vulnerable
Slackware
current	not vulnerable	uses glibc 2.20
14.1 and earlier	vulnerable	uses glibc 2.17 and earlier </tr>
Knoppix information about glibc versions
7.2 and earlier	vulnerable	uses glibc 2.17 and earlier
7.4 and later	not vulnerable	uses glibc 2.19 and later
Slax
all	vulnerable	appears to use glibc 2.15
CentOS
CentOS-5	fix available	fixed in glibc-2.5-123.el5_11
CentOS-6	fix available	fixed in glibc-2.12-1.149.el6_6.5
CentOS-7	fix available	fixed in glibc-2.17-55.el7_0.5

Jailbreak, updated and open-sourced

Mon, 19 Jan 2015 13:37:00 +0000

Jailbreak allows a user to export certificates from Microsoft certificate stores even if the certificate has been marked as non-exportable; this can be useful if you need to make backups of the certificates or perform some other form of testing. The utility was first released in 2007, but at that time was closed source and OS version dependent, as it patched DLLs in memory. The new 4.0 release maintains all of the previous functionality but is now open source (under a BSD license) and uses a function hooking approach to remove OS version dependencies. There are pre-compiled binaries that should work on all versions of Windows from Windows XP up to Windows 8.1 on 32-bit and 64-bit systems.

A Simple DLL Injection Utility

Wed, 29 Oct 2014 11:08:35 +0000

NCLoader is a simple command-line DLL injection tool for windows. It takes a PID or process name as parameter and accounts for systems with a high number of running processes. Being single-featured, the utility aims for simplicity with its single C code file implementing the well known VirtualAllocEx+WriteProcessMemory+CreateRemoteThread method. The code aims for cleanliness (no warnings compilation on MSVC), readability and includes verbose error checking. Statically compiled binaries for x86 and x64 architectures are provided.

Check out the ncloader repository.

Shellshock Advisory

Thu, 25 Sep 2014 01:23:55 +0000

Executive Summary

Immediate patches are required to fix a vulnerability in bash that allows arbitrary code execution from unauthenticated users.

The full impact of vulnerable vectors may never be enumerated, so patching is required immediately, as in-the-wild attacks are being seen.

The vulnerability is not fully resolved by the available patch, so a second round of patching will be required once the subsequent patch is available.

It is not necessary to restart computers or processes following patching.

Impact & Determining Exposure

Shellshock enables code execution, arbitrary file disclosure, and system compromise from unauthenticated remote attackers. The ways that a system could be vulnerable to this bug are numerous, and no exhaustive list could be compiled. However, some of the common scenarios are:

Web servers using CGI scripts that are written in bash
Web servers using CGI scripts that are written in other languages that invoke certain function calls:
- C-based scripts calling system() or popen()
- Python-based scripts that call os.system() or os.popen()
- PHP-based scripts that call system() or exec() (when run in CGI mode)
- Perl-based scripts that invoke shell commands
Restricted SSH shells using ForceCommand can be bypassed. Some git and subversion deployments use such restricted shells.
If an attacker is in a position to forge DHCP responses, it can enable root-level code execution in DHCP clients
Set-UID applications may allow local escalation to root
CUPS-based printer daemons are likely to be affected
Mac and Linux Desktops are affected, and are likely to allow privilege escalation to a root user

Certain common deployments are not affected:

Regular use of SSH is not affected as users already have shell access
PHP scripts that use mod_php are not affected, nor is mod_python or mod_perl
Sudo by itself is not affected

Finally, there is no need to restart services after patching. Running processes have passed the window of vulnerability and new processes will be running the new, patched code.

Patching

Linux Operating Systems have deployed patches:

RHEL: https://rhn.redhat.com/errata/RHSA-2014-1293.html
Ubuntu: http://www.ubuntu.com/usn/usn-2362-1/
Debian: https://lists.debian.org/debian-security-announce/2014/msg00220.html
CentOS: http://centosnow.blogspot.com/2014/09/critical-bash-updates-for-centos-5.html
Gentoo: An updated bash package is available in portage
OpenSUSE: http://support.novell.com/security/cve/CVE-2014-6271.html

Mac OS X is not yet patched, but manual instructions to recompile bash from source are available at: https://apple.stackexchange.com/questions/146849/

An Imperfect Fix

Unfortunately, the patch supplied is incomplete. As noted by Tavis Ormandy, other vectors still exist to bypass protections and perform invalid actions, such as overwriting files. While no one has publicly demonstrated code execution for this bypass, it seems likely to be possible. A second CVE (CVE-2014-7169) has been created to track this issue.

Red Hat has an experimental mitigation that requires many manual steps to use available at: https://access.redhat.com/articles/1200223

Red Hat and NCC both advise deploying the available patch immediately and being prepared to deploy a second patch, when one becomes stable and tested shortly.

In the Wild Attacks

Shellshock is being actively scanned for and exploited on the Internet at-large currently.

Robert Graham is one security researcher who has initiated an Internet-wide scan from the IP address 209.126.230.72. His scan, and many others, use a ping command to call back to a server, alerting them that your server is vulnerable – although this is not the only mechanism one could use.

Besides internet scans, several Metasploit modules are available, and a few exploits have been posted online. These include exploits that provide shell access to a server, read arbitrary files the web server has access to read, and a report of a payload that exploits a kernel vulnerability. The kernel exploit is not yet confirmed to exploit a previously known or unknown vulnerability.

IDS Signatures and Detection

IDS vendors are producing rules that will attempt to detect and block attempted exploitation of this issue. Rules are available for:

mod_security: https://access.redhat.com/articles/1200223
iptables: https://access.redhat.com/articles/1200223
Snort: http://www.volexity.com/blog/?p=19
Suricata: http://www.volexity.com/blog/?p=19
Akamai has rules deployed in its WAF products: https://blogs.akamai.com/2014/09/environment-bashing.html
CloudFlare has similarly deployed rules in its WAF Products: https://blog.cloudflare.com/bash-vulnerability-cve-2014-6271-patched/

Technical Details of the Flaw

The vulnerability was discovered by Stephane Chazelas and can be tested for manually using the following command:

env x='() { :;}; echo vulnerable' bash -c "echo this is a test"

If it outputs ‘vulnerable’, the system is vulnerable. This bug arises because of an unusual feature of bash that allows exporting functions as well as environment variables. This feature is specific to bash, and no other shells are known to be vulnerable. (However, on some systems, other shells will actually be symlinks to bash.)

The actual vulnerability is in the parser for these exported functions. It does not parse the function correctly, and upon invocation will automatically execute trailing code defined after the function.

Any variable beginning with “() {“ is automatically treated as a function – but the aspect that makes this bug so prevalent is that environment variables are populated in unexpected places from user input. For example, environment variables like HTTP_COOKIE and HTTP_USER_AGENT are often populated for CGI scripts. And PHP, Perl, Python, and other scripts are often run as CGI scripts under a web server.

This results in a perfect storm of unexpected vectors of automatic remote code execution, most commonly on web servers. For more details, a good technical blog post is: http://lcamtuf.blogspot.co.uk/2014/09/quick-notes-about-bash-bug-its-impact.html

References

Perfect Forward Security Whitepaper

Thu, 04 Sep 2014 11:25:55 +0000

Encrypted communication channels were created so nobody could read confidential communications - this means not only during the conversation, but also any time after it. But adversaries have the ability to monitor, record, and attack communication retroactively. Disclosure of state sponsored monitoring of electronic communications and the threat of retroactive decryption of traffic of millions of people has created an urge for an extra layer of security and privacy for all electronic communications.

iSEC has published a whitepaper that looks into how Forward Security can be used to protect online communication - but covering much more than just TLS. Besides explaining the groundwork, we also explore the difference between Forward Security and Perfect Forward Security and mechanisms outside any specific implementation, modeling a generic protocol and building it up showing how Forward Security can be achieved. And on the implementation level, we also cover how to enable Forward Security in protocols you have deployed in your network today - giving a simple explanation, real life applications, advantages, and implementation in protocols like Off-the-Record (OTR) Messaging, Secure Shell (SSH), Wireless Protected Access II Protocol (WPA2-EAP-PWD), Virtual Private Networks (VPN), and of course TLS.

Tor Browser Research Report Released

Wed, 13 Aug 2014 11:25:55 +0000

As part of our work with the Open Technology Fund, we recently worked with the Tor Project to see how Tor Browser stands up in terms of modern exploit mitigations, and what could be done to make it harder to develop exploits for.

Tor Browser is based on Firefox, so it inherits the strengths and weaknesses of Firefox — but one of the things Tor Project is working on is a security slider that will let people disable features of the browser depending on their security posture. If you’re extra paranoid you’ll ratchet it all the way up and disable Javascript; if you’re less paranoid, you can put it on ‘Low’ and disable things like obscure font rendering features only used in South East Asia.

Tor Project has published a blog post that summarizes the report from their point of view and links to a number of issues on their bugtracker and other documentation.

This project was more of a research engagement than a security assessment — a lot of this engagement was identifying features that should be placed on the slider, and making recommendations for where they should land. But we looked at a lot of other more general hardening items too. We checked the status of DEP and ASLR on Windows and Mac, and found an interesting lack of exception handling on the Windows build, due to the MinGW build process (this throws SafeSEH and SEHOP out the window). We also went through, with the cooperation of the Mozilla Security team, and categorized over a hundred past security vulnerabilities in Firefox into feature category and bug type (Use-After-Free wins the latter overwhelmingly.) We analyzed a few public and private exploits, and also investigated enabling assertions in certain classes in Firefox. We have a skeleton patch for the latter, but it’s more a proof of concept than something we think they should use. One of the other major items was looking at replacing Firefox’s memory allocator (jemalloc) with a more hardened allocator (PartitionAlloc from Chrome). Fortunately, Mozilla makes this pretty easy, so most of the work is in adapting PartitionAlloc and making full use of its partition features. There are several other parts to the report, including looking at protocol handlers, media formats, and making regression tests for DOM object exposure.

We had a ton of fun working on this project and we’d like to thank Mike Perry at Tor for working with us so closely, OTF for sponsoring the work, and all the people inside iSEC and the security community we talked about this project with who gave us ideas — especially Chris Evans from Google (the author of PartitionAlloc). The report clocks in at about 30 pages, but with the appendices (which have patch files), it balloons up to a whopping 150 pages. You can find the report, and all the patch files in our publications repository.

ZigTools: An Open Source 802.15.4 Framework

Mon, 04 Aug 2014 08:30:00 +0000

ZigTools is a Python framework, which was developed to reduce the complexity in writing additional functionality in communicating with a Freakduino (a low cost Arduino based 802.15.4 platform). Features such as initializing the radio, changing channels, sniffing network traffic, sending raw data and processing that data can be written in just a few lines. This allows developers to focus on writing more complex and feature rich applications without worrying about low level communications between the radio and system.

Benefits

Sniffed data is saved in a pcap format, which can later be dissected by popular applications
Replay packets directly from pcap file
All aspects of the packet can be modified, allowing developers to test Layer 2 and 3 functionality of 802.15.4 and Zigbee systems

iSEC Partners is pleased to publicly release this version of the ZigTools framework at Black Hat USA 2014 Arsenal, a tools/demos area.

Tool Release: You'll Never (Ever) Take Me Alive!

Fri, 09 May 2014 11:25:55 +0000

A year ago, we released You’ll Never Take Me Alive — a tool that helps protects Full Disk Encrypted Windows computers from DMA and cold boot attacks.

YoNTMA runs as a background service and begins monitoring your computer any time the screen is locked. If the power cable or Ethernet cable is disconnected from the system while your laptop is locked, YoNTMA will immediately hibernate the machine to ensure that the disk encryption keys do not remain in RAM. This ensures that if a thief walks off with your powered-on laptop, your encrypted data stays protected.

It’s been a great tool that I’ve used happily, but when I got a new Macintosh, I ran up against Issue #3 — there’s no Mac version! Until today. We’re releasing a new version of YoNTMA for Macs. The source is still open and the .dmg can be downloaded from Github. Due to some tricks of how Macintoshes hibernate, you’ll need to provide your administrative password (just once) to update the power management settings to enable a secure hibernation. Or, if you’re paranoid, you can run those commands yourself and re-launch the app — don’t worry, you won’t hurt my feelings.

The only issue we’re aware of is a lingering issue in OS 10.9; that said, while I’ve experienced this issue in the past, I’m currently running 10.9 and haven’t had issues in the past few months. Feel free to test and if you have problems, open an issue on Github.

DIBF Tool Suite

Wed, 16 Apr 2014 12:01:05 +0000

Introducing iSEC Partners’ Windows driver testing suite. The source, binaries and example output are available at https://github.com/iSECPartners/DIBF under the GPLv2 license. Currently three tools are included:

DIBF - Dynamic IOCTL Brute-Forcer (and fuzzers)

This tool encompasses two distinct features. It guesses the IOCTL values that the driver accepts, and also their valid size limitations, and stores the results are in a file for future reuse. The second feature is composed of 3 dumb fuzzers: a pure random fuzzer, a sliding DWORD fuzzer and a fully asynchronous fuzzer. Any combination of the 3 fuzzers can be run sequentially, and numerous options can be set from the command line, including time limits for each fuzzer run, the maximum number of failed requests in a row (indicating further fuzzing might be pointless due to lack permission for instance) and the verbosity level. Any fuzzer run can be stopped cleanly with ctrl-c, and upon completion cumulative statistics are displayed. See the README and usage for more information on all options and features.

IOSEND - sending single IOCTL to a driver

This is a tool intended for proofing vulnerabilities and is meant to be used in conjunction with a hex editor. Once the request of interest has been crafted in the editor, this utility will send it to the driver using command line parameters. The response gets sent to stdout.

IOCODE - simple encoding/decoding utility for IO codes

This very simple tool encodes and decodes windows IOCTL control codes. It provides a user-friendly way to deal with IO encoding of device types, function number, transfer method and access type.

SSLyze v 0.9 released - Heartbleed edition

Wed, 16 Apr 2014 10:00:00 +0000

A new version of SSLyze is now available. SSLyze is a Python tool that can analyze the SSL configuration of a server by connecting to it. This version brings a few improvements and bug fixes as well as a new plugin to identify servers affected by the Heartbleed vulnerability.

Heartbleed Testing

To implement the Heartbleed check, I used the methodology described on Mozilla’s blog, which has the advantage of not directly exploiting the vulnerability unlike most Hearbleed-testing scripts that have been released. Mozilla’s technique does not retrieve memory from the server, thereby avoiding server crashes or sensitive data exposure.

Additionally, SSLyze’s implementation uses the tool’s existing networking code, allowing Heartbleed testing against multiple servers at the same time and on StartTLS services including XMPP, LDAP, SMTP, FTP and POP. Also, just like all of SSLyze’s checks, Heartbleed tests can be tunneled through an HTTPS proxy.

Full Changelog

Experimental support for Heartbleed detection; see --heartbleed. Heartbleed detection has also been added to --regular scans
Capped the maximum number of concurrent connections to around 30 per server in order to avoid DOSing the scanned servers. Scans are slightly slower but a lot less aggressive, resulting in better scan results with less timeout and connection errors
Support for Basic Authentication when tunneling scans through an HTTPS proxy with --https_tunnel
Bug fixes for IPv6 and XMPP support
Updated OpenSSL to 1.0.1g
Updated the Apple, Microsoft, Mozilla and Java trust stores
Cleaned up the text output of PluginOpenSSLCipherSuites

Download

SSLyze requires Python 2.7; the supported platforms are Windows 7 32/64 bits, Linux 32/64 bits and OS X 64 bits. Pre-compiled packages available in the release section of the project’s page on GitHub.

iSEC Completes TrueCrypt Audit

Mon, 14 Apr 2014 10:00:00 +0000

Is TrueCrypt Audited Yet? Yes, in part!

For nearly a decade, tens of millions of users have been trusting the open source encryption software, TrueCrypt. Over the past year, however, revelations about the capabilities of intelligence agencies have shaken the very foundations of much of the cryptography community. Owing to its popularity and widespread use, TrueCrypt has come under intense scrutiny with many openly asking if TrueCrypt could be trusted to function as claimed.

The Open Crypto Audit Project (OCAP) is a new organization that is attempting to answer questions of importance to the cryptography community, including those about trust in TrueCrypt. OCAP began a grassroots campaign to raise money to answer fundamental questions about TrueCrypt. These fundamental goals were identified. First, resolve questions regarding TrueCrypt’s license status. Second, produce repeatable, deterministic builds. And third, conduct a public analysis of the code.

As announced in December 2013, iSEC Partners (iSEC) worked with the Open Crypto Audit Project on the final goal – conducting a methodical analysis of TrueCrypt through code review and penetration testing.

In January 2014, iSEC Partners kicked off the engagement to audit the following portions of TrueCrypt: the Windows kernel code, the bootloader, the filesystem driver, and the areas around this code. The scope was kept narrowly focused to avoid stretching resources too thin and ensure that the review conducted was thorough and robust.

The audit conducted by iSEC is now complete and the findings are available now. iSEC did not identify any issues considered “high severity” during this testing. iSEC found no evidence of backdoors or intentional flaws. Several weaknesses and common kernel vulnerabilities were identified, including kernel pointer disclosure, but none of them appeared to present immediate exploitation vectors. All identified findings appeared accidental. Overall, iSEC does think changes can be made to improve code quality and maintainability, and that the build process should be updated to rely on recent tools with trustworthy provenance. In sum, while TrueCrypt does not have the most polished programming style, there is nothing immediately dangerous to report.

Given TrueCrypt’s popularity, the entire security industry benefits from knowing more about the software and how secure it is. iSEC believes in the importance of working with organizations like the Open Crypto Audit Project and the Open Technology Fund to support the development and security of technologies that promote trust and security throughout the Internet.

iSEC hopes both the TrueCrypt project and the larger Open Crypto Audit Project continue their work. The security community will benefit from continued review, new versions, and reproducible builds of the software in the future.

iSEC is grateful and honored to have been a part of the TrueCrypt security audit and feels that the analysis was both productive and important. iSEC’s full report is now available to the public. It is unchanged save two items: correcting a few late-stage misspellings and redaction of the consultants’ phone numbers. It is available at https://opencryptoaudit.org/reports.

Heartbleed (CVE-2014-0160) Advisory

Thu, 10 Apr 2014 11:00:00 +0000

News of a major widespread vulnerability discovered by Neel Mehta came out Monday, April 7 2014. This vulnerability allows a network attacker to read memory from programs that use certain versions of the OpenSSL library, e.g. web servers, VPN clients and servers, or mail transfer agents. Vulnerable data could include:

Certificate private keys and session keys
Any credentials (such as username and password) sent to the endpoint. Session cookies and similar bearer tokens are also affected.
The actual data that was intended to be protected (such as financial data or account numbers).
Other potentially sensitive data in memory (such as memory addresses and their contents) that could allow an attacker to more easily exploit other vulnerabilities.

What is vulnerable?

This vulnerability has been in source code since December 2011 and in production OpenSSL versions since March 2012:

OpenSSL 1.0.1 through 1.0.1f (inclusive) are vulnerable
OpenSSL 1.0.1g is NOT vulnerable
OpenSSL 1.0.0 branch is NOT vulnerable
OpenSSL 0.9.8 branch is NOT vulnerable

Even if you are not directly using OpenSSL, a large number of software packages incorporate OpenSSL and are vulnerable.

Who is vulnerable?

Anyone who has run any product using OpenSSL versions 1.0.1 through 1.0.1f even if you are currently patched is vulnerable. Even if your organization does not run OpenSSL directly, it is a part of many other software packages. Additionally, appliances such as SSL/TLS terminators, mail servers, instant messaging servers, and VPN concentrators could be running OpenSSL internally. This is not limited to servers either. Any client software that uses a vulnerable version of OpenSSL can be attacked. Our investigations into the exploitability of client software are ongoing.

What action should be taken on the server side?

iSEC recommends performing the following discovery and remediation steps:

Discovery: determine if you are running a vulnerable version of OpenSSL

Fix the base issue going forward:

Update to OpenSSL 1.0.1g or newer, or recompile the current version in use with heartbeats disabled via the –DOPENSSL_NO_HEARTBEATS option.
Restart all processes that load the OpenSSL library

Mitigate potential damage:

Generate and deploy a new public and private key pair.
Revoke old, assumed-compromised private key. Check with the issuing Certificate Authority (CA) for details on how to revoke a compromised private key. You may wish to request a new certificate even before your production systems are fully patched so that it has a chance to age before deployment to minimize problems for clients with incorrect clocks.
Invalidate all active sessions
Encourage users to change passwords
Elevate fraud detection procedures
Notify vendors of any vulnerable commercial software or appliances.

Due to the severity of the impacts of an exploit, if a service cannot be upgraded or recompiled, consider removing the service from the internet until fixes can be applied.

What action should be taken with client software?

Currently the most active threat is to servers, however a network attacker could use this bug to attack clients as well. Depending on the functionality and use of your product, client-side attacks could steal sensitive session data, user credentials, and private keys for client certificates.

Discovery: determine if clients/products are using a vulnerable version of OpenSSL.

Fix the base issue going forward:

Update to OpenSSL 1.0.1g or newer, or recompile with heartbeats disabled
Release update/patch

Mitigate potential damage:

Notify customers
Invalidate sessions
Encourage users to change passwords
Encourage users to generate new public and private key pair for client-side certificates
Revoke old, assumed-compromised private key of client-side certificates
Elevate fraud detection procedures

What action should be taken by users/consumers?

Almost every person uses some service or software that is vulnerable to Heartbleed. Although much of the burden resides on software vendors to provide prompt patches, there are a few things you can do to minimize your personal risk:

Log out of services
Determine if services are currently vulnerable by looking for an advisory or checking one of the available lists, such as Mashable’s list
Avoid using vulnerable services and notify them that they are vulnerable
After services are no longer vulnerable, change passwords

More information

CVE-2014-0160
http://heartbleed.com/
https://www.openssl.org/news/secadv_20140407.txt
https://www.nccgroup.com/en/blog/2014/04/heartbleed-openssl-vulnerability/
http://security.stackexchange.com/a/55250 - Details on client-side attacks

Introducing iSEC's Smart Password Evaluation Service

Tue, 01 Apr 2014 06:00:00 +0000

Note: This post was written as an April Fool’s Day joke; we will (fortunately) not be offering this service. We hope you enjoyed this bit of humor about the current challenges in the security industry.

The Trouble with Password Strength Meters

One of the main downfalls of using passwords as an authentication mechanism is that it’s extremely difficult to convince users to select strong passwords. In the past few years, several web applications have begun to use “password strength meters” which show the user how resistant their chosen password is to brute force attempts.

A recent paper by Carnavalet and Mannan showed that, while these meters are somewhat effective at increasing the strength of passwords, they are easily fooled. Many meters rate passwords like “password$1” as strong despite the fact that modern attack tools could easily crack such a password.

iSEC’s Service

What’s the problem here? Is your attacker a little JavaScript snippet with a pretty colored bar? No! Your attacker is a constantly evolving and adaptable human adversary. What’s the only way to defeat a human? With a human!

With this in mind, iSEC is proud to announce iSEC Smart Password Evaluation Service, the first and only password evaluator that uses live humans to judge the strength of passwords.

How it Works

Let’s say you register a new account with XYZ Bank. They’re an iSEC customer who wisely uses our Smart Password Evaluation Service. When you enter your desired password into the XYZ Bank application, their web server makes a backend request to our service. This request includes all of your registration information and your attempted password in plaintext. (Note that this backend request takes place over leased lines. This escapes the dangers of crossing Internet infrastructure and allows us to maintain the fastest service possible by securely omitting encryption.)

iSEC’s trained specialists then evaluate the password and determine whether it meets the length and complexity requirements of XYZ Bank. We also use our human intelligence to look for weaknesses that a computer could never determine, such as:

Is your password derived from your personal information?
Is your password some obfuscated form of the word “password” that a computer cannot detect (e.g. “p4ssW0rd”)
Does your password contain the letter “z”? (All passwords should contain one or more “z” because it’s always the last character that hackers attempt in brute force attacks.)

Examples

Let’s take a look at some real life examples, taken from customers in our pilot program.

Financial Services Application

Our first example comes to us from one of our financial services customers. Accounts on this site control millions of dollars worth of assets, so the security of these accounts is paramount. No one other than the end user should ever have access to the user’s personal details, especially not their password, so it’s critical that we evaluate the password thoroughly.

The user’s password here demonstrates a very common password weakness: it is largely based on the customer’s personal information. If the attacker compromised the full user database (which is quite common in large data breaches), they could combine dictionary words with the user’s personal information to discover the password.

In this case, the user’s password is simply the word “Go” followed by their favorite sports team and year of birth. iSEC’s analyst therefore rejected this password as weak and the user was required to select a new, stronger password.

Message Board Application

We want to protect all the Internet’s users, not just those of large financial services clients. There are many smaller sites in our pilot program as well. Our next example comes to us from a customer who runs a free message board where users can discuss young adult fiction:

This site collects fewer personal details during registration so our analysts have less to work with. What we can see is that the English word “Team” appears in the password, which is bad. However, the remainder of the password are 12 random, nonsense characters that no attacker could guess, so we mark the password as very strong.

Scaling

We expect that very soon, every major web site on the Internet will use iSEC Smart Password Evaluation Service to solve their password woes. How do we scale our solution to address millions of requests per second? After all, each request requires manual interaction from a trained specialist.

Well, like most difficult problems in security, the answer is: the cloud.

Specifically Amazon’s Mechanical Turk service. For those not familiar, Amazon’s Mechanical Turk allows companies to hire temporary workers for “micro-tasks”: short jobs that can be completed within a few minutes.

Of course, evaluating passwords is very sensitive, skilled work so we can’t allow any anonymous user on the Internet to do it. Before any Mechanical Turk worker can begin evaluating passwords, they must complete a rigorous examination that challenges their security acumen as well as their personal integrity.

We’re only a few months into our pilot program, but we have already found thousands of Mechanical Turk workers who are extremely enthusiastic about their work. Every day they tell us, “Please send us more passwords!” At first we worried that our workers would shy away from the responsibility of evaluating passwords for high value accounts such as banks or stock exchanges, but those types of accounts are proving to be our most popular. Some of our workers have even offered to pay us for the opportunity to protect these accounts! Talk about passionate employees!

Conclusion

After software developers and security professionals have spent decades of struggling to get password authentication right, iSEC is very proud to have solved passwords once and for all.

We will be expanding our Smart Password Evaluation Service pilot program very soon. If you run a web site and are interested in joining the next wave of our pilot program, stay tuned to this blog over the next few weeks for instructions on how to start using our service on your site.

Cryptopocalypse Reference Paper

Thu, 20 Mar 2014 04:35:05 +0000

Alex Stamos, Tom Ritter and Javed Samuel presented “Preparing for the Cryptopocalypse” at Black Hat 2013, looking into the latest breakthroughs in the academic cryptography community. The original presentation can be downloaded here.

Today we’re releasing a full whitepaper that provides additional detail and extensive references which will explain the latest breakthroughs in the academic cryptography community and look ahead at what practical issues could arise for popular cryptosystems. Specifically, it focuses on the recent major developments in discrete mathematics and their potential ability to undermine our trust in the most basic asymmetric primitives, including RSA.

It explain the basic theories behind RSA and the state-of-the-art in large numbering factoring, and how several recent papers may point the way to massive improvements in this area. It also describes some of the mathematics of Elliptic Curve Cryptography (ECC).

The paper then switches to the practical aspects of the doomsday scenario, and will answer the question “What happens the day after RSA is broken?” It will point out the many obvious and hidden uses of RSA and related algorithms and outline how software engineers and security teams can operate in a post-RSA world. We will also discuss the results of our survey of popular products and software, and point out the ways in which individuals can prepare for the “zombie cryptopocalypse”.

The paper provides a detailed list of references to the latest academic papers related to asymmetric cryptography. In addition, references that discuss the current level of ECC support in various popular products and software are included.

The paper can be downloaded here.

AWS environment security assessment with Scout2

Wed, 19 Feb 2014 07:51:00 +0000

Security engineers at iSEC Partners are regularly involved in projects that require assessing the security of an Amazon Web Services (AWS) environment. Thoroughly reviewing AWS configuration requires poring through dozens to hundreds of pages in the AWS console, depending on the environment’s size. In 2012, iSEC Partners released AWS Scout to help AWS administrators assess their environment’s security posture. Unfortunately, APIs have changed since then, and the tool wasn’t written in a particularly maintainable fashion.

AWS Scout2

iSEC Partners developed a new, more comprehensive, version of AWS Scout in order to address its need for an AWS configuration review tool. AWS Scout2 is an open-source application written in Python that connects to the AWS API and downloads configuration data for the following AWS services:

Identity and Access Management (IAM)
Elastic Compute Cloud (EC2)
Simple Storage Service (S3)

The information gathered is then rendered in an offline HTML report. In addition to AWS configuration, this HTML report displays a number of security risks.

Project page

iSEC Partners is pleased to release AWS Scout2 to the security community. See the Github repository page for full details on how to download and use the tool:

https://github.com/iSECPartners/Scout2

iOS certificate pinning code updated for iOS 7

Sat, 01 Feb 2014 07:51:00 +0000

We’ve updated the iOS certificate pinning code which is part of iSEC’s SSL Conservatory project on Github. This new version brings the following changes:

The Xcode project was re-created as a static library (instead of an iOS App) to facilitate integration. Sample code demonstrating how to use the library has been moved the project’s unit tests.
A new convenience delegate class for NSURLSession, the HTTP connection framework introduced in iOS 7, was added to the project. Similarly to the existing convenience class for NSURLConnection this class makes it easy to add certificate pinning to connections relying on NSURLSession.

Project page

Code and instructions are available on the project’s Github page.

Announcing the Release of RtspFuzzer

Tue, 07 Jan 2014 12:13:00 +0000

iSEC Partners is pleased to announce the release of RtspFuzzer, an open-source fuzzer for the real-time streaming protocol (RTSP). RTSP is a text-based protocol that facilitates media streaming. We have been developing this fuzzer over the past several months as we fuzz different media players. Though this protocol doesn’t receive much attention, most popular media players implement it and these implementations have previously been a source of critical security vulnerabilities (including QuickTime and Windows Media Player).

Using RtspFuzzer, we uncovered a new, critical vulnerability in the Live555 library, an open-source implementation of the RTSP protocol that several media players and servers use, including VLC. The vulnerability allowed an attacker to gain remote code execution on a victim’s system if they could induce a VLC user to visit a malicious web page or open a malicious playlist file.

Using RtspFuzzer

See the Github repository page to download the tool and for quick start instructions:

https://github.com/iSECPartners/RtspFuzzer

We created the fuzzer using the Peach fuzzing framework. RtspFuzzer has built-in configurations for Windows binaries of QuickTime, VLC, and openRTSP, but users can easily adjust the configuration and use this fuzzer to test any RTSP client on any Peach-compatible platform.

Advice for developing fuzzers with Peach

Creating RtspFuzzer was a great way to learn to use Peach. Peach is a very powerful framework for fuzzing, but many people shy away from it and instead create one-off fuzzers because they perceive Peach’s learning curve as too steep. Peach does indeed take some time to learn, but it does also save you from rolling your own implementation of a lot of things that Peach does for you, such as integrating with debuggers, mutating your data to match common attack patterns, or logging results in an organized way.

I would like to see Peach succeed because, despite its current problems, Peach makes it easy to write fuzzers that others can reuse and adapt. As more people use Peach, more information about its use will be available and this will reduce the learning curve. The Peach development team is very responsive, and as the user base increases, more people will be able to report bugs and feature suggestions. If you’re thinking of writing a fuzzer with Peach, keep the following tips in mind:

Treat your Peach pit like a regular program. Keep it under source control and use bug tracking to maintain a list of issues in your fuzzer. Debugging your fuzzer will be a lot easier if you can revert to a known good state.
Expect bugs in Peach. While Peach has existed since 2004, the latest 3.x version is a complete rewrite of the product in .NET and was first released in May, 2013. Peach works well for the most part, but there are definitely some rough edges, especially as your pits get more complex. You need to account for this in planning if you’re building your fuzzer on a schedule. I recommend building Peach from source so that if you suspect you’ve run into a bug in the framework itself, you can debug it more easily.
Fuzz early and fuzz often. When I started working on the RTSP fuzzer, my first task was to define the RTSP protocol as precisely as I could in Peach. What I wish I had done first was build a mostly dumb fuzzer that spoke just enough RTSP to do basic fuzzing of a test application such as VLC, then build up from there. Seeing how Peach works and how it interprets the data in pit files is immensely helpful in designing your fuzzer. Look at the kind of data that Peach generates and see if anything is causing iterations to run slowly or to stop.

iOS 7 tool updates

Thu, 02 Jan 2014 13:44:00 +0000

With the availability of the evasi0n7 jailbreak and the subsequent release two days ago of Cydia Substrate with support for iOS 7 and ARM64, a full-blown iOS 7 penetration testing environment can now be setup. To this extent, we’ve updated our publicly available iOS tools for blackbox testing in order to add support for iOS 7 and ARM64. We just released the two following updates:

iOS SSL Kill Switch v0.5, our tool to disable SSL certificate verification/pinning.
Introspy-iOS v0.4, our iOS Apps security profiler.

The pre-compiled packages for these tools now contain both an armv7 and an arm64 slice, which means that they will work on 64 bits iOS Apps for devices with an A7 chip (such as the iPhone 5s and the iPad Air).

Both tools were successfully tested on an iPhone 5s running iOS 7.0.4:

![screenshot](/images/introspy-ios7.png)

Sandbox changes in iOS 7

While testing Introspy-iOS on iOS 7, I ran into issues with the sandboxd daemon denying write access to specific files the tool was trying to create. Interestingly enough, it seems like the Seatbelt profiles deployed on iOS 7 have been updated, compared to iOS 6. Specifically:

AppStore Apps can no longer write to the root folder of their container directory, for example /var/mobile/Applications/3152B928-D771-424C-AE39-F79EC4A79EC5/
System Apps can no longer write to /var/mobile/

Because of these changes, I had to modify the locations where Introspy-iOS stores its files, to the following paths:

[App Container]/Library/ for AppStore Apps.
/var/mobile/Library/Preferences/ for System Apps.

It is unclear why the Seatbelt profiles were changed, although the ability to write to these locations was not actually needed by Apps. More information regarding the Seatbelt profiles used for various iOS Apps is available on the iphonedev wiki.

iSEC Research Labs

Introducing opinel: Scout2's favorite tool

opinel

Support for Python 2.7 and 3.x

Modification of the MFA workflow

Support to use assumed-role credentials

Conclusion

IAM user management strategy (part 2)

Categorize your IAM users

Example of category groups

Create your default groups with aws_iam_create_default_groups.py

(Automatically) sort IAM users with aws_iam_sort_users.py.

Additional advantages of configuration files

Conclusion

iSEC audit of MediaWiki

Work daily with enforced MFA-protected API access

AWS Security Token Service

Challenges with MFA-protected API access

aws_recipes_configure_iam.py

aws_recipes_init_sts_session.py

Conclusion

Use and enforce Multi-Factor Authentication

What is Multi-Factor Authentication?

Why should one use and enforce MFA?

How can one enforce MFA?

Use AWS Scout2 to detect users without MFA

How can one use MFA with command line tools?

Conclusion

iSEC reviews SecureDrop

Recognizing and Preventing TOCTOU Whitepaper

IAM user management strategy

Use IAM groups

Create a common IAM group to apply generic policies

Authorize IAM users to manage their credentials

Use AWS Scout2 to detect user policies

Check that all IAM users belong to the common group

Do not use your AWS root account

What is the AWS root account?

Risks of using the AWS root account

AWS Identity and Access Management (IAM)

Important security consideration about the root account

Announcing the AWS blog post series

CA Alternative Whitepapers

Calculating SQL Permissions

Vulnerability Overview: Ghost (CVE-2015-0235)

Executive Summary

What is vulnerable?

Who is vulnerable?

Ubuntu

Debian

Red Hat Enterprise

Mint

Gentoo

Arch

Fedora

Mandriva Linux

openSUSE

Slackware

Knoppix

Slax

CentOS

Jailbreak, updated and open-sourced

A Simple DLL Injection Utility

Shellshock Advisory

Executive Summary

Impact & Determining Exposure

Patching

An Imperfect Fix

In the Wild Attacks

IDS Signatures and Detection

Technical Details of the Flaw

References

Perfect Forward Security Whitepaper

Tor Browser Research Report Released

ZigTools: An Open Source 802.15.4 Framework

Benefits

Tool Release: You'll Never (Ever) Take Me Alive!

DIBF Tool Suite

SSLyze v 0.9 released - Heartbleed edition

Heartbleed Testing