Log4j Rehashed
It was December 10, 2021, when the cybersecurity community was ablaze with hunting down yet another critical vulnerability. I know it's hard to keep vulnerabilities straight when they are discovered oh so often. I hope to use this blog entry to get cyberTAP readers up to speed with the current situation regarding the Apache Log4J security vulnerability. Let's start at the basics.
Log4j is the Java logging library developed and maintained by the Apache Software Foundation. This library is used in many client and server applications; not just web applications. The log4j library is commonly included in Java-based software including multiple Apache frameworks such as Struts2, Solr, Druid, and Fink. The library provides enhanced logging functionality for Java applications and is widely used. As of May 2021, Apache web servers were used by 47% of websites with a known web server per Kinsta.com's knowledge base. Unless changed, the log4j library is the default logging library for all these web servers. So, yes, the attack surface is significant. Vulnerable versions of the log4j library have been found in a large list of security solutions also, so if you think your firewall will protect your webservers, what's going to protect your firewall?
This vulnerability is the result of a design error involving the Java Naming and Directory Interface (JNDI). JNDI is a part of how applications speak to each other, and in the case of this vulnerability, has left the application server utilizing the library vulnerable. JNDI handing in log4j (and all applications that use it) was susceptible to a variable injection attack (bad guys can insert text strings into fields that get logged), which can be used to trick the application into leaking sensitive information or executing attacker provided code. As a result of this vulnerability, threat actors can ultimately exfiltrate sensitive information or execute malicious payloads on vulnerable victim application servers, potentially allowing complete access to the network. The image below shows how an attacker can inject a JNDI string in a header field in the hopes it will get logged. If logged the vulnerable log4j library will act on the string, instead of just logging the event into a log file, it parses the injected string and attempts to interact with a remote LDAP server referenced in the JNDI string. LDAP stands for Lightweight Directory Access Protocol. Digging into LDAP is out of the scope of this blog; however, for simplicity's sake think Active Directory, when picturing an LDAP server. There are several free and opensource LDAP servers available for attackers to spin up quickly. The attacker's LDAP server will respond to the log4j inquiry with a piece of java code (e.g., java class), log4j will then execute that java code on the server hosting the log4j library. If the attacker controls the LDAP server, they also control the java class that is downloaded. Now, you understand why the end of 2021 was crazy for security engineering teams around the world.
Image tweeted by Lady G (@gabsmashh)
Okay, George, you have our attention. Now remind us of which versions are vulnerable? That's a great idea. As you may recall initially it was only log4j libraries from v2.01 – 2.3, v2.40 – 2.12.1, and v2.13.0 – 2.14.9. So, yeah, many years of log4j libraries being released that are susceptible to this attack. As Apache jumped on this issue and started developing patches, the security research community found a few more issues with the libraries and subsequently with the patches that had been released. In total three CVEs were created to capture all the vulnerabilities associated with log4j (CVE-2021-45105, CVE-2021-45046 and CVE-2021-44228); now collectively code named Log4Shell. At this point, I would recommend updating to v2.17.2. You can learn more about the current log4j library from Apache's logging services page - https://logging.apache.org/log4j/2.x/).
So, you're telling us that there were hundreds of millions of systems that were potentially affected by this issue, and hundreds of third-party software packages utilizing vulnerable log4j libraries. It's been 4 months; do we still need to worry about this vulnerability? YES! Until systems are completely patched, this vulnerability will be an easy target for attackers. As of March 15, 2022, this vulnerability is still rated as critical with a CVE score of 10 out of 10. Vulnerabilities don't get any nastier than this one. Apache has done a fantastic job of getting patches released. It is our job now to deploy those patches. In many cases, it is the job of your third-party software provider to upgrade their solution so that YOU can upgrade your installation. Just this week, on March 15, CISA added 15 new vulnerabilities that are actively being exploited some of which date back to 2015! You can review all the currently exploited vulnerabilities here: https://www.cisa.gov/known-exploited-vulnerabilities-catalog, and yes, you will find the log4j issue listed. The sheer number of systems where log4j is being utilized will make this vulnerability stick around for many years. There already have been several malware families (Barzarlader, Mirai, and various crypto mining software) observed using the log4j vulnerability to establish the attacker's foothold in an environment. It is my opinion that we are only months away from learning of a massive breach or ransomware attack that started with a simple 1-line string injected into a vulnerable application. It could be as simple as an attacker using the "contact us" form on a webpage to initiate this breach.
There are a number of things that I would recommend to help reduce the risk and impact of log4j exploitation.
1) Scan all public facing systems first, then move inwards. For large networks, you should assume an adversary already has a way into the network. Protecting intranet only applications should not be ignored.
2) Look for vulnerable libraries within the filesystem of all systems. Both CISA and Logpresso have great command line scanners that you can script to expedite the search. Check out each organization's GitHub for the latest version. My experience is it takes 3 to 5 minutes to scan an average web server. Fileservers will take significantly longer.
3) Scan your weblogs (or application logs) for suspicious strings. Look for strings containing JNDI, keep in mind that strings might be heavily obfuscated so you will have to iterate your queries to try to locate well-hidden log entries.
4) For many applications, making connections to the Internet may seem out of place. Look for the java process making connections to external hosts on suspicious ports. If you find connections, this is a good sign that you are being probed or you have already been compromised.
5) For many systems, Java should not have to call local processes. An attacker will explore their level of access if they are able to exploit log4j in your environment. Search for Java trying to run local executable such as cmd.exe, powershell.exe, python.exe, curl.exe, wget.exe, etc. Look for the equivalent in Linux/Unix environments.
6) Reduce the privileges of our applications to the bare minimum. If java is running with system-level access because it makes things easy, your log4j vulnerability status is significantly worse.
7) Ask your vendors and SaaS providers what they are doing to remediate their systems. It might be their systems, but it is your data and your reputation.
Whatever you do, don't just wait for auto-update processes to fix this one. The ability for the attacker to exploit this vulnerability remotely, as an unauthenticated user will keep it at the top of the attackers' arsenal for quite some time.
