Unmanaged devices are the Achilles heel of any asset inventory. Shadow IT, rogue, or orphaned devices are easy targets for the adversary to gain potential footholds onto the network.

The obvious question is: which discovery approaches are the most effective at finding unmanaged devices?

Why are unmanaged assets harder to find?

First, we need to examine why unmanaged devices are so difficult to find. Let’s break it down:

• Shadow IT devices: DevOps teams spin up machines but without central governance. Many discovery approaches need inputs to know where to look. So knowledge of these devices does not propagate to the rest of the organization.
• Rogue devices: As the name suggests, someone intended for these devices to remain under the radar and evade standard discovery techniques. Otherwise, they would only have remained rogue for a short time.
• Orphaned devices: Many discovery approaches require tuning or fresh inputs to keep the inventory current. Without caretakers to ensure the necessary calibration, orphaned devices become unmanaged assets that fall out of the asset inventory if they were ever there in the first place.

What has been tried and failed

So what are the traditional approaches to finding assets, and why do they fall short?

Endpoint agent (or just “agent”)

This approach requires installing software on every device which gathers excellent detail. This method only works with managed IT assets. After all, the device is known and probably managed if you can install software on it. So this approach does not address the bane of asset inventory–unmanaged assets.

Authenticated scans

This active scanning methodology uses one or more scanners to log into every device that responds within an IP range. Once logged in (typically via SSH or WMI), the scanner gathers excellent detail about the device. Similar to the previous method, the device is known and probably managed if you already know the credentials to get on it. So, once again, this approach only really works with managed IT assets.

Passive network monitor

This technique deploys one or more appliances on a network to eavesdrop on network traffic, including chatter from unmanaged assets. The setup requires sending network traffic to the appliance(s) by either reconfiguring one or more switches to span or inserting one or more taps into the network. Where in the network you make these changes matters. Eavesdropping at a network “choke point” is ideal since it ensures visibility into all traffic. For all the work involved, you, unfortunately, get little detail. Suppose an asset rarely talks on the network or is terse. In that case, there’s little data to work with, leading to imprecise or inaccurate fingerprinting. As more devices encrypt traffic, the fingerprinting accuracy gets worse.

API import

Solutions that generate asset inventories from API imports do not discover assets independently. They rely on the rest of the security and IT stack to cobble together an inventory. Completeness and accuracy depend on data quality from those sources. API import solutions will miss unmanaged assets and produce vague fingerprinting.

Unauthenticated scans

This final approach uses one or more scanners to actively scan for information from every device within an IP range. Unlike authenticated scans, these scanners do not attempt to log in to machines. Unauthenticated scans can discover unmanaged assets, even without prior knowledge. Since it’s an active scan rather than a passive monitor, it can interrogate the devices to gather much more information for accurate fingerprinting. The one shortcoming of this approach lies with sensitive devices. These assets tend to be older or low-powered, often found in operational technology (OT) environments, and may be disrupted by aggressive scanning.

New reasons for an old problem

So which approach works best for unmanaged assets? First, it’s worthwhile to understand how this state of asset inventory came to be. There was a time when security just needed to protect the corporate office. Over the past 20 years, the following trends started or magnified, leading to a divergence of environments. In some cases, these environments teem with unmanaged assets. Others permit the deployment of unmanaged assets. Still, others allow assets to become unmanaged more easily.

• More IoT devices: Network-enabled cameras and smart speakers are recent phenomena.
• Convergence of IT and OT: OT networks have been overlaid onto IP networks to improve manageability and, in many cases, come under the purview of IT.
• Move to the cloud: Many organizations see the cloud as a transformational journey to lower cost and increase speed & agility.
• Rise of DevOps: Software development and operations teams have adopted a methodology of shared ownership, automation-at-scale, and rapid feedback resulting in dynamic attack surfaces, particularly in the cloud. Unfortunately, there isn’t always governance in this area.
• More M&As: Each year in the 2010s, there were more than 2x the large M&As than each year in the 2000s.¹ When you take on a new company, you take on all its unknowns and risks too.
• Work from home: Pressures around talent shortage gave rise to a growing WFH trend that compounded due to the pandemic.

