Learn more about the critical vulnerability discovered in the Log4j2 Java package and recommendations from CloudHealth Secure State team on how to remediate or, if impossible, mitigate the issue.
Last week, a new critical vulnerability was discovered in the Log4j2 Java package and has been assigned the identifier CVE-2021-44228. The CloudHealth Secure State team has been monitoring the public cloud security landscape, as the vulnerable software component is used widely among cloud services.
The Log4j2 vulnerability is particularly impactful due to several reasons:
- The exploit for this vulnerability is particularly simple to execute
- It was discovered in the wild, i.e., attackers already have a head start
- The Log4j2 library is extremely popular and widely used, up to the point where many software vendors were not aware of this dependency
This has resulted in a wave of attacks by a variety of actors, and the expectation is that these attacks will only ramp up in the next few days as more and more malicious tools incorporate this exploit in their codebase. The mitigation and remediation process for this vulnerability is expected to be tedious and arduous due to the widespread adoption of Log4j2, need for a combination of updates, and temporary workarounds while waiting for upstream releases that incorporate the fix.
As part of this effort, cloud providers have released documentation on how to remediate or, if impossible, mitigate the issue:
- AWS – Apache Log4j2 Issue (CVE-2021-44228)
- Azure – Microsoft’s Response to CVE-2021-44228 Apache Log4j2
- GCP – Google Cloud recommendations for investigating and responding to the Apache “Log4j2” vulnerability (CVE-2021-44228)
One of the more direct and quick security measures you can take, albeit only a mitigation, is to add a WAF rule that filters exploit attempts for this vulnerability, as recommended in the documentation released by each cloud provider. You can validate whether you have employed the recommended WAF rules for each cloud provider using CloudHealth Secure State:
- AWS – Use
AWS.WAFv2.WebACL !-> AWS.WAFv2.Rule HAS Name = AWS-AWSManagedRulesKnownBadInputsRuleSetto find any Web ACLs that don’t have the “Known bad inputs” rule group added - Azure – Use
Azure.FrontDoor.FrontendEndpoint !-> Azure.WAF.FrontDoorWAFPolicy HAS RuleSetName = Microsoft_DefaultRuleSet_1.0 OR RuleSetName = Microsoft_DefaultRuleSet_1.1to find any FrontDoor Frontend Hosts that do not have any of the recommended Rule Sets for FrontDoor WAF Policies - GCP – Use
GCP.Compute.SecurityPolicy !-> GCP.Compute.SecurityPolicyRule HAS ExprExpression = "evaluatePreconfiguredExpr('cve-canary')" AND Action = "deny(403)"to find any Cloud Armor Policies without the Google-recommended built-in GCP rule
Another necessary activity will be the identification of vulnerable versions of Log4j across cloud-managed infrastructure. For example, in AWS you can use Systems Manager. To identify managed EC2 instances with Log4j installed you can use the following SSQL query: “AWS.SSM.Application HAS Name = log4j”.
Identifying Log4j installations over EC2 managed instances
We can also identify Serverless / FaaS resources that use the Java runtime for follow-up analysis:
- For AWS Lambda, use:
AWS.Lambda.Function HAS Runtime = java8 - For Azure WebApps, use:
Azure.AppService.WebApp HAS LinuxFxVersion = JAVAI8-jre8 - For Azure FunctionApps, use:
Azure.Functions.FunctionApp HAS JavaVersion = 1.8 - For GCP CloudFunctions, use:
GCP.CloudFunctions.Function HAS Runtime = java11
Learn more about misconfiguration and cloud security posture management and download our complete report, or feel free to reach out to an expert from VMware’s CloudHealth Secure State team for additional information.
