Beware of the Log4j vulnerability! This nasty software bug has much of the IT world in a panic as it follows us into the New Year.
No doubt, many organizations and SMBs with no IT staff are clueless about its existence. But ignorance of Log4j only makes them more susceptible to an attack. They remain defenseless.
Log4j is a very common section of code that helps software applications keep track of their past activities. Code writers rely on this recurring code rather than reinvent the software wheel by creating more logging or record-keeping programs to duplicate the same functions.
Earlier this month, cybersecurity experts found that by asking Log4j to log a line of malicious code, Log4j executes that code in the process. This gives bad actors access to controlling servers that are running Log4j.
That revelation put nearly every major software company in crisis mode. They searched their products to see if the Log4j vulnerability affected them and, if so, how they could patch the hole.
This vulnerability is a huge deal. Log4j has been around for nearly a decade, noted Theresa Payton, former White House chief information officer and CEO of cybersecurity consultancy firm Fortalice Solutions.
“Think of it as your library of all things loggable. We tell organizations [to] log it all [as] you may need it for forensics later. So Log4J is often used by Java developers when they want to log that a person logged in and may even use it to track access to applications,” Payton told TechNewsWorld.
Many businesses may not even know if they have used Log4j, which makes knowing the scope of the problem even more difficult. In order for them to find out, they would need a software engineer to go through the various systems to look for the usage and then look at the versions, she added.
“It can be a time-consuming process,” Payton noted, “and time is something that you do not have when you are racing against the clock against bad actors seeking to exploit these vulnerabilities.”
Back Door for Hackers
Think of a door lock used in a variety of security hardware installations in millions of locations around the world. Some of the door locks have the same part failure in a tiny sprocket that lets almost any key open the lock.
Changing your own lock is an easy fix if you know about the potential failure and have the tools to do the replacement job. Doing that worldwide is an insurmountable task. That concept is what makes the Log4j debacle so threatening.
Log4j is part of the Java programming language used in writing software since the mid-1990s. Software running Log4j code drives enterprise and consumer applications everywhere.
Cloud storage companies that provide the digital backbone for millions of other apps also are affected. Major software sellers of programs used in millions of devices are involved too.
Typically when a security vulnerability is found, the chief information security officer (CISO) leads the charge to update and patch systems or put in place manual mitigations, explained Payton. Log4j is more insidious and hidden and not fully in the control of the CISO.
“Hunting and finding this vulnerability requires everyone who is a programmer. Where does development happen nowadays — everywhere! Developers can be internal staff, outsourced development, offshore development, and third-party vendors,” she observed.
That all amounts to an inexhaustible attack opportunity for hackers. Of course, not everyone will be hacked, at least not immediately. The key big question is finding out if your equipment is burdened with the problematic code. Just finding out is putting IT departments and software engineers into overload.
“The implications of the exploitation of this vulnerability are the stuff of my nightmares. An unethical hacker with knowledge and access could use this vulnerability and target servers using this logging capability with remote code execution on servers,” warned Payton.
Attack Vectors Widening
Hackers are now fully aware of the Log4j vulnerability. Cybersecurity hunters are seeing numerous cases where bad guys are expanding what they can do with their attacks.
The Blumira research team recently discovered an alternative attack vector in the Log4j vulnerability that relies on a basic Javascript WebSocket connection to trigger the remote code execution vulnerability (RCE) locally via drive-by compromise. That discovery worsens the vulnerability situation.
One early assumption by cybersecurity experts was that the impact of Log4j was limited to exposed vulnerable servers. This newly-discovered attack vector means that anyone with a vulnerable Log4j version can be exploited through the path of a listening server on their machine or local network by browsing to a website and triggering the vulnerability.
WebSockets have previously been used for port scanning internal systems, but this represents one of the first remote code execution exploits being relayed by WebSockets, offered Jake Williams, co-founder and CTO at incident response firm BreachQuest.
“This should not change anyone’s position on vulnerability management, though. Organizations should be pushing to patch quickly and mitigate by preventing outbound connections from potentially vulnerable services where patching is not an option,” he told TechNewsWorld.
While significant, attackers will likely favor the remote exploit versus the local one, added John Bambenek, principal threat hunter at digital IT and security operations company Netenrich. That being said, this news does mean that relying on WAF, or other network defenses, is no longer effective mitigation.
“Patching remains the single most important step an organization can take,” he told TechNewsWorld.
Log4Shell Vulnerability
The Log4j vulnerability, dubbed Log4Shell, already provides a relatively easy exploit path for threat actors, noted Blumira’s report. It does not require authentication to take full control of web servers.
Using this vulnerability, attackers can call external Java libraries via ${jdni:ldap:// and ${jndi:ldaps:// and drop shells to deploy the RCE attack without additional effort. This new attack vector expands the attack surface for Log4j even further and can impact services even running as localhost, which was not exposed to any network, according to Blumira.
“When the Log4j vulnerability was released, it became quickly apparent that it had the potential to become a larger problem. This attack vector opens up a variety of potential malicious use cases, from malvertisting to creating watering holes for drive-by attacks,” said Matthew Warner, CTO and co-founder of Blumira.
“Bringing this information to light ensures that organizations have the opportunity to act quickly and protect themselves against malicious threat actors,” he added.
Log4j Linked to Dridex, Meterpreter
The Log4j vulnerability offshoot Log4Shell is yet another infection path that researchers recently discovered installing the notorious Dridex banking trojan or Meterpreter on vulnerable devices, according to a Bleeping Computer report.
Dridex malware is a banking trojan first developed to steal online banking credentials. It evolved into a loader that downloads various modules to perform tasks such as installing additional payloads, spreading to other devices, and taking screenshots.
Primarily used to execute Windows commands, if Dridex lands on a non-Windows machine, it instead downloads and executes a Python script for Linux/Unix to install Meterpreter.
Meterpreter, a Metasploit attack payload, is deployed using in-memory DLL injection that resides in memory and writes nothing to disk. It provides an interactive shell an attacker uses to explore the target machine and execute code.
Jen Easterly, U.S. Director of the Cybersecurity and Infrastructure Security Agency, said in recent media presentations that the Log4j vulnerability is the most serious vulnerability she has seen in her decades-long career. Cybersecurity experts warn that the Log4j vulnerability is the biggest software hole ever in terms of the number of services, sites, and devices exposed.
Loading ...
