The Log4j Vulnerability and How Enterprise Applications Are Exposed

In an interconnected world existing largely online, vulnerabilities and exploits to large systems do not exist in isolation.

So we learned last week, when Amazon Web Services (AWS) experienced an outage that affected millions of people and thousands of businesses.

Announced December 9 is a new vulnerability that has the potential to cause global havoc and affect millions more people, should a fix not be implemented immediately.

The problem lies in Log4j, a ubiquitous, open-source Apache logging framework that developers use to keep a record of activity within an application. Security responders are scrambling to patch the bug, which can be easily exploited to take control of vulnerable systems remotely.

Log4j is a Java library, and while the programming language is less popular with consumers these days, it’s still in very broad use in enterprise systems and web apps.

To exploit the vulnerability, a bad actor will need to cause the application to save a special string of characters in the log. Applications routinely log a wide range of events, including messages sent and received by users and system error details. Because of this, the vulnerability is unusually easy to exploit and can be triggered in a wide variety of ways. And worse, firewall protection alone does not eliminate risk

“This is a very serious vulnerability because of the widespread use of Java and this package log4j,” Cloudflare CTO John Graham-Cumming told The Verge. “There’s a tremendous amount of Java software connected to the internet and in back-end systems.”

“When I look back over the last 10 years, there are only two other exploits I can think of with a similar severity: Heartbleed, which allowed you to get information from servers that should have been secure, and Shellshock, which allowed you to run code on a remote machine.”

There is a wide diversity of applications vulnerable to the exploit, and a range of possible delivery mechanisms. Theoretically, the exploit could even be carried out physically by hiding the attack string in a QR code that was scanned by a package delivery company, making its way into the system without having been sent directly over the internet.

Free Wortley, CEO of the open source data security platform LunaSec, told WIRED, “It’s a design failure of catastrophic proportions.” LunaSec has already published their own assessment of the situation.

Governments around the world, including the United States-based Cybersecurity and Infrastructure Security Agency (CISA), issued warnings and encouraged users and administrators to implement appropriate mitigations immediately.

How is Tigunia affected?

Like most companies, we immediately started scanning our products and systems to see if any of our services use a vulnerable version of Log4j.

The Log4j vulnerability, as we mentioned, is a Java library. Java is an object-oriented programming language developed in the mid-1990s. Millions of programmers still use it, despite its many criticisms.

These criticisms pertain to its speed, its lack of native unsigned integer types, and, as one would guess after this week, its security risks.

Given this knowledge, Tigunia does not develop or implement Java in our own software. We were notified extremely early about the vulnerability through our Internal SecOps, including the available measures to protect ourselves with the latest patch versions.

We scanned our systems and found 1 application using the library and we implemented the new security measures to mitigate the risk quickly, enabling us to assess whether any new threat activity had been detected. We are happy to announce that we have not detected any malicious exploitation due to the CVE-2021-44228 vulnerability.

If you want to bring your company, and its technology and data hosting, into the current generation, contact Tigunia for more information.

Related Posts