The Log4shell (log4j) vulnerability (CVE-2021-44228) emphasized more than ever the importance of setting network controls & policies not only on inbound traffic but also on outbound traffic.
In this blog we will go through:
The vulnerability in the popular log4j library is a critical remote code execution described in a simple and understandable way in the Swiss Government Emergency and Response site. The main takeaway here is that for an application to be exploitable it has to answer 3 requirements: Java application with the vulnerable log4j version (Any version of log4j between versions 2.0 and 2.14.1 are affected). Application is logging user controllable strings. This one is really hard to detect or to know what loglines are or are not controllable by a user, So better to assume it is always user controllable. The application running the vulnerable version has unrestricted outbound access (internet) to download the malicious payload from the attacker server or exfiltrate data.
The third point is a “critical” requirement, as without it your application cannot/less likely to be exploited. This is not to say you shouldn’t patch all of your vulnerable java applications ASAP.
There are numerous ways to allow/disallow outbound access from an EC2. Following is a diagram:
The most important and usually the most commonly used is a security group. Security groups act as a virtual firewall and are attached directly to an instance (EC2 network interface).
Following is a query to identify all security groups with unrestricted outbound access.
You can also run the query straight from the policy pack located on our GitHub
Depending on the size/number of accounts this is probably going to return a bunch of results. A good best practice (though it will be a project) would be to go through each one of the returned results and understand if this unrestricted outbound access is needed or can we tighten it up? If this is needed the best way to address it is to create the following tags, for example: “egress: true”, “egress-reason: this is our A microservice which needs to access A,B,Z….”
Even though your security groups should have least privilege network access configured, having unrestricted access to a security group doesn’t necessarily mean it really has outbound access to the internet. This means we can filter further to help find and prioritize resources that not only have wide open security groups but really have outbound internet access.
We won’t talk about NACLs here as they are less widely used and usually you need to configure the tightest security groups in any case.
The second requirement for outbound access is an internet gateway. Here is a query that checks if an instance with an unrestricted outbound access security group resides in a VPC with an internet gateway.
This doesn’t cover all the methods but does cover pretty much the most popular connectivity structure. For example, there are ways to peer VPCs which enables VPCs to share an Internet Gateway, this will require different queries. If we missed some other connectivity scenarios please open an issue in our GitHub
EC2 instances are just one type of compute resource that can run a vulnerable application. Applications can also be run on other services including ECS, Lambda, AppRunner, Lightsail, and more.