Huntress’ John Hammond: Log4j Could Have Been ‘Ransomware Armageddon’

‘It’s very evident that a lot of the technology, a lot of security stacks, a lot of software stacks that managed service providers use are still going to be affected by this. This affects so much, it’s ubiquitous. There’s no mistake, small and mid-market businesses and MSPs are going to see the effects,’ says John Hammond, senior security researcher at Huntress.

The Java logging library Apache Log4j vulnerability could have been prevented, according to John Hammond, senior security researcher for Huntress. The flaw affected dozens of software vendors and their partners and customers and will be wreaking havoc for years to come.

If they haven’t already, Hammond said MSPs can take a multitude of actions like a simple Google search of how their vendor is handling it, patching often and communicating with their customers.

Affected companies like Cisco, IBM and VMware have all put out statements on how they’ve been affected and how they’re deploying patches. Over the weekend, the U.S. Cybersecurity and Infrastructure Security Agency (CISA) urged vendors to swiftly identify, mitigate and patch the wide array of products using software from the Log4j library.
CRN spoke with Hammond on how this vulnerability differs from other software vulnerabilities, the government finally taking action and how this impacts the MSP community.

Could this vulnerability been easily prevented?

Yes is the short answer. The long answer is this new feature functionality and bug was brought into the Log4j application back in 2013. There’s a Blackhat talk floating around back in 2016 that showcased this attack vector. It wasn’t specific to Log4j but we knew the industry had seen this attack vector for five years now. If folks may be paid a little bit more attention to some of the weird oddities that we had seen in that potential package in that 2013 feature request, we might have been able to be a little bit ahead of the ball here.

What could have happened if this vulnerability wasn’t found?

This will play well into what we’re seeing for current industry threats. If it were just dropped as zero day and we didn’t have the awareness or knowledge of it, if it were weaponized further by nation, state actors, advanced persistent threats or real sophisticated adversaries, then it would be ransomware Armageddon. [It would’ve been] cobalt strike beacons, implants and remote access Trojans on practically anything that they could get their hands on. We’ve seen a spray and pray across the internet for cryptocurrency miners and botnets. Not to trivialize what those threats are, they’re still valid threats but it doesn’t have the same damning impact as ransomware.

The U.S. Cybersecurity and Infrastructure Agency is not only putting out statements now, they’re telling IT experts how they can remedy this. What are your thoughts on this?

I am very, very happy to see this effort and action taken from CISA and so many other government agencies and our political bodies. We’ve seen a lot of proactive effort in some of the recent events [such as] ransomware takedowns and arrests, even taking the effort to go patch Microsoft Exchange servers. We could list a good amount of examples here now. But now it’s taking the entire industry and the entire community to really make a stink of this. We’re screaming about it. We’re shouting from the rooftops. [There has been] an incredible outpour of researchers and practitioners and administrators saying like, ‘Hey, use these detection tools. Here’s some free resources. Here’s as much information as we can give to you. Look for these mitigation efforts, use these patches.’ If there is any silver lining from this, it’s absolutely that. It’s the incredible joint collaboration effort from the entire landscape.

What was the impact on MSPs?

There has been a growing impact on MSPs. We’ve seen a numerous amount of vendors be able to kind of come out of the woodwork and start to release their own advisories and notifications for this. There was some concerns that were rising from larger remote monitoring and management applications. F Secure was affected, VMware might have even had a couple hotspots. It’s very evident that a lot of the technology, a lot of security stacks, a lot of software stacks that managed service providers use are still going to be affected by this. This affects so much, it’s ubiquitous. There’s no mistake, small and mid-market businesses and MSPs are going to see the effects.

What measures should MSPs be taking to protect themselves?

I really need to get across the idea that if you don‘t consider yourself a cybersecurity nerd or wizard, if you think, ‘Hey, I’m not a computer person,’ still be cognizant of the applications and software that you use on a day-to-day basis. Literally do a Google search of name of application and Log4j and see if that software provider or vendor has put out any notifications and advisories on it. If they have mitigations and steps you can take to remedy and recover from this, go do that as quick as you can. If they have patches and hot fixes and updates available, install those right away. Ultimately, it boils down to the same old silly security baselines and best practices when we say run a solid antivirus, be aware of networks coming in and out of your environment. That is still the foundation that we need here, but the tried-and-true practice of patching is patch early, patch often, patch always. It’s paramount right now.

What action should MSPs they take to better protect their customers?

That boils down to a serious amount of communication, transparency and honesty. We need to have the messaging and the education. If they have not already sent out notifications and their own updates to their customers that say, ‘Hey, we‘re tracking this Log4j vulnerability. We’re doing our own investigations. We’re determining how you could be affected.’ That’s the best that they could do to get started and then go take those efforts to detect, hunt down the vulnerability and mitigate it and patch it.

What makes the Log4j package vulnerability to so unique or dangerous compared to other software or code vulnerabilities?

It’s used in Java a lot of Apache Software. These dependencies. These are libraries and modules that are pulled in in a plug-and-play fashion for a lot of software. The damning portion of this is that it could be baked in somewhere, anywhere, in an egregious amount of software. We‘ll see the implications of this either because we just haven’t found or discovered the flaw in some corner and crevice of an app of a program for however long. Some code,, some software, some applications might not even be maintained or updated anymore. It’s legacy dead software that will never get a patch or an update. A lot of security researchers have likened this to the Shellshock vulnerability which was well known for its enormous attack surface. This is the same that we’re seeing for Log4j.