When you work with Qualys long enough, it’s inevitable that you’ll eventually find them: Zero-day vulnerabilities in software that’s several years old, with no patch available. There’s no easy answer about what to do with them, but here’s some advice for old Qualys zero-day vulnerabilities.
Zero-day vulnerabilities by definition have no vendor-supplied patch. Typically a vendor issues a patch a few days or weeks after a zero-day comes out, but there are a few zero-days from the 2007 timeframe that never got patches released, and those vulnerabilities require another type of mitigation.
Old Qualys zero-day vulnerabilities
The titles of these vulnerabilities look something like this: Word 2007 blah blah buffer overflow vulnerability – Zero Day. Many, if not most, apply to Ballmer-era Microsoft products like Windows Vista, Windows Server 2008, and Microsoft Office 2007.
The solution field tells you Microsoft has no patch available, and it directs you to load a Trend Micro virtual patch. This is a subset of two Trend Micro products, Deep Security for servers, or Vulnerability Protection for desktops. Load the Trend Micro product, and the vulnerability finding goes away in your Qualys scans.
But is that the best use of your security budget? We’re vulnerability analysts, right? Sometimes that means we have to analyze. I’m going to write in very general terms here but you can follow my formula to make a decision on what to do.
How I analyze the vulnerability
You have to analyze the vulnerability, and the product it’s attached to. Those are two separate things, but collectively they direct you to what you need to do. Don’t let the words zero day throw you into a panic.
Did you authenticate, and is the finding confirmed or potential?
First things first, make sure the scan authenticated. You need the results column to have usable data in it, and that requires authentication. Also check to see whether the finding is confirmed or potential. If it’s potential, first make sure the vulnerability is actually present. There’s no point in chasing the other solutions if the vulnerability turns out to be a ghost.
Look at the exploits
Do a Google search on the vulnerability’s CVE. You’ll turn up the original proof-of-concept exploit, in most cases. Look at the source code. Not a programmer? No problem, look at the comments. You’ll get a sense of what the original author thought of the vulnerability. How hard is it to do anything other than crash the service?
In most of these that I’ve analyzed, what I found was that the exploit could crash something, but it was difficult to get it to do more than just crash. Remember, an exploit is a controlled crash that lets you force an application or service to run other code as it goes down in flames. An exploit that’s too hard to control isn’t very useful.
Look at the CVSS score
CVSS is a horrible statistic, but it still has uses. CVSS is a measure of a vulnerability’s potential. I’m more interested in whether attackers are using the vulnerability than I am in CVSS score, but CVSS is more readily available, so we should go ahead and use it.
In many cases, these don’t rate a 7 on the 10-point scale. Many organizations only patch vulnerabilities with a CVSS score of 7 and higher. Yes, this leaves them open, but when you blindly demand that an organization patch everything, more often than not you end up with nothing. Fixing the 7s and above gives you a better chance of getting the highest-severity vulnerabilities fixed, plus some others since most patches fix multiple vulnerabilities.
I”m a lot more worried about a zero-day with a CVSS score of 9 than I am about one with a 6.8.
Do Qualys competitors look for the vulnerability?
Qualys doesn’t make its vulnerability database public, but Tenable and Rapid7 do. Search on the CVE plus the word Tenable, then search on the CVE plus the word Rapid7. In many cases, you’ll find they don’t even look for the vulnerability.
This isn’t an automatic disqualifier, but if two of the three leading vulnerability scanners don’t look for something, that’s a strong indicator you have bigger problems.
What does Kenna say?
If you have Kenna, pull up the vulnerability in Kenna and look at it. How many exploits exist, and how many malware strains use it? Kenna may say this old Qualys zero-day is a high severity, but that’s still a binary answer. Look at the counts versus something that’s patchable. What I frequently find is that these old zero-days have three or four exploits floating around and maybe a dozen malware strains using it. A typical high-severity vulnerability in Kenna shows dozens or hundreds of exploits, and thousands of malware strains using it.
If only a few are targeting the vulnerability, that suggests they aren’t getting a high degree of success with it.
Can the vulnerability be mitigated another way?
If it’s a buffer overflow, you can probably load EMET or Malwarebytes Anti-Exploit and gain a degree of protection. This will be cheaper than buying the Trent Micro product. Qualys won’t factor that in, but Qualys is a tool. It’s not a vulnerability analyst in a box, any more than a table saw is a carpenter in a box.
Sometimes the best thing we can do is mitigate the vulnerability, take it off the board for 12 months, concentrate on other things we can fix, then re-evaluate. Otherwise, more often than not, unpatchable vulnerabilities turn into an excuse to not patch anything.
Analyzing the product
The second thing to look at is the product itself. Maybe this vulnerability isn’t a huge deal in and of itself, but that doesn’t mean you just ignore it out of hand.
Is the product end of life?
Most of these vulnerabilities exist in products that no longer are under support. I’m more worried about the vulnerabilities in Office and Windows that got patched in 2018 for supported products but didn’t get patched in Windows XP and Vista and Server 2008 and Office 2007.
You need to run supported software wherever you can. Upgrade to a supported version of Windows or Office, and the vulnerability goes away.
How isolated is the product?
If the product is in use somewhere that it’s not taking data from the wild, it’s less risky than if you’re using it in your HR department. If a business-critical application exists that really does rely on an old Microsoft product, but it’s only being used for internal data processing, it may be worth accepting the risk. But it should be the business process owner signing off on the risk, not the CISO, and probably not the CIO either.
Is the Trend Micro product worth considering?
I think it’s overkill to buy an expensive product to fix a handful of old zero-days that attackers rarely use. But it could have other uses. Many companies have millions of unpatched vulnerabilities in their network and they can’t stop the bleeding because they don’t know where to start. If Trend Micro virtual patching is easier than deploying the vendor patches, it may be a good way to buy time while you get a handle on traditional patch management.
What I’ve found is that when you take the pressure off a bit, IT teams generally are willing to patch. But handing them a spreadsheet with two million lines in it and telling them to fix it is rarely effective. I put up with it early in my career, and I got very good at patching, but when a better offer came along, I left that high-pressure life and never looked back.
A better approach is to put mitigations in place, then deploy the new Microsoft and Adobe updates every month, along with 10 older updates. In an enterprise with 5,000 computers, you can close 100,000 vulnerabilities a month that way. Establish a discipline of pushing 10 older, non-superseded updates every month, and you may very well find in a couple of years you don’t need the Trend Micro product anymore. But in the meantime, it helps you stop the bleeding and get things moving.