by Drew Streib – Head of Architecture and Operations
[updated for CVE-2021-44832]
On Friday, December 10, 2021, due to CVE-2021-44228 the world became significantly more aware of Log4j, a prevalent Java logging library that was previously only in the vernacular of Java software developers. Because it is maintained by the Apache Foundation and used in a significant amount of software, Log4j vulnerabilities have wide reaching impact.
What is CVE-2021-44228?
Log4j is a logging library in wide use in Java applications, and receives messages from throughout an application intended to be logged for record keeping or for operational/debug purposes.
Some of these messages may include “user generated input”, where something that a user inputs into an application is contained within the log message itself. Any time you have user input (as in all web applications), there is an opportunity for exploit when a vulnerability is found.
CVE-2021-44228 (CVSS score 10.0, the highest possible severity) describes a vulnerability in which a formatted message triggers Log4j to perform an external retrieval of code from an input-generated URL, and Log4j then executes this code.
This makes the vulnerability of a “Remote Code Execution” (RCE) type, which is particularly heinous as it gives a foothold for an attacker on the machine running the software that calls Log4j (some backend server in most webapp cases).
Specifically, the vulnerability makes use of JNDI (Java Naming and Directory Interface), an API that provides naming and directory functionality to Java applications. Exploiting the attack involves triggering a fetch of code from an LDAP (Lightweight Directory Access Protocol) server that is controlled by the attacker.
You do not need to directly use Log4j in order to be vulnerable. Any piece of infrastructure software that you use that further processes input and makes use of Log4j makes you transitively vulnerable.
So, if your 100% non-vulnerable web application passes user input data to a backend service that makes use of a vulnerable 3rd party library, you could still indirectly introduce this attack-critical foothold into your environment.
If you found vulnerable Log4j in an environment, the recommended fix at the time (see below follow-up vulnerabilities) was to upgrade to Log4j 2.15, or mitigate with a configuration parameter disabling the external lookup capability.
Because of bullet 4 (above), IT and Operations departments around the world have been forced to do massive wholesale review of infrastructure and scramble to get responses from dependent vendors in order to get make sure that environments are clear of this CVE.
What are CVE-2021-45046, CVE-2021-45105, and CVE-2021-44832?
On Tuesday, Dec 14, another vulnerability designated CVE-2021-45046 (CVSS score 9.0) was announced which involved a slightly more complex attack of Log4j when it was used with non-default configuration. Since vulnerable configurations are in widespread use, the Log4j 2.15 upgrade was deemed an incomplete fix, and Log4j 2.16 was released, disabling the “JNDI” functionality at the root of the issue by default.
In short, there was still a Remote Code Execution (RCE) flaw in the “fixed” Log4j 2.15, and thus upgrades to Log4j 2.16 are recommended.
Likely due to suddenly increased scrutiny on Log4j, another vulnerability was found and announced as CVE-2021-45105 (CVSS score 7.5) on Saturday, Dec 18, affecting even the newly patched Log4j 2.16. This vulnerability is not an RCE, but a flaw in the same mechanism as the previous vulnerabilities allows for crafted inputs to cause a denial of service (DoS) against the service linking to Log4j.
This flaw is less severe than the RCEs of the first two, but still an easily exploitable way to DoS an application and thus still considered a high CVSS risk score.
A new update, Log4j 2.17, was released to address this vulnerability.
[UPDATE] On Dec 28, yet another followup vulnerability was announced as CVE-2021-44832. It has been updated again as of Jan 5 and continues to undergo NIST re-analysis due to its somewhat complex nature.
As of Jan 7, 2022, the CVE has been assigned a CVS score 6.6 (medium severity). It involves a more specific configuration and control of an already named LDAP server, making it far less accessible to a common attacker. A new update, Log4j 2.17.1 allows for some configuration specificity to limit this more narrow capability.
Are NTT Application Security (White Hat Security) products vulnerable?
NTTAS products are NOT vulnerable to any of the 4 recent Log4j CVEs.
How does Sentinel find Log4j vulnerabilities in customer sites?
NTTAS can test for Log4j vulnerabilities with both SAST and DAST methodologies:
Since the use of Log4j within an application stack can be widely varied and not always exploitable through a determinable series of inputs provided over the web application itself, the best way to correct these vulnerabilities is to locate and upgrade all Log4j libraries in use.
This is an ideal use case for Sentinel SAST and Vantage Inspect products. The software composition analysis in these tools look for the existence of the vulnerable library based on inclusion in the source or build process.
This recommendation to upgrade Log4j is a direct mirror of the NIST recommendation for all 4 CVEs:
Sentinel Dynamic (DAST) can serve as an augmentation to SAST by attempting to replicate vectors that an attacker would use to try to hack vulnerable sites. This method will show validated exploitable implementations, but is limited to the attack surface of directly accessible web inputs.
As of 9 am PST, Friday, December 17th, Sentinel Dynamic began scanning for Log4j CVE-2021-44228. All currently running and future scans test for actively exploitable Log4j vulnerabilities.
Why does the Sentinel Dynamic Log4j test require a connection to an external IP?
For CVE-2021-44228, there is an out of band (OOB) collection component, reaching out and performing external LDAP lookups that inform us that the Log4j vulnerability has been detected.
NTTAS is not recommending that you reduce or change your security posture to allow for external web connections from your application for the purposes of DAST test detection. It is probable that a restrictive outbound network policy helps mitigate an attack vector for these types of CVEs. But note that this does mean that DAST detection using these attack methodologies may fail due to the same controls that would thwart a hostile attacker.
The choice to whitelist a single IP for the purpose of this test is each customer’s to make, and should be taken with the above considerations in mind.
Sentinel Source and Vantage Inspect scanning do not have similar considerations and this is another reason why these remain the recommended primary mechanism of detection.
Will NTTAS be adding the new Log4j vulnerabilities, CVE-2021-45046, CVE-2021-45105, and CVE-2021-44832 into the Sentinel Dynamic scans?
The external attack methodology for CVE-2021-44228 and CVE-2021-45046 are similar, and Sentinel Dynamic scans attempt JNDI exploits that will be common (from a web attack surface perspective) across both vulnerabilities. They will be reported in Sentinel as “CVE-2021-44228” or “Log4j” per above but may represent either vulnerability.
The attack vector for CVE-2021-45105 is a denial of service (DOS) against the application, and the end result is the potential non-availability of the application under test. (We’d very likely crash or actively bring down the site under test for this vulnerability.) The appropriate search for CVE-2021-45105 is via the Sentinel Source or Vantage Inspect products, and we do not plan to test for this specific variant with Sentinel Dynamic.
[UPDATE] CVE-2021-44832 requires control of an LDAP server already named in a local configuration file and is thus not a target for Sentinel Dynamic scanning. (In a similar manner, it is a significantly more limited vector for an attacker.) The appropriate search for CVE-2021-44832 is also via the Sentinel Source or Vantage Inspect products, and we do not plan to test for this specific variant with Sentinel Dynamic.
The Log4j series of vulnerabilities is among the biggest worldwide security events in the past several years, and organizations have had to respond quickly and across a range of technology implementations. NTTAS offers multiple strategies to discover this vulnerability in use or as exploitable through web applications. If you have any questions regarding the use of NTTAS products in your environment, please contact your CSM or Support representative.
NTTAS will review customer-obtained results for Sentinel SAST, Vantage Inspect, and Sentinel Dynamic and continue to adapt detection and reporting of the Log4j series of vulnerabilities.
For additional information on Sentinel Source and SCA:
For additional information on Vantage Inspect:
As of 9 am PST, Friday December 17th, Sentinel Dynamic began scanning for log4j CVE-2021-44228. All currently running and future scans test for actively exploitable Log4Shell vulnerabilities.
Sentinel Source and SCA continues to be the most comprehensive method of finding vulnerable log4j versions within your application’s technology stack, augmented by Sentinel Dynamic for “in-the-wild” testing of demonstrably exploitable vectors.
For additional information on Sentinel Source and SCA:
For additional information on Vantage Inspect:
Due to the severe criticality and Internet-wide impact of Log4Shell, NTT Application Security is actively developing behavioral tests that will enable Sentinel Dynamic to detect Log4Shell.
This test will be available for user testing by Friday, December 17, 2021, and will roll-out to all Sentinel Dynamic clients by the following Friday, December 24th.
Once complete, this will enable clients to determine their exposure to this vulnerability in the assets scanned with Sentinel Dynamic. Because log4j is a back-end component, we strategically chose to develop behavioral testing over a fingerprinting approach, which we believe will provide the most accurate results.
Dec. 14 — The US Cybersecurity and Infrastructure Security Agency has ordered all civilian federal agencies to patch the Log4j vulnerability by December 24, 2021. CISA has published a landing page to provide additional information, technical resources and remediation guidance.
“This vulnerability is one of the most serious that I’ve seen in my entire career, if not the most serious.” — Jen Easterly, director of the US Cybersecurity and Infrastructure Security Agency
Late in the afternoon of December 10, 2021, evidence of a new zero-day vulnerability CVE-2021-44228—commonly known as Log4Shell—surfaced on Twitter and immediately sent shockwaves throughout the security industry.
Log4Shell is rated as a highly critical vulnerability due to how easy it can be exploited, as well the potential impact of its resulting ability for an attacker to perform Remote Code Execution. Commonly known as an Injection Vulnerability, an attacker only needs to insert a malicious payload into a log within an application using a vulnerable version of log4j to exploit the vulnerability, which could then give them access to the running environment and other attack vectors.
Zero-day vulnerabilities are not uncommon; however, Log4Shell’s status as one of the most widely used open-source software components that is used in thousands of enterprise web applications projects exponentially increases the potential impact of its exploitation in the wild. A recent analysis determined that Log4Shell was downloaded more than 28 million times from Maven Central, a repository for Java components, in just the past four months alone.
Security researchers have observed attackers making over a hundred attempts to exploit Log4Shell vulnerability every minute. Given the ubiquity of Java applications and the widespread use of log4j, enterprises using the vulnerable version in their applications must assume that they are currently at-risk of exploitation.
According to the Apache Software Foundation’s advisory, all Apache Log4j versions up to 2.14.1 are vulnerable (if message lookup substitution was enabled). Enterprises using the impacted version of Log4j should first focus their efforts on patching the vulnerability within all Internet-connected web applications.
Apache has released version 2.16.0 to address the flaw, which enterprises can now install from its download page.
It is important to note that the quickest and most effective way for clients to determine their exposure to Log4Shell is to use Sentinel SCA.
In response to the discovery of the vulnerability, NTT Application Security released an update on Monday, December 13, 2021, that enables Sentinel SCA to detect the affected versions of the log4j library.
There are two primary methodologies within Sentinel SCA to make this determination:
First, if Sentinel SCA identifies that a vulnerable version of log4j is currently in use, the tool will automatically surface a vulnerability finding of the class “Unpatched Library” that can be queried via the UI or API.
Sentinel SCA also provides an index of libraries currently in use, which can then be filtered for log4j to surface versions being utilized alongside associated CVEs. This method (step-by-step guide below) will provide the specific information needed to identify the vulnerability and begin remediation.
To see a list of applications scanned with Sentinel Source in which this vulnerability was detected:
The NTT Application Security team is actively working alongside experts in our network to identify the influence of CVE-2021-44228 within our environment. We have performed a thorough analysis of codebases, inventories of both development and production package deployments and have validated results with third-party systems security scanners.
As such, we are confident that no NTT Application Security production services or components are affected by Log4Shell. Additionally, the product appliances that are deployed within customer environments are not affected by the vulnerability.
NTT Application Security’s environment is also monitored by NTT Global Security Operations Center (GSOC) 24/7 to identify suspicious activity, provide ongoing health checks, threat detection and response capabilities. NTT Application Security uses next-generation Antivirus and End Point Detection and Response (AV/EDR), vulnerability management and network DNS security tools to protect our assets and perimeter.
NTT Application Security is closely monitoring the impact of the Log4Shell vulnerability and its impact on organizations’ web applications. This post will be updated as we learn more. Enterprise teams looking to speak with one of our application security experts for guidance on remediating the Log4Shell vulnerability are encouraged to contact us here.