Log4J Vulnerability / ED 22-02 Update

The cloud.gov team has continued working on the Log4j vulnerability, also known as Log4Shell (CVE-2021-44228), since our last news update posted on December 14th, 2021.  This post summarizes customer responsibilities, steps we have taken to protect our customers, and the status of the platform with respect to log4j.

Update 2021-12-27: In compliance with directives from the FedRAMP JAB, cloud.gov has completed our ED-22-01 response per the CISA-provided template. The report is available to our authorized customers on the FedRAMP Secure Repository in Max.gov, or by request to support@cloud.gov. cloud.gov Customer Responsibilities

• Customers are responsible for ensuring that their Java applications are fully patched or otherwise have this vulnerability mitigated. For guidance, refer to CISA’s Log4J guidance.
• If you have reporting requirements, e.g. ED 22-02, regarding cloud.gov components that you leverage:
  • cloud.gov brokered AWS Elasticsearch components were patched at the latest by Dec 21, 2021.
  • All other cloud.gov brokered components, AWS RDS, AWS S3, AWS Elasticache Redis, External Domains, Service Accounts and Identity Provider, were patched by Dec 13, 2021.

cloud.gov has taken the following steps to provide default protection to our customers:

• We deployed Web Application Firewall rules starting on Dec 10, 2021, to block known patterns attempting log4j attacks. Please do not rely on these to protect your applications as they are not a full mitigation strategy. The rules block naive attacks and reduce overall noise. They may impact your ability to run queries for, say, ${jndi in our logsearch platform.
• Since Dec 13, 2021, web applications on the platform are running with the environment variable, LOG4J_FORMAT_MSG_NO_LOOKUPS=true. This should provide log4j versions from 2.10.0 to 2.14.0 a mitigation for CVE-2021-44228, but not for CVE-2021-45046 or other attacks.

cloud.gov Platform and Infrastructure updates:

• Pages (formerly Federalist), a cloud.gov service, does not use Log4j, and was not directly exposed.
• cloud.gov, has components that use Log4j:
• • We applied mitigations and patches as they became available, starting on Friday, December 10th, 2021, and have continued applying patches as they have become available from the upstream component maintainers.
  • We have no evidence that any of our cloud.gov-managed components executed externally-supplied code. We have evaluated vulnerability disclosure program reports, egress from potentially-vulnerable platform components (note that we cannot and did not evaluate user egress), and web application logs, and so far have seen no evidence of exploitation.
  • We are providing detailed updates to the FedRAMP JAB, as required by our P-ATO authorization.
• AWS GovCloud is the IaaS hosting service for most of cloud.gov, and AWS has components that use Log4j. Their response to this vulnerability is detailed in their security bulletin, but with respect to cloud.gov infrastructure:
• • AWS patched/updated all the components that cloud.gov leverages by Sunday, December 12th, 2021.
  • We have verified reports that external researchers could make “jndi:ldap” requests to cloud.gov hosted web applications and get a response back from AWS internal components until Dec 12, 2021.
  • We have an open support request with AWS to determine if such attacks could have impacted the integrity of hosted content.

If you received a report that your cloud.gov or Federalist site was subject to the Log4j attack, please contact cloud-gov-compliance@gsa.gov.

We are continuing to track the Log4j vulnerability and its related follow-ups very closely and will post more updates and details to the cloud.gov StatusPage Log4j incident as we continue to deploy patches and take steps to address this vulnerability.

Any questions should be directed to support@cloud.gov. Concerns regarding vulnerability details or evidence of compromise should be directed to cloud-gov-compliance@gsa.gov

NB: An earlier verion of the post labeled the directive type incorrectly. CISA has issed an ED (Emergency Directive), not a BOD.