Cloudknocking

Our Modernizing Security: AWS series has discussed a number of ways to improve security posture in an AWS environment. Building off some of these concepts, this article takes the perspective of an attacker and demonstrates one method of establishing a foothold in an account.

While impractical in a well instrumented environment, without proper monitoring and IAM segmentation this may well go undiagnosed for long enough to cause more than a headache. To be clear, this is not a vulnerability, per se, in the underlying technology but more so an abuse of existing functionality. Securing access keys and tokens is of the utmost importance and would mitigate this method from the outset. To start, we discuss the attack surface then the background and motivation for this method. A barebones demonstration is made using Terraform and we close with notes on key indicators and strategies for mitigation.

A Cornucopia of Shell

Assuming you have disabled user access to the console, one could still gain remote access to a server or resource through:

• SSH/RDP via unsecured/unmonitored network ingress.
• Remote execution via Simple Systems Manager.
• Server side code exploitation and privilege escalation to abuse loosely implemented machine roles.
• Direct API calls or CLI invocation.

These options all assume some direct or persistent pathway through the perimeter that could raise alarms in an environment with common rudimentary monitoring. Host based logging and agents could catch server exploits and basic Cloudtrail aggregation would at least make note of rogue API calls. What If there was a path to trigger arbitrary execution, a Lambda function or SSM automation for instance, that didn’t traverse the network perimeter and could otherwise be overlooked as normal intra-environmental machine-to-machine traffic? Well, we will get to that in a minute. First, a quick history lesson.

The Old Way

Before the likes of SDN and WAF, when SSH was a luxury, one was lucky if they had a basic firewall running and configured on each server.

Back when servers were more pets than cattle and firewalls were little smarter than electrified fences, admins went to great lengths to obfuscate and protect their remote access to individual servers. An obfuscation technique, port knocking, was developed earlier in this century that allowed a remote admin to authenticate themselves using a combination of specially crafted packets sent to a daemon that would “unlock” the server by adjusting firewall rules or starting a remote shell service.

The New Way

Could cloud native services be used to replicate the type of obfuscated authentication achieved with legacy port knocking? More critically, could a nefarious actor use such a pattern to conceal their command-and-control signals? Yes! First, we need a way to receive an arbitrary outside signal. Route53 provides a “highly available and scalable cloud Domain Name System DNS web service”, it should work just fine. Then that signal will need to be captured and routed into the environment. Route53 public record queries can be monitored through CloudWatch Logs and linked to an alarm with a metric filter. Action can be taken directly on this alarm through an SQS topic but the relatively new EventBridge service provides even greater configurability through more target options and robust event pattern matching. From here, the sky, or more specifically the credential, is the limit.

• Activate a lambda function
• Fire off an SSM Automation
• CloudFormation template update.
• Launch an EC2 or ECS task
• Trigger a CodePipeline, Step Function or Batch Job

As a simple demonstration, I’ve written some basic Terraform to wire everything together. For proof of concept, simply provide an existing Route53 hosted zone ID and valid number for SMS notification delivery. This code is provided without warranty or guarantee and is for demonstration purposes only.

Defending from the Threat Within

A good defensive posture always starts with an inventory of services in use or that you intend to use. If a service is not expected to be used in a particular account or organizational unit, use Service Control Policies to disable it completely. For services that cannot be disabled, anomaly detection through GuardDuty may be useful but regular audit of environments is a must. This should include right-sizing of IAM roles and review of deprecated or abandoned resources for potential inclusion in organization level deny lists.

Reactive control can only scale so far and at some point a proactive approach must be implemented. Consider creating a unified deployment pipeline for your wider environment including automated checks for unapproved services and overly permissive IAM role. It is much easier to lock down and monitor a cluster of integration/deployment servers that you trust to deploy a limited scope of hardened resources than it is to harden a wider set of bespoke infrastructure hand crafted by multiple teams with different end goals. Think of it as a “single path of permit” rather than a “single point of failure”. Infrastructure as code is your friend!