Against this backdrop of divergence of environments, there has been a convergence of responsibilities onto security teams. During this same time, organizations have improved their security posture around managed IT assets in on-prem environments. Assets outside this scope have become more attractive targets.

What works

Given these challenges, let’s look at the approaches that will work the most effectively.

Start with unauthenticated scans

Unauthenticated scanning is the only possible starting point–inherent limitations in the other four disqualify them as options. If only we could use an unauthenticated active scanning approach that avoids disrupting sensitive devices.

Mix in a security research-based approach

The missing ingredient is to couple a well-designed scanner with a security research-based approach. Such a recipe conducts discovery from the perspective of the adversary, someone who actively avoids disrupting devices and leaving digital footprints during recon. The scanner must use properly-formatted packets, which ensures the best chance of “good” behavior from a device and allows tuning of scan parameters, including overall and per-host scan rate. Just as important, the scanner must fingerprint as it scans, adapting the scan behavior as it learns asset details.

Zero unmanaged assets

This unauthenticated scan and security research-based approach has proven practicable in thousands upon thousands of real-world networks distributed over various environments: IT, IoT, OT, cloud, and remote. St
art a runZero trial to see for yourself.

Get started with runZero in minutes

Do you know about the unmanaged assets on your network? Find them with runZero.

Get started

The OpenSSL project team recently patched two buffer overflow vulnerabilities that affect 3.0.0 through 3.0.6 releases of  OpenSSL. These vulnerabilities exist within X.509 certificate verification (specifically within name constraint checking logic) and affect both client and server side applications. Attackers can exploit these vulnerabilities to cause a denial-of-service by crashing applications/services (CVE-2022-3786, CVE-2022-3602) or potentially achieve remote code execution (CVE-2022-3602). The OpenSSL project team fixed these vulnerabilities in OpenSSL 3.0.7. OpenSSL 1.x versions do NOT contain these vulnerabilities.

Is runZero affected by these OpenSSL vulnerabilities?

The runZero platform does not use OpenSSL. The runZero operations team is ensuring that appropriate updates and mitigations are being rolled out to all of our supporting systems, including endpoints, infrastructure, and supporting services.

What are the details around these vulnerabilities?

The OpenSSL project team put together a thorough blog post that covers the details.

How to find vulnerable OpenSSL 3.0.x in your network

You can use runZero to discover vulnerable 3.0.x versions of OpenSSL in your environment. We shipped initial support for remote OpenSSL version detection in runZero version v3.2.6 on Sunday, October 30th, and scans run by our SaaS users after this time will report OpenSSL in the software inventory along with the version number when possible. Self-hosted users can enable this feature by applying the v3.2.6 (or later) update and rescanning their environment. In both cases, the runZero Explorer will be automatically upgraded as needed before the scan is launched.

After your scans complete, you can find assets running OpenSSL endpoints using the query: product:openssl. This query also works for the services and software inventory.

The server-side exposure only applies to services that process client certificates. This is not a common configuration, but runZero already performs checks for it. To identify services running OpenSSL 3.0.x variants that may be vulnerable to exploitation, use the query _service.product:"OpenSSL:OpenSSL:3" AND tls.requiresClientCertificate:"true" in the service inventory search.

The runZero scanner will reliably detect OpenSSL 3.0.x versions on any TLS-enabled ports identified during a normal scan. This includes both 3.0.x and 1.1.x OpenSSL versions when TLS-enabled service uses either TLS 1.2 or 1.3. The current fingerprints handle protocols that expose TLS directly. STARTTLS and additional service support are due in the near future.

What is the impact of these vulnerabilities?

The two issues are in the punycode parsing function used to process email addresses within certificates. Punycode is a way to transform a domain name using a non-ASCII character set into a standardized label. Punycode formatting can also convert emoji unicode characters into usable domain names. For example, ☃.net is encoded as xn--n3h.net.

