Log4j library still vulnerable to the Log4Shell exploit

Updated on 2022-12-29

The Log4Shell vulnerability remains a big threat to organizations even after a year since it received security patches. It is found that around 40% of software continues to use vulnerable versions of Apache Log4j. Read more: Lessons Learned: The Log4J Vulnerability 12 Months On

Updated on 2022-12-12: Log4Shell one-year anniversary

Happy birthday to one of the most over-hyped vulnerabilities in recent years! Here’s a collection of excellent memes that came out of it.

Updated on 2022-12-05: Log4Shell anniversary

The Log4Shell anniversary will be coming this week, and most likely a new vulnerability too. That’s how the month of December works in infosec. A major security disaster before everyone’s winter holiday. Read more: Log4j one year in: Vulnerability fuels attacks — and a new urgency for software supply chain security

Updated on 2022-12-01: Log4Shell, one year later

Vulnerability management platform Tenable says that following a series of tests, it found that 72% of organizations still remain vulnerable to the Log4Shell vulnerability, disclosed a year ago in December 2021. Tenable says that 28% of organizations across the globe have fully remediated Log4Shell as of October 1, 2022, doubling the figure from May 2022. Read more: Tenable Research Finds 72% of Organizations Remain Vulnerable to “Nightmare” Log4j Vulnerability

Updated on 2022-11-29

Almost one year after the Log4Shell vulnerability was disclosed, around one in four downloads of the Log4j library are still for a version that’s vulnerable to the Log4Shell exploit, according to Sonatype CTO and co-founder Brian Fox. Nonetheless, Fox notes that the company has seen “a little uptick in [the download of] safe versions in the last few months.” Read more: Log4j Vulnerable Downloads Dashboard

Updated on 2022-11-21: Iranian hackers breached U.S. federal agency that failed to patch Log4Shell

U.S. cybersecurity agency CISA announced this week that a U.S. federal civilian agency was compromised earlier this year by Iran-backed hackers, likely working on behalf of the regime. CISA didn’t name the agency or say what, if anything, was taken. Washington Post ($) reports it was the little-known U.S. Merit Systems Protection Board, an agency that “adjudicates grievances from federal government employees in areas such as whistleblower retaliation” (which, sidenote: 👀). CISA said it learned of the compromise months later in April. The hackers broke in by exploiting Log4Shell, the zero-day bug in the ubiquitous Log4j open source software, found in a server on the federal agency’s network. This happened just weeks after CISA ordered all federal agencies to patch their systems. A couple of key questions for the cyber agency: Did the breach agency ignore CISA’s directive, or can CISA effectively enforce its directives? Read More:

CISA spox. declined to answer our questions or say for what reason why the breached federal agency failed to patch its systems, despite CISA's emergency directive mandating patches in December 2021. Did the breached agency ignore? Can CISA effectively enforce its directives? 🤷

— Zack Whittaker (@zackwhittaker) November 17, 2022

Updated on 2022-11-21: Log4Shell campaigns are using Nashorn to get reverse shell on victim’s machines

Almost one year later, Log4Shell attacks are still alive and making victims. Log4shell, as you may remember, was the name given to a remote code execution (RCE) vulnerability in the Apache Log4j Java library, first known on December 10th, 2021.

In an incident case I got last week, attackers started a reverse shell on the victim’s machine in a way I have not seen in Log4Shell exploitations. The reverse shell was issued using Nashorn, a JavaScript scripting engine used to execute JavaScript code dynamically at JVM. Similar use of Nashorn was seen in Confluence CVE-2022-26134 exploitations. Read more: Log4Shell campaigns are using Nashorn to get reverse shell on victim’s machines

Updated on 2022-11-17: CISA and FBI: If You Haven’t Patched Log4Shell, Assume Your Systems are Compromised

A joint cybersecurity alert from the Cybersecurity and Infrastructure Security Agency (CISA) and the FBI details advanced persistent threat activity conducted by Iranian state-sponsored threat actors against the network of an unnamed federal civilian executive branch organization. The attackers gained initial access earlier this year by exploiting the Log4Shell vulnerability. The alert says, “CISA and FBI encourage all organizations with affected VMware systems that did not immediately apply available patches or workarounds to assume compromise and initiate threat hunting activities.”

Note

