The Log4Shell Vulnerability

CyberSense is a monthly bulletin by CSA that spotlights salient cybersecurity topics, trends and technologies, based on curated articles and commentaries. CSA provides periodic updates to these bulletins when there are new developments.

OVERVIEW

In early December, a vulnerability in Apache Log4j – an open-source Java package use to support activity-logging in many popular Java applications was unveiled. While not all software written in Java are vulnerable, the affected package is believed to be widely used by developers, and there are literally hundreds of thousands – if not millions – of applications and services that use the Log4j library. Products from big tech firms such as Amazon, Microsoft, VMWare, Cisco and IBM were also affected. This edition of CyberSense takes a closer look at the Log4j vulnerability (aka Log4Shell) and why it has been considered by many to be one of the most serious cybersecurity issues in years. 

WHAT IS LOG4J, LOG4SHELL, AND WHY IS THIS VULNERABILITY SUCH A CONCERN?

On 9 December 2021, a vulnerability (aka Log4Shell) impacting multiple versions of the Apache Log4j library (Log4j 2) was publicly disclosed. Log4j is an open-source Java package or library (a piece of reusable programming module) that is widely used by developers to log activities and events within their applications/services or products. As most applications incorporate logging function to track activities and audit purposes, logging libraries such as Log4j have enormous reach and implications. The vulnerability affects many Java applications and services that use the open-source Apache Log4j 2 library, including enterprise IT and security solutions such as Apple iCloud, VMWare Horizon, Palo Alto Panorama and IBM QRadar.

Within hours of public disclosure, there have been reports of increased in mass scanning activities on the Internet for vulnerable servers and proof of concept (POC) codes were released by researchers. Based on malicious activities observed, researchers have noticed cybercriminals incorporating the Log4Shell exploit into their operations. Numerous crypto-miners, botnets, and malwares, as well as ransomware such as Khonsari, TellYouThePass and Conti have been found taking advantage of the vulnerability to target vulnerable servers.

The Log4Shell vulnerability was assigned to maximum severity rating of 10 (the highest) on the Common Vulnerability Scoring System (CVSS). This suggests that the impact of successful exploitation of the vulnerability is very serious, given the availability of POC exploit codes, ease of exploitation and the extent which attackers are able to seize full control of targeted systems through remote code execution (RCE) just by sending a simple malicious string code to the targeted machine. It affects multiple releases of the version 2 of the library (v2.0 to v2.14.1). The vulnerability lies in a feature that allows lookup of variables via naming and directory services such as Lightweight Directory Application Protocol (LDAP) and Domain Name System (DNS). Consequently, threat actors can redirect the look up to load malicious Java codes from their servers.

IT systems are not the only ones vulnerable to Log4Shell. OT (Operational Technology) systems such as SCADA (Supervisory Control and Data Acquisition) systems and IoT (Internet-of-Things) devices are also at risk, with products from Philips, Schneider Electric, Siemens and MobileIron already known to be affected. Since the disclosure of Log4Shell, the list of affected products and services has been growing, and with Log4j being used in a wide range of applications and services, the impact is expected to be massive and far-reaching.

UBIQUITY OF THIRD-PARTY LIBRARIES AND MANAGING THE RISKS 

The ubiquitous nature of the Log4j library is what makes the potential impact caused by the log4Shell vulnerability so serious. The Log4j library has been compared to a type of screw that is widely-used in semi-finished products and finished goods – such as engines, chairs, tables or even automobiles – any vulnerability in such a foundation piece of the software supply chain could have far-reaching consequences. Much like how most consumers have no idea of the full list of components make up their devices, many organisations might not be aware of what different pieces of third-party libraries are used in the products and services they have, making management of the vulnerabilities associated with them a challenge.

Managing the risk of vulnerability in third-party libraries that are used in products and services (developed in-house or provided by vendors) would be highly dependent on IT asset visibility as well as the availability of fixes. Based on these two factors, organisations can frame their understanding and devise relevant approach to the situation according to the following FOUR broad scenarios (derived using the Knowns and Unknowns Framework):

      a. “Known-Known” [Organisation Aware - Fix Available]. Organisations have visibility of their vulnerable IT assets and patches are available. Organisations should proceed to apply the relevant patches to secure their systems.

      b. “Known-Unknown” [Organisation Aware - Fix Not Available]. The organisation is aware of the list of affected assets, but patches are not readily available. Risks should manage by implementing intermediate mitigation measures to protect critical systems and detect any abnormal activities, while working with vendors on patches/replacement for their systems.

      c. “Unknown-Known” [Organisation Not Aware – Fix Available]. There could be instances where organisations have not patched or remediated affected software or devices, even though patches are available. This could be due to lack of visibility of affected assets, unable to afford systems downtime or being unaware of/ underestimating the seriousness of the issue. Organisations will need to expand their IT assets visibility to better assess the potential impact of a cyber-attack on business reputation and operations and consider the remediations or trade-offs. 

      d. “Unknown-Unknown” [Organisation Not Aware – Fix Not Available]. A scenario that encapsulates the vulnerabilities and exploits that have yet to emerge, and patches not yet developed for (i.e., Zero-day attacks). Organisations need to stay up to date on new developments, maintain a robust cybersecurity posture, and continuously monitor their networks and systems for anomalies.

CONCLUSION

The Log4Shell is one of the most critical vulnerabilities in recent years and unfortunately the risk from log4j vulnerability is likely to persist for years, as there will be residual services or systems that remained unpatched. The Log4j issue highlights the importance for organisations to review their application portfolios and maintain accurate software bill of materials, so that affected products or services can be swiftly identified and fixed.

For further details and mitigation measures, please refer to SingCERT’s advisory on actions to protect against exploitation of Log4j vulnerability.

SOURCES INCLUDES:

360Factors, Apache Software Foundation, Beeping Computer, The Record, Threatpost, Wired, ZDNet