(last updated 1/11/2022)
Issue
On 12/9/2021, a critical vulnerability was reported in a widely used Java software called Log4j. Log4j is not an application itself, but a software component commonly used by many commercial, open-source, and UCI-developed applications. The following morning an alert with recommendations was sent to IT Leadership and Unit Information Security Leads across campus.
Impact
Any system using vulnerable versions of Log4j can be remotely exploited by an attacker without requiring a login. The exploit can result in the entire system being taken over and controlled by the attacker, data copied and/or deleted, ransomware installed, other accounts compromised, backdoors installed, and used to pivot to additional systems on the network.
Action Required
Product owners and IT staff on campus should identify and patch software within their units that are vulnerable to this Log4j exploit as soon as possible. This may involve reaching out to your commercial software suppliers, open-source software projects, and/or UCI software developers to check for applications using a vulnerable Log4j component and update them appropriately. More technical details in the FAQ section below.
Please contact your Unit Information Security Lead or security@uci.edu if you have any questions.
FAQ
Which versions of Log4j are vulnerable?
- Log4j 2.0-beta9 through 2.12.1 and 2.13.0 through 2.15.0 (CVE-2021-44228, CVE-2021-45046)
- Log4j 2.0-alpha1 through 2.16.0 (CVE-2021-45105)
- Log4j 2.0-beta7 through 2.17.0 (CVE-2021-44832)
Which version of Log4j do I need to update to?
- Currently Log4j 2.17.1 is the most secure version to use. However, keep checking this page regularly as reviews of the software continue and new issues may be discovered requiring another upgrade.
Is Log4j 1.x also vulnerable?
- CVE-2021-4104 involves an untrusted deserialization flaw affecting Log4j version 1.2. This issue only affects Log4j 1.2 when specifically configured to use JMSAppender, which is not the default. Apache Log4j 1.2 reached end of life in August 2015. Users should upgrade to Log4j 2.x as it addresses numerous other issues from the previous versions. The impact to confidentiality, integrity and availability is high, but the attack complexity is much higher for a successful exploitation as it requires a non-default configuration.
How do I know if my system is affected?
- Contact your supplier for purchased software or check project websites for open-source software.
- CISA also maintains a page cataloging previously reported software and status: https://github.com/cisagov/log4j-affected-db
- There are also some tools you can use to scan system drives for the existence of vulnerable files
What is OIT doing to help?
- Scanning the network with multiple tools to identify vulnerable systems and notify owners. Note: we cannot rely solely on the results of these automated scans to act upon due to the wide array of software on our network and unique scenarios each can be exploited by this vulnerability.
- Blocking known bad IP addresses from the Internet who are attempting this exploit on other systems. Note: we cannot rely solely on these lists as bad actors keep changing.
- Monitoring network activity using signatures to detect and block exploit attempts from the Internet. Note: we cannot rely solely on this protection as much of this activity is encrypted using HTTPS and invisible to our monitoring tools.
- Updating all OIT services that are using vulnerable Log4j components.
- Reporting the existence of vulnerable Log4j files on systems of managed clients. Note: existence of these files alone may not lead directly to an exploit, however they can be a clue to where they are used in a vulnerable application and good practice to cleanup anyway.
- Collaborating with other UC locations, sharing information, and checking for malicious activity reported by other institutions.
What if OIT determines my system is exploitable before I can fix it?
- OIT Security will do its best to contact the owner of the system as a warning, however due to the urgency of the risk to campus and the long holiday break, a system that is at risk of exploit will be blocked from the network until it can be fixed.