George Floyd: Anonymous Hackers Reemerge Amid US Unrest

An anonymous reader quotes a report from the BBC: As the United States deals with widespread civil unrest across dozens of cities, “hacktivist” group Anonymous has returned from the shadows. The hacker collective was once a regular fixture in the news, targeting those it accused of injustice with cyber-attacks. After years of relative quiet, it appears to have re-emerged in the wake of violent protests in Minneapolis over the death of George Floyd, promising to expose the “many crimes” of the city’s police to the world. However, it’s not easy to pin down what, if anything, is genuinely the mysterious group’s work.

Various forms of cyber-attack are being attributed to Anonymous in relation to the George Floyd protests. First, the Minneapolis police department website was temporarily taken offline over the weekend in a suspected Distributed Denial of Service (DDoS) attack. This is an unsophisticated but effective form of cyber-attack that floods a server with data until it can’t keep up and stops working — in the same way that shopping websites can go offline when too many people flood it to snap up high-demand products. A database of email addresses and passwords claiming to be hacked from the police department’s system is also in circulation, and being linked to Anonymous. However, there is no evidence that the police servers have been hacked and one researcher, Troy Hunt, says the credentials are likely to have been compiled from older data breaches.

How to Protest Without Sacrificing Your Digital Privacy

Thousands of protesters are filling the streets of American cities to protest the police killing of George Floyd, an unarmed black man, and police brutality writ large. Police officers have shown they’re more than willing to escalate violence with pepper spray, tear gas, rubber bullets, vehicles, and other dangerous crowd suppression measures. In addition, law enforcement are likely heavily surveilling protests with all sorts of tech and spying gear. Already, we’ve seen a Customs and Border patrol drone flying over Minneapolis protests.

How to perform automated incident response in a multi-account environment

How quickly you respond to security incidents is key to minimizing their impacts. Automating incident response helps you scale your capabilities, rapidly reduce the scope of compromised resources, and reduce repetitive work by security teams. But when you use automation, you also must manage exceptions to standard response procedures.

In this post, I provide a pattern and ready-made templates for a scalable multi-account setup of an automated incident response process with minimal code base, using native AWS tools. I also explain how to set up exception handling for approved deviations based on resource tags.

Because security response is a broad topic, I provide an overview of some alternative approaches to consider. Incident response is one part of an overarching governance, risk, and compliance (GRC) program that every organization should implement. For more information, see Scaling a governance, risk, and compliance program for the cloud.

Important: Use caution when introducing automation. Carefully test each of the automated responses in a non-production environment, as you should not use untested automated incident response for business-critical applications.

Solution benefits and deliverables

In the solution described below, you use AWS Systems Manager automation to execute most of the incident response steps. In general, you can either write your own or use pre-written runbooks. AWS maintains ready-made operational runbooks (automation documents) so you don’t need to maintain your own code base for them. The AWS runbooks cover many predefined use cases, such as enabling Amazon Simple Storage Service (S3) bucket encryption, opening a Jira ticket, or terminating an Amazon Elastic Compute Cloud (EC2) instance. Every execution for these is well documented and repeatable in AWS Systems Manager. For a few cases where there are no ready-made automation documents, I provide three additional AWS Lambda functions with the required response actions in the templates. The Lambda functions require minimal code, with no external dependencies outside AWS native tools.