Both client and server applications using OpenSSL 3.0.x include the vulnerability. Exploitation requires presenting a malicious certificate to the application. This only occurs after certificate validation, which is a mitigating control, in theory. Unfortunately, some applications disable certificate validation, either entirely (in insecure mode) or via a custom validator in the application.

To attack an exposed service:

1. An attacker would need to present a client-side certificate that triggers this issue, and
2. The server would need to have client certificate authentication enabled.

Even under these conditions, the client certificate would either need a valid signature or the application would need to be configured to skip validation. The number of applications that meet these requirements vary from organization to organization.runZero automatically checks for the use of both OpenSSL 3.0.x and client-side certificate support (tls.requiresClientCertificate) by default.

The client-side scenario may be harder to solve. Utilities like curl and wget, system update frameworks like apt and yum, and other client-side applications, may be impacted if they disable certificate validation. Some scripts may disable validation (e.g., using curl -k) to work around missing root certificates. The script can validate the hash of the received file, but still potentially exposes the script’s host to attack by a server presenting a malicious certificate with a punycode email address attribute.

Servers that make outbound calls to other HTTP endpoints (e.g., APIs and webhooks) also fall under this client-side scenario. Finding these embedded client-side instances are trickier, since every binary on every platform is suspect until proven otherwise. While many applications use the system library for OpenSSL, quite a few also statically link the library. These instances must be individually patched even if the system libraries are up-to-date.

How to respond

First things first: identify any externally exposed network services using OpenSSL 3.0.x that support client certificate authentication. This is the most likely scenario for remote exploitation today. runZero Enterprise customers can use our hosted scan engines to quickly scan their externally-facing assets.

Next, categorize internal services using OpenSSL 3.0.x and leverage existing software inventory capabilities (like the SentinelOne and Miradore integrations in runZero) to make a list of systems that use OpenSSL 3.0.x. Ensure that these systems are configured to receive frequent updates. Spot check that updates are applied once available.

Finally, identify third-party, statically-linked applications that might be using OpenSSL. There is great work happening with YARA rules that can help.

How to remediate

Thorough remediation of this vulnerability requires:

• Shifting all applications/services that use vulnerable OpenSSL 3.0.x software to OpenSSL 3.0.7.
• Deleting all files associated with vulnerable OpenSSL 3.0.x software, to ensure nothing attempts to use them.

You can accomplish the above by doing the following per asset:

• Update system and non-system OpenSSL 3.0.x libraries to 3.0.7.
• Update installed a
  pplications that are statically linked to (or are packaged with) a vulnerable OpenSSL version.
• Ensure older files associated with vulnerable OpenSSL 3.0.x versions are gone.

If your organization maintains applications or services which use OpenSSL:

• Rebuild applications/services that statically link to a vulnerable OpenSSL 3.0.x version to link with 3.0.7.
• Rebuild applications/services that repackage or specify a vulnerable OpenSSL 3.0.x version.

Software developers might also consider switching to a non-vulnerable TLS implementation, including the older OpenSSL 1.1.x branch, the LibreSSL project, or the BoringSSL project.

How to mitigate

If remediation in the near term is not an option, doing one of the following can help reduce your attack surface:

• Disable TLS client authentication for services using a vulnerable OpenSSL version that have it enabled.
• Stop running applications/services that use a vulnerable OpenSSL version (e.g., sshd, httpd, etc.).
• Use access control rules in your firewalls or routers to block access to ports associated with services that use a vulnerable OpenSSL version on affected assets.
• Disconnect from the network (or power down) devices that have services/applications/OSes using a vulnerable OpenSSL version.

Mitigation should be considered a temporary measure until remediation is possible.

How to stay on top of these vulnerabilities

Many individuals and organizations are compiling information on software affected by these OpenSSL vulnerabilities. See our Acknowledgements section below for links to those resources.

Acknowledgements

• Thanks to the OpenSSL team for all of their work, including the excellent blog post
• Thanks to SANS Internet Storm Center for reporting affected operating systems.
• Thanks to Royce Williams for his extensive lists of affected software.
• Thanks to National Cyber Security Centrum (NCSC-NL) for centralizing techniques to discover OpenSSL 3.0.x and affected/unaffected software lists.