runZero Loves Open Source: Integrating Nuclei

If you know one thing about me, it’s that I’m an interminable weird fiction fan. But if you know two things about me, it’s that I also absolutely adore open source security research and software. I’ve basically pinned my entire career on giving away attack and defense tools and techniques for free, and today, I wanted to tell y’all about the next cool open source thing to come out of runZero: first-order-integration with the popular and easy-to-use Nuclei vulnerability scanner from Project Discovery.

This week, runZero shipped the first phase of this integration with support for default login checks across the web interfaces of IoT, OT, IT, and DevOps applications. Worried about default credentials in your Tomcat, Jenkins, SolarWinds, Ruckus, Siemens Simatic, or BMCs like iDRAC and Supermicro IPMI? We got you.

A Note on Safety #

“But I use runZero BECAUSE it’s so safe and sensible and polite about scanning,” you might cry out. You may be worried about the prospect of running some anonymous dude’s vuln check and ending up crashing out your printer (or your factory floor). Believe me, I get it. This is precisely why we’ve spent months poring over the Nuclei codebase (conveniently also written in Go, just like runZero’s platform), inspected thousands of templates, and figured out how to offer this feature in the most gentle and thoughtful way possible. To that end, we’ve selected a set of about 180 Nuclei templates for inclusion in runZero, nearly all of which are focused on default and weak credential use within web interfaces of various sorts.

All of these templates have been carefully reviewed, with our own human hacker eyes, to make absolutely sure that they’re safe and non-disruptive; and even then, we make sure that we’re only firing these templates at the right endpoints, thanks to runZero’s fantastic fingerprinting. For example, if we run across a slow and fragile embedded device, we’re not going to flood it with authentication requests for Apache Tomcat. Likewise, if we can’t positively identify the service and match it to the rules embedded in the template, the template will not run. This prevents runZero from impacting fragile ICS and IoT endpoints that react poorly to sudden incursions. So, we won’t fire those kinds of things off all willy-nilly ¹.

Bonus: Speed #

All of this safety has another benefit: speed. The fewer irrelevant checks we run, the faster the entire scan completes, with less impact on the network. In many cases, enabling default login checks does not noticeably increase scan time. Speed is a crucial factor in security response — if you can’t immediately identify every instance of a serious vulnerability, you risk an attacker doing so first. We’re excited to combine retroactive and instant query-based vulnerability detection with active checks that confirm whether a vulnerability remains after remediation.

Getting Started #

Today, none of these Nuclei templates will run in your environment by default, mainly in order to avoid surprises for our existing users. So, if you’d like to kick the tires on this, you are cordially invited to opt in, put your Power User boots on, and get down in the weeds in the Probes and SNMP tab. Scroll down (or use Control+F/Cmd+F and search for "vscan") until you find the "vscan" probe. This probe is enabled by default, but it will not do anything unless the "vscan-enabled" option has the exact value of "true". Even then, it will not run any checks unless you opt in to the specific category. These two categories available today are vscan-scope-default-login-http — which does what it says on the tin and checks various web services for weak and default credentials — and vscan-scope-admin-panel-http, which only has one approved template today, but will identify exposed administrative interfaces in the future.

One thing to note: even the default login check can cause temporary account lockouts. We discovered that newer versions of Apache Tomcat and many versions of CrushFTP temporarily lock out accounts after these templates run. That’s generally not a problem — the accounts tested shouldn’t be the ones you use to administer the system — but we don’t want anyone to be surprised. As we add support for other default login types (SSH, SMB, Telnet, etc.), we will clearly document the risk of account locking and do our best during the fingerprinting phase to avoid it wherever possible.

To recap the steps to enable this feature:

1. Create a new scan or modify an existing one.

2. Click on Probes and SNMP tab.

3. Hunt for the "vscan" probe near the end of the list.

4. Enter the value "true" for vscan-enabled, vscan-scope-default-login-http, and vscan-scope-admin-panel-http.

5. Optionally enable vscan-verbose if you’d like to see a detailed log of the logic.

6. Save and/or launch the new scan.

Your settings should look like the image below:

Once that’s done, you’ll start seeing a small amount of additional activity during runZero scans — not too much, since these are still precisely targeted. Any positive results (or negative as it relates to security) will be presented in the Vulnerability Inventory and be associated with the appropriate Finding.

The image below is an example of what these new checks look like in the Vulnerability Inventory:

It’s Just the Beginning #

This is our first (public) step in incorporating Nuclei templates, so please pardon the rough edges. Once we get some feedback from users in real environments, we expect to expand our support for:

• Rapid response coverage for emerging vulnerabilities in addition to actively exploited vulnerabilities on the CISA and VulnCheck KEVs

• Slightly more aggressive checks, tunable by safety rating, for deeper and more comprehensive scans of select systems (or at least the internet-facing ones)

• Default login checks across several more protocols, such as SSH, telnet, FTP, databases, and more common HTTP-based checks

• Common misconfigurations focusing on database exposures, administrative services and web management consoles, and accidentally accessible backups and secrets

• Unauthenticated application vulnerability checks against confirmed vulnerable targets

• Integrations with our SSHamble and excrypto open source projects

A bit further out, we hope to support customer-provided Nuclei templates (and template libraries), and more comprehensive remediation workflows from within runZero.

More importantly, we intend to contribute back to the wider Nuclei user community any cool stuff we (and you!) come up with. Check out our fork of the nuclei-templates repository at https://github.com/runZeroInc/nuclei-templates to see the kinds of things that we’re already fixing up for upstream use. The runzero-match: metadata section is how runZero’s per-asset-per-service fingerprinting logic is applied to each template.

Again, this is just the beginning. We’re excited to include new templates, new categories, and a ton of usability improvements in the near future.

So, if you’re ready to take the plunge, we’d love to hear from you about your experience with this nifty open source integration. If something doesn’t work the way you’d expect, our engineering team is ready to catch your support request, and if it ends up making Nuclei proper better, well, that’s just the neighborly thing to do. After all, the whole point of open source security research and development is to raise the bar for everyone, not just us and our customers. Finally, if you’re new to runZero and want to jump right into the deep end, we have a 21-day, fully-featured trial to get you started, as well as the free community edition where this is of course available as well.