Exploit continues to plague the IT realm
Back in December 2021, an unfortunate, widespread flaw took the IT and cyber world by storm. By now, most in the industry are familiar with it, the now-infamous Log4j exploit. This nasty problem, operating as an archive resource for Java, can be found virtually anywhere because of Java’s widespread applications and uses. By this metric, and according to CISA’s (Cybersecurity and Infrastructure Security Agency) director, Jen Easterly, it’s the worst exploit they’ve seen in their entire career.
Identifying vulnerabilities caused by the exploit also proves difficult, as it’s hard to know which applications were vulnerable. Information abound by the problem also took relevant sectors of the internet by storm. Malicious parties were eager to capitalize while those affected released scanning and patch tools with haste to mitigate any potential damage.
The first weeks of the exploit
The gravity and seriousness of the Log4j exploit is indeed Herculean in nature. That’s why it’s surprising no major cyberattacks occurred during its initial discovery, at least not to the degree of the SolarWinds or Kaseya incidents. It’s possible the lack of action came from figuring things out on a fly-by basis. Both attackers and respondents knew there was a serious flaw, but how best to take advantage/protect against it remained the question.
There were still various instances of attack and compromised networks, though. Attackers would use the exploit to “break” into VM Horizon servers and then install persistent malware to maintain access and monitoring. In those cases, exploitation of resources was common, used for processes like cryptomining. That’s because, when used “correctly,” the Log4j exploit can give administrator-level privileges to the offending party, or in other words, total control/access.
Other exploit examples
To again emphasize the dangers of the exploit, you have to understand the lateral privileges it grants. Specifically, the vulnerability caused by CVE-2021-44228 Log4j. The access privileges allow them to perform a collection of administrator-level actions. Basic permissions become commanding ones, all of which are difficult to track at the source. Depending on the kind of exploit and the systems it affects, such a problem can quickly become widespread. Worsening problems is updating any Java-based platform isn’t enough, as the exploit still works after the fact. The only counter solution is identifying the specific exploit and patching against it.
Here’s an example of an outbound-based exploit: an outbound connection reaches out to an LDAP protocol to retrieve a Java class host. In that request, attackers can exfiltrate and obtain sensitive information. Variables from that environmental data could, again, unlock other permissions with dangerous outcomes.
Longevity of the problem
With such a widespread and disruptive exploit, the Log4j issue isn’t expected to disappear anytime soon. Because patching isn’t a catch-all solution, a standard defense is not yet available beyond patching the problem on a case-by-case basis. The common use of Java and how embedded it is into development, solving the exploit will likely take years. In other scenarios, those affected by the exploit may not know about a vulnerability until it’s too late.
Awareness of the exploit is important to protect yourself, and keeping an eye on new exploits or developments related to Log4j. While attackers have not fully utilized the exploit to their advantage, they’ll continue to do so until a common solution is found, if ever.