You use a central security account to execute the incident response actions in the automation runbooks. You don’t need to do anything in the service accounts where you monitor and respond to incidents. In this post, you learn about and receive patterns for:

  • Responding to an incident based on Amazon GuardDuty alerts or AWS Config findings.
  • Deploying templates for a multi-account setup with a central security account and multiple service accounts. All account resources must be in the same AWS Region and part of the same AWS organization.
  • AWS Systems Manager automation to execute many existing AWS managed automation runbooks (you need access to the AWS Management Console to see all documents at this link). Systems Manager automation is available in these AWS Regions.
  • Prewritten Lambda functions to:
    • Confine permissive (open) security groups to a more-constrained CIDR (classless interdomain routing), such as the VPC (virtual private cloud) range for that security group. This prevents knowable network configuration errors, such as too-open security groups.
    • Isolate a potentially compromised EC2 instance by attaching it to a single, empty security group and removing its existing security groups.
    • Block an AWS Identity and Access Management (IAM) principal (an IAM user or role) by attaching a deny all policy to that principal.
    • Send notifications to the Amazon Simple Notification Service (Amazon SNS) for alerting in addition to (and in concert with) automated response actions.
    Exception handling when actions should not be executed. I suggest decentralized exception handling based on AWS resource tags. Integrating AWS Security Hub with custom actions for GuardDuty findings. This can be used for manual triggering of remediations that should not receive an automatic response. Custom AWS Config rule for detecting permissive (open) security groups on any port. Mapping the security finding to the response action defined in the CloudWatch Events rule pattern is extendable. I provide an example of how to extend to new findings and responses.

    Out-of-scope for this solution

    This post only shows you how to get started with security response automation for accounts that are part of the same AWS organization and Region. For more information on developing a comprehensive program for incident response, see How to prepare for & respond to security incidents in your AWS environment.

    Understanding the difference between this solution and AWS Config remediation

    The AWS Config remediation feature provides remediation of non-compliant resources using AWS Systems Manager within a single AWS account. The solution you learn in this post includes both GuardDuty alerts and AWS Config, a multi-account approach managed from a central security account, rules exception handling based on resource tags, and additional response actions using AWS Lambda functions.

    Choosing the right approach for incident response

    There are many technical patterns and solutions for responding to security incidents. When considering the right one for your organization, you must consider how much flexibility for response actions you need, what resources are in scope, and the skill level of your security engineers. Also consider dependencies on external code and applications, software licensing costs, and your organization’s experience level with AWS.

    If you want the maximum flexibility and extensibility beyond AWS Systems Manager used in this post, I recommend AWS Step Functions as described in the session How to prepare for & respond to security incidents in your AWS environment and in DIY guide to runbooks, incident reports, and incident response. You can create workflows for your runbooks and have full control of all possible actions.

    Architecture

     

    Figure 1: Architecture diagram

    The architecture works as follows:

    In the service account (the environment for which we want to monitor and respond to incidents):

    1. GuardDuty findings are forwarded to CloudWatch Events.
    2. Changes in the AWS Config compliance status are forwarded to CloudWatch Events.
    3. CloudWatch Events for GuardDuty and AWS Config are forwarded to the central security account, via a CloudWatch Events bus.

    In the central security account:

    1. Each event from the service account is mapped to one or more response actions using CloudWatch Events rules. Every rule is an incident response action that is executed on one or more security findings, as defined in the event pattern. If there is an exception rule, the response actions are not executed.

      The list of possible actions that could be taken include:

      1. Trigger a Systems Manager automation document, invoked by the Lambda function StratSsmAutomation within the security account.
      2. Isolate an EC2 instance by attaching an empty security group to it and removing any prior security groups, invoked by the Lambda function IsolateEc2. This assumes the incident response role in the target service account.
      3. Block the IAM principal by attaching a deny all policy, invoked by the Lambda function BlockPrincipal, by assuming the incident response role in the target service account.
      4. Confine security group to safe CIDR, invoked by the Lambda function ConfineSecurityGroup, by assuming the incident response role in the target service account.
      5. Send the finding to an SNS topic for processing outside this solution; for example, by manual evaluation or simply for information.
      Invoke AWS Systems Manager within the security account, with a target of the service account and the same AWS Region. The Systems Manager automation document is executed from the security account against the resources in the service account; for example, EC2, S3, or IAM resources. The response actions are executed directly from the security account to the service account. This is done by assuming an IAM role, for example, to isolate a potentially compromised EC2 instance. Manually trigger security responses using Security Hub custom actions. This can be suitable for manual handling of complex findings that need investigation before action.

      Response actions decision

      Your organization wants to articulate information security policy decisions and then create a list of corresponding automated security responses. Factors to consider include the classification of the resources and the technical complexity of the automation required. Start with common, less complex cases to get immediate gains, and increase complexity as you gain experience. Many stakeholders in your organization, such as business, IT operations, information security, and risk and compliance, should be involved in deciding which incident response actions should be automated. You need executive support for the political will to execute policies.

      Creating exceptions to automated responses

      There may be cases in which it’s unwise to take an automated response. For example, you might not want an automated response to incidents involving a core production database server that is critical to business operations. Instead, you’d want to use human judgment calls before responding. Or perhaps you know there are alarms that you don’t need for certain resources, like alerting for an open security group when you intentionally use it as a public web server. To address these exceptions, there is a carve-out. If the AWS resource has a tag with the name SecurityException, a response action isn’t executed. The tag name is defined during installation.

      Table 1 provides an example of the responses implemented in this solution template. You might decide on different actions and different priorities for your organization. A current list of GuardDuty findings can be found at Active Finding Types and for AWS Config at AWS Config Managed Rules.

      N Source Finding Description Response
      1 GuardDuty Backdoor:EC2/Spambot
      Backdoor:EC2/C&CActivity.B!DNS,
      Backdoor:EC2/DenialOfService.Tcp,
      Backdoor:EC2/DenialOfService.Udp,
      Backdoor:EC2/DenialOfService.Dns,
      Backdoor:EC2/DenialOfService.UdpOnTcpPorts,
      Backdoor:EC2/DenialOfService.UnusualProtocol,
      Trojan:EC2/BlackholeTraffic,
      Trojan:EC2/DropPoint,
      Trojan:EC2/BlackholeTraffic!DNS,
      Trojan:EC2/DriveBySourceTraffic!DNS,
      Trojan:EC2/DropPoint!DNS,
      Trojan:EC2/DGADomainRequest.B,
      Trojan:EC2/DGADomainRequest.C!DNS,
      Trojan:EC2/DNSDataExfiltration,
      Trojan:EC2/PhishingDomainRequest!DNS
      See Backdoor Finding Types and
       
      Trojan Finding Types
      Isolate EC2 with empty security group.
       
      Archive the GuardDuty finding.
       
      Send SNS notification.
      2 GuardDuty UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration,
      UnauthorizedAccess:IAMUser/TorIPCaller,
      UnauthorizedAccess:IAMUser/MaliciousIPCaller.Custom,
      UnauthorizedAccess:IAMUser/ConsoleLoginSuccess.B,
      UnauthorizedAccess:IAMUser/MaliciousIPCaller
      See Unauthorized Finding Types Block IAM principal by attaching deny all policy.
       
      Archive the GuardDuty finding.
       
      Send SNS notification.
      3 AWS Config S3_BUCKET_SERVER_SIDE_ENCRYPTION_ENABLED See the documentation for s3-bucket-server-side-encryption-enabled Enable server-side encryption with Amazon S3-Managed keys (SSE-S3) with SSM document (AWS-EnableS3BucketEncryption).
       
      Send SNS notification.
      4 AWS Config S3_BUCKET_PUBLIC_READ_PROHIBITED See the documentation for s3-bucket-public-read-prohibited Disable S3 PublicRead and PublicWrite with SSM document (AWS-DisableS3BucketPublicReadWrite).
       
      Send SNS notification.
      5 AWS Config S3_BUCKET_PUBLIC_WRITE_PROHIBITED See the documentation for s3-bucket-public-write-prohibited Disable S3 PublicRead and PublicWrite with SSM document (AWS-DisableS3BucketPublicReadWrite).
       
      Send SNS notification.
      6 AWS Config SECURITY_GROUP_OPEN_PROHIBITED See template, custom configuration. Confine security group to safe CIDR 172.31. 0.0/16
       
      Send SNS notification.
      7 AWS Config ENCRYPTED_VOLUMES See the documentation for encrypted-volumes Send SNS notification.
      8 AWS Config RDS_STORAGE_ENCRYPTED See the documentation for rds-storage-encrypted Send SNS notification.

      Installation

      1. In the security account, launch the template by selecting Launch Stack.
         

        Additionally, you can find the latest code on GitHub, where you can also contribute to the sample code.
      2. Provide the following parameters for the security account (see Figure 2):
        • S3 bucket with sources: This bucket contains all sources, such as the Lambda function and templates. If you’re not customizing the sources, you can leave the default text.
        • Prefix for S3 bucket with sources: Prefix for all objects. If you’re not customizing the sources, you can leave the default.
        • Security IR-Role names: This is the role assumed for the response actions by the Lambda functions in the security account. The role is created by the stack launched in the service account.
        • Security exception tag: This defines the tag name for security exceptions. Resources marked with this tag are not automatically changed in response to a security finding. For example, you could add an exception tag for a valid open security group for a public website.
        • Organization ID: This is your AWS organization ID used to authorize forwarding of CloudWatch Events to the security account. Your accounts must be members of the same AWS organization.
        • Allowed network range IPv4: This CIDRv4 range is used to confine all open security groups that are not tagged for exception.
        • Allowed network range IPv6: This CIDRv6 range is used to confine all open security groups that are not tagged for exception.
        • Isolate EC2 findings: This is a list of all GuardDuty findings that should lead to an EC2 instance being isolated. Comma delimited.
        • Block principal finding: This is a list of all GuardDuty findings that should lead to blocking this role or user by attaching a deny all policy. Comma delimited.

        Figure 2: Stack launch in security account

      3. In each service account, launch the template by selecting Launch Stack.
         

        Additionally, you can find the latest code on GitHub, where you can also contribute to the sample code.

      4. Provide the following parameters for each service account:
        • S3 bucket with sources: This bucket contains all sources, such as Lambda functions and templates. If you’re not customizing the sources, you can leave the default text.
        • Prefix for S3 bucket with sources: Prefix for all objects. If you’re not customizing the sources, you can leave the default text.
        • IR-Security role: This is the role that is created and used by the security account to execute response actions.
        • Security account ID: The CloudWatch Events are forwarded to this central security account.
        • Enable AWS Config: Define whether you want this stack to enable AWS Config. If you have already enabled AWS Config, then leave this value false.
        • Create SNS topic: Provide the name of an SNS topic only if you enable AWS Config and want to stream the configuration change to SNS (optional). Otherwise, leave this field blank.
        • SNS topic name: This is the name of the SNS topic to be created only if enabling AWS Config. The default text is Config.
        • Create S3 bucket for AWS Config: If you enable AWS Config, the template creates an S3 bucket for AWS Config.
        • Bucket name for AWS Config: The name of the S3 bucket created for AWS Config. The default text is config-bucket-{AccountId}.
        • Enable GuardDuty: If you have not already enabled GuardDuty in the service account, then you can do it here.

      Testing

      After you have deployed both stacks, you can test your environment by following these example steps in one of your service accounts. Before you test, you can subscribe to the SNS topic with prefix Security_Alerts_[Your_Stack] to be notified of a security event.

      1. Create and open security group 0.0.0.0/0 without creating an exception tag. After several minutes, the security group will be confined to the safe CIDR that you defined in your stack.
      2. Create an S3 bucket without enabling encryption. After several minutes, the default encryption AES-256 will be set on the bucket.
      3. For GuardDuty blocking of IAM principal, you can define a list of malicious IPs under the Threat List in the GuardDuty panel. Create a test role or user. When you execute an API call from this IP with the created test role or user, a GuardDuty finding is generated that triggers blocking of the IAM role or user.
      4. You can deploy Amazon GuardDuty tester and generate findings such as Trojan:EC2/DNSDataExfiltration or CryptoCurrency:EC2/BitcoinTool.B!DN. The GuardDuty findings trigger isolation of an EC2 instance by removing all current security groups and attaching an empty one. This new empty group can then be configured for forensic access later.

      Exceptions for response actions

      If the resource has the tag name SecurityException, a response action is not executed. The tag name is a parameter of the CloudFormation stack in the security account and can be customized at installation. The value of the tag is not validated, but it is good practice for the value to refer to an approval document such as a Jira issue. In this way, you can build an auditing chain of the approval. For example:

      
      Tag name: SecurityException
      Tag value: Jira-1234
      

      Make sure that the security tag can only be set or modified by an appropriate role. You can do this in two ways. The first way is to attach a deny statement to all policies that do not have privileges to assign this tag. An example policy statement to deny setting, removing, and editing of this tag for IAM, EC2, and S3 services is shown below. This policy does not prohibit working with the resources, such as starting or stopping an EC2 instance with this tag. See Controlling access based on tag keys for more information.

      { { "Sid": "S3-Sec-Tag", "Effect": "Deny", "A ction": [ "s3:PutBucketTagging", "s3:PutObjectTagging" ], "Resource": "*", "Condition": { "ForAnyValue:StringLikeIfExists": { "aws:TagKeys": "TAG-NAME-SecurityException" } } }, { "Sid": "EC2-VPC-Sec-Tag", "Effect": "Deny", "Action": "*", "Resource": "*", "Condition": { "ForAnyValue:StringLikeIfExists": { "aws:TagKeys": "TAG-NAME-SecurityException" } } } ] }

