Rapid Response: Bridge the gap and find vulnerabilities faster
Proactively check systems for weaknesses exploited in the wild and reduce your time-to-fix
The time between a critical exploit going public and a patch being released can leave you exposed for days. This might not sound long, but it’s more than enough time when it comes to the big-hitting CVSS 9.5-10.0 weaknesses.
Hackers are always looking for these exploits and scanning entire internet ranges for boxes to exploit. Within a week, they’re done exploiting and have already moved onto the next vulnerability. Wait too long and you could be too late to patch. Is the wait worth the risk? Close the gap with Rapid Response – a manual screening service that proactively scans for weaknesses when automated scanners don’t have checks available yet.
How does it work?
Our team continuously monitors security and news feeds for emerging critical risks. New information on these weaknesses is then used for manual scanning to discover hosts that could be vulnerable. This bridges the gap until our automated scanners have checks for these weaknesses, and uncovers more hosts where automated scanners can be less effective than manual detection.
Why is there a delay?
The process from CVE being published to scan is reactive by nature. It can take time for scanners like Tenable (one of the powerful scanners under the hood of Intruder) to analyze the weakness and write a robust plugin for detection. As soon as a plugin is created and released, we can run the relevant scans.
We call these Emerging Threat Scans (ETS), and as soon as we identify a new vulnerability that could critically affect your systems, we automatically kick-off a scan on all your external targets (license permitting). Regardless of the outcome, we'll notify you (in numerous ways) that an ETS has completed.
But there can still be a delay between the release of a new vulnerability and ETS scans in the Intruder portal. This is where Rapid Response comes in. Rapid Response goes above and beyond Emerging Threat Scans, because if there aren’t automated checks for highly critical, headline vulnerabilities yet, our team will run manual checks to check targets for the specific vulnerability. Rapid Response starts from the earliest possible information sources, kicking off before information about the vulnerability hits the mainstream media.
What happens next?
Where exposed servers are discovered, you’ll receive advisories with details and recommendations. This helps reduce your time-to-fix for the most serious weaknesses.
When attackers are alerted to emerging vulnerabilities, so are we, and we’re already checking your systems for them. Rapid Response focuses on weaknesses being exploited in the wild, where you have a small window of opportunity to act to reduce your risk before mass exploitation takes place.
Rapid Response in action
Intruder Head of Security, Dan Andrew, explains how Rapid Response has discovered critical weaknesses for customers…
ProxyNotShell was a resurgence of an earlier vulnerability in Microsoft Exchange servers (ProxyShell) that allowed a remote unauthenticated attacker to get remote code execution on Microsoft Exchange servers when combined with CVE-2022-41082.
What happened: this vulnerability affected the latest versions of Microsoft Exchange, and a full patch wasn’t available for over a month. Microsoft provided steps to help prevent exploitation before releasing a patch, but researchers produced new payloads which easily bypassed these mitigation steps. This continued for several days, with Microsoft changing their remedial advice daily, and researchers finding new ways to bypass their mitigations. It was very confusing for defenders - if they acted on the initial advice, but didn't follow up, they would still be vulnerable. Microsoft changed their mitigation advice every day, without warning! Rapid Response stepped in and advised customers with outdated mitigations or no mitigations at all on where they were vulnerable.
Why Rapid Response was required: there was no automated external check available when the weakness was first made public so detecting the vulnerability with Rapid Response was faster than using a scanner alone. Microsoft’s moving goalposts meant the Rapid Response team’s additional help and tracking of the weakness was essential to customers who don’t have time to read security news all day.
Impact of the vulnerability: Server-Side Request Forgery, leading to Remote Code Execution.
How we helped: Our team acted fast, writing first checks before the scanner had external checks available. Customers got additional value from updates around Microsoft's changing advice, making sure they were aware that patching advice was changing. After each update to Microsoft’s article, the Rapid Response team manually scanned and found servers which didn't have the latest mitigations in place and pointed them out to customers.
Fortinet FortiOS & FortiProxy, Remote Code Execution / Buffer Underflow (CVE-2023-25610)
What happened: this one was simple; a new vulnerability in Fortinet products was disclosed, and the scanner only had an internal (agent-based) check. The Rapid Response team stepped in to discover vulnerable hosts exposed to the internet in place of the scanner's lack of an external check for this weakness.
Why Rapid Response was required: not all customers have installed the internal (agent-based) scanner on all their targets, so Rapid Response adds an additional external check for hosts the scanner wouldn’t be able to detect. In practice, this means finding vulnerabilities which would remain undetected without Rapid Response.
Impact of the vulnerability: Remote Code Execution or Denial of Service
How we helped: the Rapid Response team ran manual scans for affected products, and pointed out external facing servers where the affected product was in use. This notification provided customers with a list of exposed targets to review for patching. Customers would not have been able to detect these with the scanner alone unless they were using internal scanning on all their targets (which many choose not to do). Rapid Response helped identify several critical weaknesses in Fortinet products over the past year – including CVE-2022-42475 and CVE-2022-40684.
5 reasons you need Rapid Response
- It’s not always practical to install an agent on everything - for example if you have thousands of targets - so you can’t scan for the vulnerability using an internal check
- Rapid Response is (usually) faster than the scanner alone. Faster means better for critical vulnerabilities, and the time from public disclosure to exploit is typically very low for vulnerabilities in the wild. But our scanner is fast, so we’ll see if it already checks for this issue, and Rapid Response will only kick in if or when it’s needed.
- Manual efforts can be more effective when the code is too generic or misses some edge cases. If so, we’ll write a more robust check to provide extra assurance.
- You can talk to our Security team and get advice on how to fix the issue.
- Our team can re-test the issue after it’s been fixed, or check mitigations you’ve put in place to give you the assurance you need.
Rapid Response: all you need to know
What is it?
Manual scanning to check for the latest critical weaknesses hitting the news, including some that our core scanners don't have checks for yet, or ones that are better detected by a human.
Why do you need it?
The delay between a critical exploit hitting the news and a patch being released can leave you exposed. Close the gap with manual screening that proactively scans for weaknesses when automated scanners don’t have checks ready.
How does it work?
We continuously monitor security threat feeds for emerging critical-risk vulnerabilities. When a threat is identified, we’ll scan your targets and identify any affected systems. If we think a target could be susceptible, we’ll notify you with details and advice.
What does it cover?
High risk weaknesses with a CVSS score of 9.5+, and weaknesses remotely exploitable over the internet.
Who’s it for?
Rapid Response is available to anyone with a Premium or Vanguard subscription.
- Raw CVE Coverage
- Risk Rating Coverage
- Remote Check Types
- Check Publication Lead Time
- Local/Authenticated vs Remote Check Prioritisation
- Software Vendor & Package Coverage
- Headline Vulnerabilities of 2021 Coverage
- Analysis Decisions
Red teamers, security researchers, detection engineers, threat actors have to actively research type of vulnerability, location in vulnerable software and build an associated exploit.
Tenable release checks for 47.43% of the CVEs they cover in this window, and Greenbone release 32.96%.
Red teamers, security researchers, detection engineers and threat actors now have access to some of the information they were previously having to hunt themselves, speeding up potential exploit creation.
Tenable release checks for 17.12% of the CVEs they cover in this window, and Greenbone release 17.69%.
The likelihood that exploitation in the wild is going to be happening is steadily increasing.
Tenable release checks for 10.9% of the CVEs they cover in this window, and Greenbone release 20.69%.
We’re starting to lose some of the benefit of rapid, automated vulnerability detection.
Tenable release checks for 9.58% of the CVEs they cover in this window, and Greenbone release 12.43%.
Any detection released a month after the details are publicly available is decreasing in value for me.
Tenable release checks for 14.97% of the CVEs they cover over a month after the CVE details have been published, and Greenbone release 16.23%.
With this information in mind, I wanted to check what is the delay for both Tenable and Greenbone to release a detection for their scanners. The following section will focus on vulnerabilities which:
- Have CVSSv2 rating of 10
- Are exploitable over the network
- Require no user interaction
These are the ones where an attacker can point their exploit code at your vulnerable system and gain unauthorised access.
We’ve seen previously that Tenable have remote checks for 643 critical vulnerabilities, and OpenVAS have remote checks for 450 critical vulnerabilities. Tenable release remote checks for critical vulnerabilities within 1 month of the details being made public 58.4% of the time, but Greenbone release their checks within 1 month 76.8% of the time. So, even though OpenVAS has fewer checks for those critical vulnerabilities, you are more likely to get them within 1 month of the details being made public. Let’s break that down further.
In Figure 10 we can see the absolute number of remote checks released on a given day after a CVE for a critical vulnerability has been published. What you can immediately see is that both Tenable and OpenVAS release the majority of their checks on or before the CVE details are made public; Tenable have released checks for 247 CVEs, and OpenVAS have released checks for 144 CVEs. Then since 2010 Tenable have remote released checks for 147 critical CVEs and OpenVAS 79 critical CVEs on the same day as the vulnerability details were published. The number of vulnerabilities then drops off across the first week and drops further after 1 week, as we would hope for in an efficient time-to-release scenario.
While raw numbers are good, Tenable have a larger number of checks available so it could be unfair to go on raw numbers alone. It’s potentially more important to understand the likelihood that OpenVAS or Tenable will release a check of a vulnerability on any given day after a CVE for a critical vulnerability is released. In Figure 11 we can see that Tenable release 61% their checks on or before the date that a CVE is published, and OpenVAS release a shade under 50% of their checks on or before the day that a CVE is published.
So, since 2010 Tenable has more frequently released their checks before or on the same day as the CVE details have been published for critical vulnerabilities. While Tenable is leading at this point, Greenbone’s community feed still gets a considerable percentage of their checks out on or before day 0.
I thought I’d go another step further and try and see if I could identify any trend in each organisations release delay, are they getting better year-on-year or are their releases getting later? In Figure 12 I’ve taken the mean delay for critical vulnerabilities per year and plotted them. The mean as a metric is particularly influenced by outliers in a data set, so I expected some wackiness and limited the mean to only checks released 180 days prior to a CVE being published and 31 days after a CVE being published. These seem to me like reasonable limits, as anything greater than 6 months prior to CVE details being released is potentially a quirk of the check details and anything after a 1-month delay is less important for us.
What can we take away from Figure 12?
- We can see that between 2011 and 2014 Greenbone’s release delay was better than that of Tenable, by between 5 and 10 days.
- In 2015 things reverse and for 3 years Tenable is considerably ahead of Greenbone by a matter of weeks.
- But, then in 2019 things get much closer and Greenbone seem to be releasing on average about a day earlier than Tenable.
- For both the trendline over an 11-year period is very close, with Tenable marginally beating Greenbone.
- We have yet to have any data for 2021 for OpenVAS checks for critical show-stopper CVEs.
With the larger number of checks, and still being able to release a greater percentage of their remote checks for critical vulnerabilities Tenable could win this category. However, the delay time from 2019 and 2020 going to OpenVAS, and the trend lines being so close, I am going to declare this one a tie. It’s a tie.
The takeaway from this is that both vendors are getting their checks out the majority of the time either before the CVE details are published or on the day the details are published. This is overwhelmingly positive for both scanning solutions. Over time both also appear to be releasing remote checks for critical vulnerabilities more quickly.