Systemic Vulnerabilities in Information Technology—Log4Shell

Systemic Vulnerabilities in Information Technology—Log4Shell

INSIGHTi
Systemic Vulnerabilities in Information
Technology—Log4Shell
Updated February 7, 2022
There is critical vulnerability in software used by mil ions of internet servers. Since its discovery both
criminals and nation-state actors have reportedly exploited it. It is uncertain how many entities are
vulnerable, but it is presumed there are many. This CRS Insight describes the vulnerability and federal
government response considerations.
Log4Shell
Log4j is an open-source tool the Apache Foundation makes available for logging web server activity. To
work, Log4J has to access many network services (e.g., network maps and directories). Malicious actors
discovered a way to use the Log4j tool to send commands that give them control of the servers. The
cybersecurity community named this vulnerability Log4Shel .
Log4Shel exploits have been observed to mine cryptocurrencies and expand botnets.
Apache Foundation software is very useful and freely available, so it is widely deployed. Hundreds of
software projects maintained by the foundation rely on volunteer developers and are supported by
donations and sponsorships.
Responses
The Apache Foundation updated Log4j to remediate the vulnerability. However, deploying this solution is
not as straightforward as with other vulnerabilities (i.e., applying the patch).
1. Deploying the solution is logistical y complex, as Log4j is not part of a single software
platform. Instead it is a part of many different web services. Users wil have to identify
al instances of its use and in some cases recompile software using the patched version.
2. Vulnerable versions of the software go back a decade, and some instances may be used in
software that is no longer maintained.
Congressional Research Service
https://crsreports.congress.gov
IN11824
CRS INSIGHT
Prepared for Members and
Committees of Congress

Congressional Research Service
2
3. Users may not know they are vulnerable because they are unaware that the web services
they rely on use this tool. Some may have difficulty enumerating which servers and
applications are vulnerable.
The private sector has taken several steps to minimize the exploitation of Log4Shel . Companies have
produced security alerts and updated their anti-malware programs. Others have deployed rules to detect
the types of queries that would compromise servers. Some have published mitigation guidance.
The federal government has also moved to mitigate this vulnerability. The Cybersecurity and
Infrastructure Security Agency (CISA) created a new website with guidance on the vulnerability. CISA is
using the Joint Cyber Defense Collaborative (JCDC) to manage the incident. The creation of the JCDC
executes a recommendation from the Cyberspace Solarium Commission. In addition to the private sector,
CISA is leveraging the Federal Bureau of Investigation and the National Security Agency in this response.
Per Emergency Directive 22-02, agencies have to remediate the vulnerability in their internet-connected
systems. For federal agencies, CISA added Log4Shel to its Known Exploited Vulnerabilities Catalog,
which requires agency action regardless of whether an agency system is operated by the agency or a third-
party (e.g., a cloud service provider). December 23, 2021, was the deadline for action.
CISA chartered the Cyber Safety Review Board (CSRB), pursuant to Executive Order 14028 (EO). The
CSRB announced that its first investigation wil be on the Log4j vulnerability.
The White House has not disclosed whether it has activated a Cyber Unified Coordination Group (Cyber
UCG) or is using the National Cyber Incident Response Plan in this response, as it did during the
SolarWinds response. However, per the EO, the CSRB is supposed to convene following incidents where
a Cyber UCG was established.
Options for Congress
This is not the first time the cybersecurity community has had to address this type of systemic
vulnerability in information and communications technology. In 2014, government and private sector
entities coordinated to resolve the Heartbleed bug. In that case too, the critical vulnerability existed in
widely used open-source software. Lessons from that response are being applied to Log4Shel ’s response,
but also highlight opportunities for policy changes.
Policymakers may choose to explore the creation of a specific capability to address systemic
vulnerabilities in the future. The JCDC can support public and private sector actions to address
Log4Shel . But the involvement of the JCDC does not activate new authorities, and remediation wil rely
on entities using their existing authorities and capabilities. Congress may choose to direct a federal
agency to build a capability to assist the open source community in identifying and remediating
vulnerabilities. Dedicated resources may help to al eviate some chal enges that open-source projects face,
such as volunteer developers not being able to resources for identifying and resolving security issues in
the same way that corporate and proprietary software developers can. Once such capability may be to
authorize an agency to proactively scan the internet to discover potential y vulnerable servers and notify
their owners. CISA has a technical capability to do this, but their authority requires entities to request
scanning. But, some may view this type of activity as unwanted, and it may trigger incident response
teams at unaware organizations—procedures on capability use and limitations wil need to be developed.
Additional y, policymakers may explore opportunities to strengthen public-private partnerships to address
malicious actors exploiting vulnerabilities. The federal government and private companies have
coordinated their actions to disrupt botnet operations in the past. However, the authority to do so is ad-hoc
and entities frequently rely on court orders to empower them to move against malicious infrastructure.
Some in Congress have proposed empowering agencies to take additional actions against malicious

Congressional Research Service
3
infrastructure. Policymakers may choose to examine what additional authorities may be granted to federal
agencies seeking to identify the infrastructure malicious actors use, conditions under which agencies may
take action against that infrastructure, what options agencies may pursue (e.g., confiscating servers), and
what protections private entities may have for assisting and partnering with agencies.
Policymakers may seek to create greater transparency in the software supply chain. When users acquire
and deploy software, they may only be familiar with the end product and may be oblivious to the
underlying components used to build that product. Policymakers may choose to enact proposals on
software bil s of materials (SBOMs) which would require software developers to disclose which software
packages went into their final products. This transparency would speed up the discovery of potential y
vulnerable information technology (IT). The EO required SBOMs for federal IT.

Author Information

Chris Jaikaran

Analyst in Cybersecurity Policy

Disclaimer
This document was prepared by the Congressional Research Service (CRS). CRS serves as nonpartisan shared staff
to congressional committees and Members of Congress. It operates solely at the behest of and under the direction of
Congress. Information in a CRS Report should not be relied upon for purposes other than public understanding of
information that has been provided by CRS to Members of Congress in connection with CRS’s institutional role.
CRS Reports, as a work of the United States Government, are not subject to copyright protection in the United
States. Any CRS Report may be reproduced and distributed in its entirety without permission from CRS. However,
as a CRS Report may include copyrighted images or material from a third party, you may need to obtain the
permission of the copyright holder if you wish to copy or otherwise use copyrighted material.

IN11824 · VERSION 4 · UPDATED