1. We don’t use Java 2. The instances in the email are not in our accounts
We later received another email providing some vague reasons for this…
On a Friday evening I was not very happy spending time trying to hunt down the invalid instances
Earlier today, we provided you a notification with a list of instances that may still be running a version of log4j that has a known security vulnerability and needs to be patched. We want to provide you additional details about that email.
The list of instances was obtained by monitoring for specific DNS queries which are typically used when targeting the log4j vulnerability. These DNS lookups can indicate that someone is attempting to exploit the log4j vulnerability on your instance. Each of the instances provided has made a DNS lookup to one of the suspect domains between 12:00 AM and 11:59 PM PST on December 16th 2021. While we are not able to tell whether the instance was compromised, we strongly recommend that you take action to update log4j across all of your Java environments, whether they are publicly accessible or not.
In some cases, the list of instances included instance IDs that may not currently be present within your EC2 environment. This happened for a number of reasons:
1. EC2 instances may have been terminated since the scan was completed at 11:59 AM PST on December 16th 2021;
2. EC2 instances that have been stopped and restarted may appear with the incorrect instance ID;
3. ECS, EKS, and Fargate containers have been included with the underlying instance ID instead of the container ID;
4. EC2 instances used by underlying network services were erroneously included in the list of instances. These services are not themselves running unpatched log4j, but can be indicative of these DNS queries coming from within your VPC.
While it is not always possible for us to pinpoint the exact instances making these DNS queries, it is critically important that you patch all Java environments for the log4j issue, whether they are publicly accessible or not. To help you, we are also providing a 15-day free trial to Amazon Inspector which can assist you in finding vulnerable resources by scanning your Amazon Elastic Compute Cloud (EC2) instances and container images for the log4j vulnerability.
Please take the steps explained in this security blog post [1] to protect your resources. You also can find more information about log4j in our security bulletin [2].
If you have any questions or concerns, please reach out to AWS Support [3].
[1] https://aws.amazon.com/blogs/security/using-aws-security-ser... [2] https://aws.amazon.com/security/security-bulletins/AWS-2021-... [3] https://console.aws.amazon.com/support
There's no JVM (or log4j) in our environment, but we received this notification listing 6 instance IDs as having done DNS lookups to suspect domains.
No trace of those instance IDs in our account over the past few weeks, and after following up with a ticket we were told they're actually the instance IDs that sit underneath some fargate tasks (no info on what tasks or ECS service of course, because that would be sensible).
We've rechecked the bits of our stack that run on Fargate and confirmed there's definitely no JVM, so we figure it must be a false positive. Maybe DNS lookups to customer controlled hostnames (which we support as part of a feature, and sandbox carefully).