John Hammond of Huntress joined Dennis Fisher on the Decipher podcast this week to discuss the Apache Log4j vulnerability. This is an edited and condensed transcript of that interview.
Dennis Fisher: What was your initial reaction when you read the advisory and kind of the creeping dread dawned on you?
John Hammond: You hit the nail on the head and that this log4j package is just ubiquitous. It's everywhere. So It's a Java logging package and that means that whenever an application tries to keep record of any sort of activity or what happens when a user interacts or engages with the program it logs it. It keeps note of it. The gimmick is that this Log4j library added some extra functionality now the bug and vulnerability that we're all screaming about, running around like chickens with our head cut off is that this will parse and take action upon the data presented in that log file in the entry, and the input supplied. That means hey it could reach out and actually execute code. It could call out to an external host that's serving a malicious payload and grant a bad actor remote code execution so they could detonate and run really whatever they'd like. Honestly, that opens the door. It's initial access. But that could then lead to privilege escalation, post-exploitation, exfiltration, persistence, lateral movement, anything.
Dennis Fisher: The way that I understand this is exploitable with just one line of code. There's not a whole lot to it.
John Hammond: That is absolutely correct. So I've tried to scream and shout about this to raise awareness the best I can. I have a kind of video demonstration. I have a walkthrough and a video up on my own YouTube channel that showcases how this is so easily exploited in Minecraft, the silly kids game. That's I think where this started to blow up. Truthfully it's very hard to validate and verify what is vulnerable and where because this package this logging functionality could be baked into any aspect of a program and that's what's so sinister about this vulnerability and that, yeah sure it's a zero day but other security researchers have likened this to like a cluster bomb of zero days and it's so many different applications and the hard part is detecting where and you can't just go off the file names or, hey we see the presence of Log4j, the class files, the jar files, because that has its own false positives and false negatives. Hey, the version might not be correct. It might not be used in some fragment of the program and application you're looking at. Really the best way to know is what I'm looking at vulnerable is to try a payload and see if you can see the connection and see the callback is dangerous.
Dennis Fisher: I've been digging in and looking at a lot of the security vendors and just technology vendors in general and looking at their sites to see what the updates are and you can almost see people saying, we don't think that this product is vulnerable and then update forty five minutes later, it's vulnerable.
John Hammond: I think folks have likened this to Shellshock, another vulnerability with an absolutely massive ginormous attack surface and is not dead. You know it's not gone by the wayside and I think this log4j vulnerability, while we're screaming about this and kind of on fire right now, we're at the very, very front of this. We will see this continue for this week potentially next month, months following that maybe years. Truthfully I don't know. There's a very real possibility that software packages and code that isn't maintained anymore legacy software applications that are just dead, they're not going to end up pushing a software patch or remediation and while we end users or asset administrators, IT practitioners, sure we could try and update, we could patch and update to the latest version of Log4j, we could make those changes the best we can. However, the software and vulnerabilities are the applications that are provided by vendors or other providers we’re kind of sitting on our hands. Waiting for them to push these updates downstream and I don't know how long that will take truthfully there's no way to know.
Dennis Fisher: I also wonder about the whole open source ecosystem too because you mentioned there's probably some dead applications out there that aren't maintained anymore or there's the other side of that coin where there's all these open source projects that are maintained but it's one person or two people and they may not have the wherewithal to be able to do this and get a patch out quickly. They probably have day jobs. They probably have other stuff to do.
John Hammond: Oh absolutely and that's why we are shouting about this thing right? Because that's why we're making a big stink of it because it is such a big deal but we're trying to raise awareness we're trying to educate. We're trying to kind of hold the entire community and the industry accountable. This is absolutely a hard pill to swallow but it has to get done. This is this is how we respond. This is how we recover. I'm really glad that you mentioned sort of that open source software developer perspective because the application itself is an open source utility put together by a few of those individuals that are creating the software. Volunteer work. You know they do it as a labor of love. It's a passion. It's something that they do in their spare time and their free time while they work a day job.
"We know that this attack is trivial to pull together and pull off. It's a single line of text."
Dennis Fisher: In terms of the attacks that are ongoing, I'm going to guess without knowing for sure that this is probably spread from top to bottom in the attacker ecosystem.
John Hammond: Yes is the short answer right? The long answer is that we know that this attack is trivial to pull together and pull off. It's a single line of text. The syntax is sort of a dollar sign, curly braces. You know, whatever special character magic that invokes the JNDI, or the Java naming and directory interface, using a specific protocol and that JNDI API supports lots of different ones between LDAP, RMI, even COBRA. So far we've seen cryptocurrency miners and botnets. I believe even Microsoft has said hey we are seeing some Cobalt Strike beacons. Again could be used for more post-exploitation or later damage. I think what we're doing right now to get out in front of it the best that we can is absolutely vital.
Dennis Fisher: The ransomware apocalypse is honestly what I expected to wake up to today, just given the way that things have been going for the last couple of years. The ubiquity of this vulnerability and it looks like a perfect opportunity for ransomware actors to make a whole bunch of money and cause a whole bunch of damage. Do you have any thoughts on why that hasn't happened yet?
John Hammond: Ttruthfully I don't know why other than goodness, we are so fortunate that we haven't seen this world blow up yet. I have to think, and this might be just a guess, when this application is exploited, when a vulnerable program is actually taken advantage of, you're still running in the context of that application, whatever account you may have landed in as a threat actor so there is maybe potentially an element of separation there. There is a security boundary if you have the access controls in place, this program is running with least privilege. Whether it's for Apache Solr or Druid or others that doesn't mean that they can immediately own this whole thing as the admin account as root right? They don't have their god superpowers yet. Maybe that's a barrier of entry for some of the script kiddies.