Pivotal Apache Log4j2 issue still jeopardizes worldwide finance
June 01, 2024
Apache Log4j2 library’s CVE-2021-44832 vulnerability remains a significant concern across numerous sectors, as experts caution about its impact on global Finance.
Renowned cyber threat intelligence analyst Anis Haboubi raises flags over a critical logging setup flaw that has the potential to drastically affect the financial sector.
“Apache Log4j2 versions 2.0-beta7 through 2.17.0 (excluding security fix releases 2.3.2 and 2.12.4) are vulnerable to a remote code execution (RCE) attack where an attacker with permission to modify the logging configuration file can construct a malicious configuration using a JDBC Appender with a data source referencing a JNDI URI which can execute remote code. This issue is fixed by limiting JNDI data source names to the java protocol in Log4j2 versions 2.17.1, 2.12.4, and 2.3.2.” reads the advisory.
The vulnerability was initially discovered by Checkmarx security researcher Yaniv Nizry who promptly brought it to Apache’s attention on December 27, 2020. Thereafter, the Apache Software Foundation promptly released Log4j 2.17.1 version to rectify the flaw.
The recent security breaches at Sisense and Snowflake, both holding ISO/IEC 27001 certifications, underscore a crucial weakness that poses a persistent threat to the financial sector at large. Despite rigorous adherence to security protocols, imperfections within their systems have left critical financial data vulnerable to unauthorized intrusions, potentially unleashing catastrophic outcomes, Haboubi informed SecurityAffairs.
Why is this aged vulnerability still a menace to the Finance realm?
The critical flaw in logging configurations allows attackers with writing privileges to leverage a JDBC Appender with a JNDI URI, thereby enabling remote code execution. This scenario could lead to a complete system takeover, granting unauthorized parties the ability to execute malicious codes from a distance and gain access to delicate financial data. Sisense and Snowflake hold the trust of renowned international financial entities.
“These organizations heavily rely on their solutions for pivotal operations such as data analytics and cloud storage. Any breach within these systems could disrupt global financial operations, inflicting significant financial and reputational harm.” stated Haboubi.
“The breaches have resulted in the exfiltration of several terabytes of customer data, including access tokens, email account passwords, and SSL certificates. This exploited data could provide attackers with further entry points into financial systems, enabling fraudulent activities. Interconnected Financial Systems: The financial sector operates in a highly interconnected manner. A vulnerability in one system could trigger a chain reaction, endangering other systems and services. The potential ripple effect poses a substantial threat.”
These breaches have raised concerns regarding the security measures put in place by Sisense and Snowflake to safeguard delicate data. The acquired data, which seemingly lacked encryption at rest, highlights the pressing necessity for beefed-up security protocols.
Conclusively, the vulnerabilities present in the infrastructures of Sisense and Snowflake, combined with their extensive adoption within the finance industry, present a formidable threat. Immediate measures must be taken to address these vulnerabilities and shield the integrity of financial operations worldwide. Enhanced security strategies, like incorporating PEM key-based authentication, play a crucial role in thwarting potential future breaches and securing sensitive financial data.
“It’s rather astounding. I suspect the infiltrations were executed several months, or maybe even years, ago. They likely awaited the opportune moment to siphon off the data, and Sisense only recently unearthed the breach. A paramount concern to me is that Sisense permitted “Connecting to a Private Network with an SSH Tunnel” without a PEM key. This is the discretely addressed issue in the commit I shared with you. The attackers evidently exploited the Log4j vulnerability from the inception to secure privileged access to critical infrastructures. They then laid low for months to evaluate if they could maintain their foothold” concluded the expert. “even today 30% of log4J installations are vulnerable to log4hell”
Follow me on Twitter: @securityaffairs and Facebook and Mastodon
(SecurityAffairs – hacking, Log4j2)
About Author
