Zero Day Initiative seeing an increase in failed patches

LAS VEGAS -- An influx of bad patches led the Zero Day Initiative to overhaul its bug bounty disclosure timelines.

ZDI is a bug bounty program started in 2005 by network security company TippingPoint; Trend Micro gained the program as part of its acquisition of TippingPoint in 2015. ZDI also runs Pwn2Own, a popular hacking contest where contestants exploit software and hardware in order to win device and cash prizes.

ZDI is a vendor-agnostic bug bounty program, meaning it buys flaws and exploits from researchers before submitting them to the appropriate vendors. It is the largest program of its kind; a report from analyst firm Omdia found that ZDI was responsible for more than 60% of all vulnerabilities disclosed and given a CVE designation in 2021.

At Black Hat USA 2022, Brian Gorenc, Trend Micro senior director of threat research, and Dustin Childs, ZDI senior communications manager, discussed the current state of bug bounty programs.

The duo announced at the show that ZDI was introducing new vulnerability disclosure timelines for any flaw that ZDI believes resulted from a faulty patch. In this interview, Gorenc and Childs discuss the fallout from incomplete patches, the drawbacks of automated vulnerability disclosure systems and more.

Over the last couple of years, there has been an educational push to improve security posture. Advice about staying patched and using zero trust and multifactor authentication is extremely common in vendor reports. That said, patching, for example, is easier said than done when there's a talent gap and resource constraints. Have organizations started to answer these calls and improve their patch rates?

Dustin Childs: I think, if anything, it has gotten worse in the last year. Part of that is the declining quality of the patches. If you go back to Print Nightmare, which we're just on a one-year anniversary for, not only was that patch easily circumvented from the security perspective, it broke a lot of printing. There are a lot of sys admins who had to install two updates today. And I've already seen sys admins online talking about, 'Oh no, we don't trust the patch because we can't break printing again.' They're losing faith in security updates, so even when they were staying up to date, now there's less of that because they don't trust the patches as much.

Brian Gorenc: We're seeing in our program that there are more failed patches being released, and we'll see it where a researcher wants to submit a bypass for the original vulnerability within hours, so there's a really fast response time from the researchers who are looking at these things. I think, for us, it's the issues with failed patches that highlight the attack surface because you can see that change in the code. You can understand that there's actually a bug there, and if that patch isn't complete, the threat actor has an opportunity to take advantage of that vulnerability -- even though the enterprise believes that they've actually resolved the issue.

Childs: There are a lot of great new technologies and there are a lot of great new techniques, but when I talk to customers, they're underfunded and under-resourced. They're under pressure, so they're trying to do more with less. It doesn't matter how many new things we come up with, because to them that's just a new thing they have to deploy. The reality on the ground is that it's still kind of frightening in some ways, with people just being unpatched for months and months and months at a time.

One thing we have heard is that for the struggles happening in IT environments, industrial control systems (ICS) and operational technology are struggling even more. Based on what you've seen on the ground floor, how much are industrial and critical settings lagging compared with traditional IT environments from a posture standpoint?

Childs: Quite frankly, it's probably years behind what we're seeing in the more mature verticals of enterprise software like Microsoft, Apple, Adobe and those sorts of things. I go back to what we saw at Pwn2Own in Miami -- that's our ICS-flavored Pwn2Own. And the types of bugs that were used there were the types of bugs that we were seeing in enterprise software years ago.

That sort of development is coming to the IoT and ICS world, but it's developing slowly. They're used to doing things at a very slow pace, whereas the rest of the industry is used to moving a lot faster. Take their customers. When [aluminum manufacturer] Alcoa buys a truck, they buy a truck for 25 years minimum. That mentality is there, but it doesn't work for software. You can't buy software for 25 years at a time, but that's what customers want to do because that's what their world is.

Gorenc: I think the other interesting thing about the ICS space is that they take a different approach to vulnerability disclosure than, say, Microsoft or cloud technologies. They focus on actually deploying out the patches to their customers or their integrators before any public disclosure actually happens. We get a lot of vulnerabilities through ICS programs that are super late for public disclosure, but the patch has been out there for a significant amount of time. Some users who are not on the relevant contact list may not get those bug disclosures, and if the patch is out there, [threat actors] can reverse-engineer the patch.

Last fall, Dustin, we were talking about bug bounty programs and researcher criticisms about lowball payments, not being credited, silent patching and so on. Have you noticed if these issues have had an impact or if the conversation has shifted in any way? Or are we still on the same issues?

Childs: I don't know that it's impacted our program very much. There are always times where you have disagreements between programs and researchers, no matter how altruistic a program is. Sometimes it's just a difference of opinion, so you're going to run into those cases. And we do have that; we don't have it happen very often, but sometimes it does happen. I see more folks having that conversation online where they're -- and I don't know the details of it, so I don't want to cast any stones -- but it's definitely people having a disagreement. People had a difference of opinion somehow, and someone's feelings were hurt. It seems like it's happening more and more often, especially when it comes to the bug bounty platforms.

Gorenc: We're in a little bit of a different position because we're not being paid by the vendors to run their bounty programs, whereas the platform companies are being paid. There's a different incentive model for them than there is for us. When we get a vulnerability, we have an agreement with the researcher that the vulnerability exists. And when we go to the vendor, if there's a disagreement, we have a vested interest in ensuring that those bugs are actually patched and released. We're not being paid to run it -- we're just buying the best stuff that we could possibly buy off the marketplace and working to resolve it.

Brian, how long have you been running ZDI?

Gorenc: I've been running ZDI for about a decade now. It's been good to see a lot of different changes in the industry as it relates to the disclosure process and researchers. That's one of my favorite parts of the job, to be honest.

We kind of bucket communication toward the researcher base and the vendor community, so we kind of have two different things there. Our approach to researchers is just to be open to them about what's going on. We make sure that we price well, that we pay well and that we pay quickly. That's a big thing for researchers. A lot of the vendor bug bounty programs will pay after the bug is fixed, and sometimes that can be six months. It's still common to this day that bugs don't get patched for four to six months. Over the years, we've been able to build a very strong research community that provides us very, very high-quality bug reports. And the signal-to-noise ratio for our program is significantly better than I think most programs out there.

Where do you still see the biggest room for improvement, generally speaking, in terms of communication between researchers and vendors?

Gorenc: I still think the room for improvement is better and more rapid communication. There are a lot of big vendors now that have automated a lot of the communication away behind automatic emails and automatic updates. I think it's better to have more of that face-to-face kind of communication that's not so automated, and I'd like to see that change. With some companies, you never really seem to talk to the actual person behind the email. You're talking to some system. It's about having that personal touch, and that's how we typically do it. It's a little bit more of a personal touch with the researchers and making sure that they feel the value of the program.

Childs: That's the thing I would say. The biggest change is, especially with the vendors, they're moving more toward an API-driven vulnerability reporting model, so they're really taking the person out of it. And a lot of this is based on interpersonal relationships; there is trust, and it has to go both ways. You have to trust the vendor with your research, and they have to trust you that you're going to obey them. And it's hard to build up that trust with an API. If you're just talking to a CRM someplace in the cloud, then it's really hard to get that trust built.

I know why vendors want to do automated vulnerability reporting -- it does end up being more efficient, and in a lot of ways, it does end up being cheaper. But I really think we need to look at what we are doing, and whether that push for automation has really served us or if we are in a worse place than we were before.

Editor's note: This interview was edited for clarity and length.

Alexander Culafi is a writer, journalist and podcaster based in Boston.