Amidst mitigation, Log4j one of the worst internet bugs in history is still being exploited.
The Apache Software Foundation revealed a vulnerability, sending the global tech industry into a frenzy. The bug, identified as Log4Shell, was in the pervasive open-source logging library Log4j as well as exposed to a broad range of applications and services—from famous consumer and business platforms to vital infrastructure and IoT devices. Log4Shell no longer poses the universal threat it once did, thanks to months of focused remediation last December and a year of cumulative patching progress. Log4j vulnerability is still active a year later. However, researchers caution that the weakness still exists in many systems around the world and that hackers will be able to exploit it for years to come.
Many critical vulnerabilities are discovered each year that require immediate attention, but Log4Shell was unique in that it was so simple to manipulate wherever it was prevalent, with few provisos or subtleties for threat actors to navigate. Developers use logging utilities to record operations within a given application. To exploit Log4Shell, attackers need to get the scheme to log a specific code string. They can then take control of their goal in order to install malware or launch other digital attacks. Because loggers will log in, trying to introduce the evil snippet can be as simple which include it in an account user id or having to send it in an email.
The Logging of Log4j
“Logging is essential to almost any computer hardware or software operation.” “Logging will be present, whether it’s a phlebotomy machine or an application server,” says David Nalley, head of state of the nonprofit Apache Software Foundation. “We knew Log4j was widely deployed because we saw the install numbers, but it’s difficult to fully grasp because you’re not going to sell a product and tracking contracts in open source.” I don’t think you can truly understand it until you have a complete inventory of where software is, what it’s doing, and who’s using it. And the fact it was so pervasive played a role of everybody reacting so quickly. To be honest, it’s a little humbling.”
The situation echoes broader conversations about the application supply chain and the fact that many organizations do not keep an accurate inventory of all of the software they use in their processes, making it more challenging to identify and patch vulnerable code. Part of the problem is that even if an organization has a list of all the software it has purchased or deployed, those programmes may encompass other software-accessible library services and utility companies Log4j—that the end user isn’t aware of and didn’t choose. This causes the cascading effect of security vulnerabilities like Log4Shell in addition to the tail of patch management, in which organizations are either unaware that they are vulnerable or fail to recognize the importance of investing in security.
Meanwhile, attackers continue to actively exploit Log4Shell in any way those who can, from cybercriminals trying to break into targeted advertisements’ systems to Chinese and Iranian government attackers using the exploit in espionage campaigns.
The revealed Log4j
“Log4Shell is going to be a root cause in data theft for the next decade—all it takes is one example of Log4Shell to be vulnerable,” says Dan Lorenc, CEO of software supply-chain security firm Chainguard. “Fortunately, most consumers did not feel the impact last year because the severity was so severe that people hurried over that terrible weekend and the vacations in a race with attackers.” And we won’t be able to scramble everyone for something even slightly less severe.”
When Apache fully revealed the scenario on December 9 of last year, it had to scramble to be ready to release spots for Log4Shell by the beginning of 2021. As a result, scientists quickly discovered exceptional cases and countermeasures to the patches, forcing Apache to release multiple iterations, adding to the confusion.
“This thing was all around, truly everywhere,” says open source security researcher Jonathan Leitschuh. “Attackers jumped on it, the security industry jumped on it, and payloads flew everywhere.”
However, researchers claim that Apache’s overall reaction was intense. Nalley adds that in response to the Log4Shell saga, Apache has made changes and improvements and decided to hire a dedicated team to broaden the security protection it can offer to open-source projects in order to catch glitches before those who ship in code and respond to incidents as needed.
Also, read Iranian Hackers Exploiting Unpatched Log4j 2 Bugs
“We had fixes out in a short amount of time, about two weeks,” Nalley says. “In some ways, this isn’t a new situation for us, and I’d like to say we handled it flawlessly.” However, even within the Apache Software Foundation, it has highlighted our obligation to everyone who uses our software.”
Concerns of Log4j
The more concerning aspect of the situation moving forward is that even a year later, roughly a half times or more of Log4j download speeds from the Apache archive Maven Center and other object storage servers are still full of vulnerable versions of Log4j. In other words, software engineers are still vigorously maintaining systems running susceptible versions of the functionality or even creating new vulnerable software.
Also, read Vmware Horizon servers continue to be exploited through log4j vulnerability
“The reality is that most of the time when people choose a vulnerable open-source software component, there is already a fix available,” says Brian Fox, cofounder, and chief technology officer of Sonatype, which also works Maven Central as well as a third-party Apache repository provider.
Fox claims that after the initial rush to confront Log4Shell, edition download speeds in Maven Central and other repositories hit a plateau, with roughly 60% of downloads being of security patches versions and 40% being of vulnerable versions. Fox and Apache’s Nalley say that in the last 3 months or so, the numbers have dropped to roughly a 75/25 split for the first time. “After a year,” Fox says, “a quarter of the downloads still is pretty awful.”
Also, read MERCURY leveraging Log4j 2 vulnerabilities
“Some people believe Log4j was a significant wake-up call to the sector, a collaborative freak-out, and awakening,” he says. “And it has allowed us to expand on the text about application supply-chain security because people are no longer in denial.” We all were living the thing we had all been talking about. But Log4j’s peer pressure alone should have compelled everybody to enhance, so if we can’t get this one to 100%, what about the rest?”
Conclusion
The question of how to address a vulnerability’s long tail is always present for security researchers. The problem affects open-source software and proprietary systems. Consider how long it took to migrate the last 10% of Windows users away from XP.
“With these worst-case situations swan occurrences in free software, just understand they’re going to continue to happen,” Lorenc of ChainGuard says. “As a result, we must strike a balance between prevention and mitigation and continue to develop efforts to decrease the regularity as much as possible.” It’s similar to the Simpsons meme in which Bart says, ‘It’s the worst day of my life.’ ‘The worst day of your life so far,’ says Homer.