Log4Shell is a tricky vulnerability in that exploitability depends first of all on how the library is exactly used, and secondly on the creativity of the attacker to reach the vulnerable code. Please do not underestimate the creativity of the attacker as you are assessing how this vulnerability impacts you. Patch.
Sage advice – assume compromise, apply patches or implement workarounds. It’s been a year since discovery of the Log4j vulnerability. Patches have been produced, workarounds documented and available; yet the government still has to issue an alert. Organizations and their leadership have to be held accountable for not establishing a standard duty of care.
You knew this was coming, even so you couldn’t get support to update everything. It’s time revisit all your systems where you’ve not deployed the patches and forensicate them to make sure they are still pristine. And patch them. Make sure that you’re not exposing unneeded services to the internet, like your VMware management network, use MFA judiciously, particularly on your internet facing services, and make sure that everything is plumbed into your centralized logging, and then that appropriate alerts are in place both for your SOC and IT staff. Implement a service which checks credentials against breach dumps and require immediate change or account lock when discovered. Now, a tricky one, make sure that you are using access controls to limit credentials to only operate on authorized services/systems to restrict lateral movement.
Or if you are a customer of SolarWinds. Indeed, assuming that one is compromised can be a prudent and useful assumption. Finding and eliminating covert and dormant compromise is a daunting problem. Consider structuring one’s network and implementing least privilege access control so as to resist its spread and exploitation.

Read more in

Updated on 2022-11-16

The CISA and the FBI published a joint advisory recommending organizations implement threat hunting to eradicate Iranian APTs that abused Log4Shell to infiltrate a federal agency network. Read more: US Gov Warning: Start Hunting for Iranian APTs That Exploited Log4j

Overview: Iranian state hackers breached US government agency and deployed a cryptominer, out of all things

In a joint security advisory this week, CISA and the FBI revealed that an Iranian APT group breached the network of a US government organization in an attack that could have turned out much worse than it did.

The breach took place earlier this year, in February, and CISA and FBI incident responders said the threat actor used an exploit for the Log4Shell vulnerability to take control over a VMWare Horizon server, moved laterally inside the victim’s network, compromised the domain controller and local credentials, and deployed reverse proxies on several hosts for future access.

The report doesn’t mention anything about sensitive data collection or abuse of the agency’s email domain for espionage purposes but instead claims that the intruders deployed a very basic and widely known cryptocurrency mining app known as XMRig to mine the Monero cryptocurrency on the agency’s servers, for their own personal gains.

This seems odd, but if you’ve read enough reporting on Iranian APTs, it’s actually not that strange since it’s widely known at this point that the Iranian government heavily relies on third-party contractors to carry out offensive cyber operations and espionage activity.

Previous reports have linked several of these groups to both classic espionage activity but also to your run-of-the-mill financially motivated cybercrime, usually carried out from the same infrastructure but for the personal gain of the operator, who would most likely know that because of their Iran citizenship, they would face almost no consequences for their actions.

For example, Iranian threat groups have been linked to internet-wide scans that compromised corporate systems, which were later put on sale on cybercrime forums. They’ve also been linked to different ransomware strains and subsequent payments, but also to the theft of academic papers that were later resold internally, in Iran, on dedicated web portals.

While the joint alert doesn’t mention the victim, the Washington Post cites people familiar with the investigation who claim that the compromised agency was the Merit Systems Protection Board, a small government agency established to protect government workers against partisan political actions. Obviously, not the high-end US government target you’d expect, which would explain why the intruders chose mining over espionage.

WaPo also identified the Iranian hacking group as Nemesis Kitten. This group—also known as DEV-0270, Cobalt Mirage, APT42, and UNC788—has been linked in the past to attacks with the Log4Shell vulnerability, but also ransomware.

Some security experts have already suggested that deploying a cryptominer could be a cover to hide their espionage-related operations, but is it, though?

If there’s one thing that’s known about cryptomining is that it’s noisy as hell. Once you deploy a cryptominer, your entire server slows down to a crawl, which often leads to your IT team looking into your active process lists and spotting XMRig, one of the most common signs that you’ve been hacked. In a government agency, that usually implies calling in the feds and DHS, so this theory doesn’t particularly hold up.

It’s quite possible that the intruders either didn’t have the vision to see how they could abuse MSPB’s position in the US government infrastructure, or they just didn’t care or know what they compromised.