Machine Learning Security Evasion Competition 2020 Invites Researchers to Defend and Attack

Machine learning (ML) is an increasingly valuable tool in cyber security as adversaries continually evolve their tactics and techniques to evade detection. As machine learning has advanced and sophisticated ML models have been developed to assist security professionals in protecting the cloud, adversaries have been busy developing malware designed to evade ML models.

Thousands of People Are Monitoring Police Scanners During the George Floyd Protests

The number of users of an app which lets people listen in to police radio broadcasts across the country is nearly doubling everyday during the protests, according to its developer. As of Monday morning, ‘5-0 Radio’ had skyrocketed above apps such as Facebook, Instagram, and TikTok to the most popular paid app, and the second most popular free app on the Apple App Store, according to Apple’s own rankings. Other similar apps have also jumped in popularity.

Finding Serious ‘Sign In with Apple’ Hole Earns Security Researcher a $100,000 Bug Bounty

An anonymous reader quotes Forbes: When Apple announced Sign in with Apple at the June 2019 worldwide developers conference, it called it a “more private way to simply and quickly sign into apps and websites.” The idea was, and still is, a good one: replace social logins that can be used to collect personal data with a secure authentication system backed by Apple’s promise not to profile users or their app activity… Unsurprisingly, it has been pushed as being a more privacy-oriented option than using your Facebook or Google account.

Fast forward to April 2020, and a security researcher from Delhi uncovered a critical Sign in with Apple vulnerability that could allow an attacker to potentially take over an account with just an email ID. A critical vulnerability that was deemed important enough that Apple paid him $100,000 through its bug bounty program by way of a reward. With the vulnerability already now patched by Apple on the server-side, Bhavuk Jain published his disclosure of the security shocker on May 30.

How to Create a Culture of Kick-Ass DevSecOps Engineers

Much like technology itself, the tools, techniques, and optimum processes for developing code evolve quickly. We humans have an insatiable need for more software, more features, more functionality… and we want it faster than ever before, more qualitative, and on top of that: Secure.

Expert Insight On Covid-19 Test & Trace SMS Phishing Attack

The NHS Test & Trace scheme is already being exploited by cybercriminals, with a new smishing (SMS-phishing) attack telling citizens that they have been in contact with someone who has COVID-19. An example of the text message is below. These kinds of fake text messages typically include a link to a malicious site, or will ask the receiver to share personal information that could then be used to commit identity fraud.