Cloud Security Migration

Utilizing CloudHealth Secure State to Safeguard Against the Log4shell Vulnerability

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:

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-AWSManagedRulesKnownBadInputsRuleSet to 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.1 to 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.