Using zero trust to secure the AWS metadata service
Connecting state and local government leaders
Implementing zero trust through microsegmentation would prevent any unauthorized request from accessing the AWS metadata and user data.
This year, CIOs got a stark reminder of the importance of securing their cloud applications and instances. In the Capital One breach, a former Amazon Web Services employee exploited a misconfigured firewall to launch a server-side request forgery attack, ultimately exposing more than 100 million consumer credit applications.
The AWS metadata service played a key role in this attack. As long as AWS believes the customer is on an EC2 instance, any HTTP request to the metadata service (e.g., 169.254.169.254 port 80) returns a URL structure of all metadata about the instance, including sensitive information such as associated security groups, hostname, MAC address, IP address and even security tokens. It’s a useful service, but it’s also vulnerable to exploitation.
The question, of course, is how can agencies ensure metadata and user data is only accessed by approved services while malicious users are blocked from accessing the data for exploitation? But first, let’s talk about how a cybercriminal could gain access to the metadata service for a cloud instance.
This oversimplified example illustrates the basic strategy for the kind of server-side forgery that was perpetrated on Capital One: Let’s say an agency has a proxy function on its instance that aggregates data from specific URLs so it can display that data on a dashboard. If the proxy is misconfigured so that a user can ask it to visit any URL instead of specific addresses, then anyone can use the proxy to access the instance metadata, which might include critical items such as security tokens, with which cybercriminals can mount attacks with severe consequences.
Securing the AWS metadata service, however, isn’t a simple task. Users can’t simply block all access, because there are key services that depend on it, such as EC2 config and SSM agent. Perimeter protection cannot be relied on to stop unauthorized access. Eventually, something will break through or previously safe software will become compromised.
The best solution for securing the AWS metadata service is to implement zero trust through microsegmentation. In a zero-trust environment, all internal communications are treated as potentially hostile unless they are specifically authorized. It’s a powerful way to reduce the network attack surface and prevent lateral movement of threats from asset to asset.
Until recently, zero trust wasn’t feasible in cloud environments because the traditional microsegmentation methods that support it have been based on network addresses. Because IP addresses in the cloud are constantly changing, it has been very difficult to create policies based on them.
A new approach, however, can overcome this problem by creating policies based not on IP address, but rather on the unique, immutable identities of communicating software and devices. In this new approach, communication is allowed only after software identities have been verified. These identities are created from dozens of attributes, including the SHA-256 hash of binaries, the universally unique identifier (UUID) of the system’s BIOS and the serial numbers of the CPUs.
In this approach, IT must first inventory all software, services and devices on the instance and map the communications pathways between them. This process can be automated using machine learning or artificial intelligence. Once the inventory is complete, all unused or unnecessary communications pathways can be eliminated to reduce the attack surface. Typically, more than 90% of these pathways can be removed without affecting the production environment. Again, this is a task best left to automation.
To secure the AWS metadata service, IT can create a segment that allows only those software and services that need to access AWS metadata and blocks all unauthorized access. When automated, it takes just seconds to complete. Because zero trust policies are based on software identity, even when the software is altered, it won’t pass the test and communications will be blocked.
So, in the case of the proxy example above, zero trust would prevent it -- and any other unauthorized request -- from accessing the AWS metadata and user data. And thanks to identity-based microsegmentation, government IT organizations can now extend zero trust to their cloud environments, which will not only protect them against the AWS metadata vulnerability, but against threat to their cloud workloads.
NEXT STORY: CX starts with culture, not technology