Technology and Security

Month: December 2021

log4j vulnerabilities in spring boot

Spring Boot Updates for Log4J Vulnerabilities

Hackers continue to scan and exploit systems containing Log4J vulnerabilities at an unprecedented rate. On 10 December, the Spring Blog published detailed instructions for remediating Spring Boot applications using Maven or Gradle build scripts; Where this solution pattern is still accurate, the documented version is now out-of-date. Remember that even though the library may not be explicitly imported, it still might be present as a transitive dependency.

Latest Release for Log4J Vulnerabilities

The most secure version of Log4J is now version 2.17.1 (documented in our previous article). To force Spring Boot to import the most recent release of Log4J, include the following in your build scripts:

Maven

<properties>
    <log4j2.version>2.17.1</log4j2.version>
</properties>

Gradle

ext['log4j2.version'] = '2.17.1'

Log4J Vulnerability Update (2.17.1)

Several weeks out from the initial zero-day event, the IT world continues to work through the remediation and blowback from the Apache Log4J vulnerability. First published as CVE-2021-44228 (Log4Shell) on 9 December 2021, subsequent CVEs continue to be issued as quick turnaround patches fail to completely resolve the problem. The most recent version is now 2.17.1 (released 28 December) which repairs a newly discovered remote code execution (RCE) vulnerability in 2.17.0, tracked as CVE-2021-44832.

This family of vulnerabilities affects millions of computers, clouds, networks, and IoT devices ranging from the size of postage stamps to automobile chargers. It derives from the use of a ubiquitous piece of software, Log4J, which is mostly unknown to those outside of the IT industry. This open source code is used to generate files containing records of events that occur in software written in (or somehow leveraging) the Java programming language.

Hackers, in the form of independents or state actors, continue to scan the internet for vulnerabilities as IT teams race to resolve the problem. Once a vulnerable device is found, bad actors attempt to trigger a log message that includes a malicious payload which Log4J will process as a valid instruction. These exploits can open a reverse shell which allows the hacker to remotely control the targeted device.

As concerning as the exploit is itself, even more concerning is the pervasive use of Log4J leading this vulnerability to be described by the U.S. Cybersecurity & Infrastructure Security Agency (CISA) Director as one of the most serious she has seen in her career.

As of today, the remediation path involves upgrading impacted software to use the latest Log4J release, version 2.17.1 (note that versions of Log4J 1.x remain unaffected). The 2.17.1 release is available on the Apache site and has not yet migrated into the central repositories such as Maven Central.

CISA has published a response page which lists the history as well as recommended remediation paths for this exploit. Large vendors continue to release updates, including Amazon, IBM, and Google, but a significant concern also remains with smaller IT shops that do not have the workforce to quickly identify and push out updates.

If you have not already remediated systems that you are responsible for, it is long overdue that you do…

Powered by WordPress & Theme by Anders Norén