Visa Europe revealed important stats about the usage of Contactless Cards. Poland, Spain and the UK use this payment methd the most, with UK usage growing by 300% year over year.
Francesco Consiglio December 14, 2021
Following the discovery of the vulnerability CVE-2021-44228, known as “Log4Shell”, the Apache Foundation confirmed an additional flaw that affects the supposedly patched version of Log4J2 (2.15.0), resulting in a new officially documented vulnerability CVE 2021-45046 that reports the possibility of using malicious input data through JNDI Lookup patterns, resulting in a denial of service (DOS) attack. The promptly released version Log4j2 2.16.0 also fixes the latter!
Please note that the below article already suggested the installation of the latest version:
The world now faces a new critical zero-day exploit that operates on the most popular logging library of the Java ecosystem: Log4j2, the second version of the notorious Java library. As a consequence, Advantio’s own ZeroRisk Scoring Engine is now including a plugin capable of testing your public assets against this vulnerability.
In certain conditions, attackers can leverage vulnerabilities that allow remote execution of code without authentication mechanisms. Technically, the library can’t protect against attackers making use of remote LDAP and JNDI endpoints to execute malicious code remotely onto systems running Log4j2 when message lookup substitution is enabled.
The exploit has been officially documented as a CVE-2021-44228 with the maximum CVSS score of 10 which makes this exploit highly resonating in the industry. Also known by the code name of "Log4Shell", this exploit is also particularly concerning considering the wide adoption of the Log4j2 library in the programming ecosystem.
Java developers of the past two decades might remember the Log4j library before it officially became a project of the Apache Software Foundation and standard-de-facto for logging in a Java-based IDE. Its version 2 was released in 2014 and introduced a series of improvements, particularly in the field of Asynchronous Logging. Generally speaking, any developer with any Java experience is familiar with Log4j.
In practice, all versions of Log4j are affected including version 1 (which should be deprecated in favor of version 2 as it contains additional attack vectors and is officially EOL).
Version 2 (Log4j2) is affected up until version 2.15.0 which contains the corrected code. Apache also released version 2.16.0 in a stable branch and we suggest you upgrade immediately to this version (also available via maven repository.)
In theory, remediation should be seamless in most cases as it simply implies an upgrade that contains full backward compatibility. In other cases, the impact might be elevated as software needs to be adapted once the library is upgraded to a secure version.
Additionally, common Java development frameworks like Spring might contain ad-hoc guidance. Finally, for versions higher or equal to 2.10, the vulnerability can be mitigated without upgrading as per official guidance. For example, our ZeroRisk Scoring Engine is fully capable of identifying the Log4Shell vulnerability in your public assets so that remediation activities are facilitated.
You may be interested to know, security monitoring and active protection mechanisms such as Web Application Firewalls should play an equally important role to ensure systems are not targeted by malicious vectors. In this case, the attack vectors should be blocked with the definition of dedicated signatures.
We need to consider any system directly using Log4j2 (and even indirectly) could be affected, despite existing technical testing that may say otherwise. We also need to consider the chance that Log4j2 is also used as a core component for third-party libraries in an organization’s software. Thus, a thorough analysis of all software dependencies is mandatory to ensure a comprehensive resolution is applied. Java being a widely used technology for empowering software in all sectors, from fintech to safety-critical environments and medical devices, the vulnerability must be seriously and promptly addressed.
Our experts have defined a lightweight assessment to quickly make sure your systems are not affected by this vulnerability. We run our assessments which also leverage the use of our ZeroRisk Scoring Engine, a solution that will support you along the remediation path efficiently and quickly. Please contact us should you need our support on this topic.
I am the CTO, Senior Security Consultant, and PCI QSA since 2010 at Advantio.
Having executed close to a hundred (and counting) assessments across Europe, Asia, South Africa, and North America, I was able to observe many different implementations of all classic security controls and much more.
Now I spend much of my time with cloud technologies. Being passionate about cloud security and cloud resources management, my research focuses on the implementation of streamlined and scalable processes in the field of Threat Management for cloud-based ecosystems.
At Advantio, I am also part of the ZeroRisk team. Our vision is to make security and compliance simpler for our users.
Comments