Log4Shell Vulnerability: Everything you need to know

By now the whole world knows about the critical “Log4Shell” vulnerability that has been detected in the log4j java library last week and is also known as CVE-2021-44228. Over the weekend spotit, as a NOC and SOC partner for many customers throughout Europe and the world, has been working with IT teams around the clock to mitigate potential impact from this vulnerability. We’re here to share a few takeaways from these hours in the trenches.

Java is still an ubiquitous programming language. While other languages have gained ground on Java over the past 10 years (Python, Golang, Haskell, C#, …) it is still used everywhere. Knowing where you are running it and what its dependencies are is crucial to estimating your attack surface.

Many products that are crucial to your business depend on third party libraries and open source code while you have no useful means to manage their security configuration and become dependent on vendor updates if a vulnerability like this lands. Having the ability to reach out and work with those vendors directly or through a trusted partner allows you to manage your attack surface.

Estimating your attack surface is not an easy feat. The log4j jar file being present on a system isn’t sufficient. You also have to use the specific functionality in your code. Finding those references in your code can be quite cumbersome if your development pipeline isn’t well structured.

Security programs nowadays rely on a lot of products to measure attack surface and determine priorities. Unfortunately many of these products are reactive more than they are proactive. Considerable time passed between the vulnerability being disclosed and tools having useful detections for it (from intrusion detection/prevention products, over vulnerability scanning products, to third party risk management platforms). In our observation, once again, the reaction time was largely dependent on the people involved in the response process.

At spotit we believe in a collaborative relationship with our NOC and SOC clients. Keeping the feedback loops short and going the extra mile for our clients is inherently part of our service-focused DNA. Working with customers that share our vision and focus on information security is truly a privilege.

Below we copy the advisory bulletin we sent to our customers after we learned of the vulnerability. Don’t hesitate to get in touch with us if you believe we can help you with managing your exposure and attack surface through our Managed SOC service.

Apache Log2j Vulnerability – CVE-2021-44228 – Log4Shell (CVSS 3.1: 10.0)

Summary

Apache Log4j versions prior to 2.15.0-rc2 have a Critical vulnerability that allows for remote code execution loaded from LDAP, RMI, and DNS servers. Log4j is a Java-based logging tool used in web applications, games, network infrastructure, cloud development, and many other generic solutions. This vulnerability is being exploited right now and is affecting services including Steam, Minecraft, iCloud, and Twitter.

Proof of concept code is available publicly.

Mitigation

Spotit recommends that its customer’s internal IT teams, software developers, and software development partners, audit all Java applications for existence of Log4j.

Log4j should be updated to 2.15.0-rc2 (minimum) where this behaviour is disabled by default.

Products from the vendor list below should be updated per the guidance.

Affected Products

Apache Log4j 2.15.0-rc1 and lower.

The vulnerability has been discovered in hundreds of products from many vendors. A curated lists of affected products is available at https://gist.github.com/SwitHak/b66db3a06c2955a9cb71a8718970c592

At this time there are 178 vendors on the list. This may increase as the week progresses. The list includes advisories from Cisco, VMware, F5, Debian, Apache, F-Secure, GitHub, Palo Alto and many more.

SOC customers please note we are on alert for any incidents occurring from this.

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H – 10.0 (Critical)