SonicWall disclosed a vulnerability that affects SonicOS management access and SSLVPN software on SonicWall Gen 5, Gen 6, in addition to Gen 7 devices running SonicOS version 7.0.1-5035 or earlier.
CVE-2024-40766 is rated critical with CVSS score of 9.3, and potentially allows for unauthorized resource access by an attacker. There is limited evidence that this vulnerability is being exploited in the wild.
What is the impact?
Successful exploitation of this vulnerability potentially results in unauthorized resource access and in some cases could lead to a DoS after causing vulnerable devices to crash.
Are updates or workarounds available?
SonicWall recommends restricting management access to trusted sources or disabling WAN management from the public Internet. Additionally, SonicWall has released updated firmware and is available for download from mysonicwall.com.
How to find potentially vulnerable systems with runZero
From the Asset Inventory, use the following query to locate systems running potentially vulnerable software:
hw:"SonicWall" type:"Firewall"
About Version 2 Digital
Version 2 Digital is one of the most dynamic IT companies in Asia. The company distributes a wide range of IT products across various areas including cyber security, cloud, data protection, end points, infrastructures, system monitoring, storage, networking, business productivity and communication products.
Through an extensive network of channels, point of sales, resellers, and partnership companies, Version 2 offers quality products and services which are highly acclaimed in the market. Its customers cover a wide spectrum which include Global 1000 enterprises, regional listed companies, different vertical industries, public utilities, Government, a vast number of successful SMEs, and consumers in various Asian cities.
About runZero runZero, a network discovery and asset inventory solution, was founded in 2018 by HD Moore, the creator of Metasploit. HD envisioned a modern active discovery solution that could find and identify everything on a network–without credentials. As a security researcher and penetration tester, he often employed benign ways to get information leaks and piece them together to build device profiles. Eventually, this work led him to leverage applied research and the discovery techniques developed for security and penetration testing to create runZero.
One of the key components of runZero’s ability to provide asset discovery, exposure management, and attack surface management data is its ability to identify an asset’s operating system (OS), hardware, and services aka fingerprinting. This is often performed with very little or even conflicting data.
In this blog, we explore commonly used fingerprinting techniques and gain insights from the runZero Research Team on their approach to deciphering a real-world fingerprinting challenge. Let’s go!
Fingerprinting concepts
For the purposes of this blog, “fingerprinting” is defined as the process of trying to identify, with as much precision as possible, some aspect of an asset. There can be significant variation in the precision that can be achieved when fingerprinting. With certain data we may be able to identify the operating system and exact build number. With different data, it may only be possible to vaguely bucket the asset into an OS family such as “Windows” or “Linux.” For services we can sometimes even determine the programming language it was written in and perhaps a range of language versions that may have been used. All outcomes can be possible against the same asset depending on which protocols and services we can observe.
Fingerprinting techniques generally fall into one of three categories:
An example of self identification based fingerprinting would be an SSH MOTD banner of “Red Hat Enterprise Linux Server release 5.11 (Tikanga)”. That is pretty straightforward and doesn’t require any additional data. Attribute based fingerprinting, which we will discuss further in the next sections, includes looking at various response and data attributes such as TCP field values such as MSS or Window Scale. Behavior based techniques typically take more work to find and implement. An example would be when a particular OS or service implementation drops a TCP connection only when sent a certain payload at a particular stage in protocol negotiation.
Identifying the OS of a network-connected system, without credentials, and with minimal services, has always been a game of precision. Some of the trickiest examples are the forks of the Red Hat Enterprise Linux (RHEL) distribution.
CentOS and certain other Linux distributions such as Oracle Linux were originally forks or “bug and binary compatible” redistributions of Red Hat Enterprise Linux. The relationship changed in 2021 when Red Hat, which acquired CentOS in 2014, discontinued CentOS Linux and created CentOS Stream. With this change CentOS would no longer be downstream of RHEL but would instead be the upstream source from which RHEL is created. The logical flow has since changed again and now has Fedora as the root with both CentOS Stream and RHEL downstream. In response to CentOS Linux being discontinued two new distributions were created: AlmaLinux OS and Rocky Linux.
Often, the only real difference between these distributions is the replacement of Red Hat trademarks and branding with that of the particular Linux project. In many cases, these distributions are byte-for-byte identical at the software package and network levels. These present a challenge to remote fingerprinting as a result.
To overcome these challenges, we collect and analyze enormous amounts of data. Our first pass at trying to differentiate the RHEL derivatives used a combination of two attributes, such as SSH version negotiation strings and the TCP Receive Window size. Over time, we realized this wasn’t going to be sufficient and that we needed more and better data.
Analyzing data at scale is useful, but in situations like this it is vital to know exactly what combination of distribution and version leads to what results. For this effort we built hundreds of virtual machines running as many versions of the different distributions as we could. In some cases, these releases were over two decades old!
From each of these virtual machines we collected as much information as we could about how the TCP stack communicated. While it is true that fingerprinting an operating system via TCP stack quirks has been a thing for years, our challenge was to improve our detection while sending the absolute minimum amount of traffic and, importantly, to look for evidence that would persist through common configuration changes by the system administrators.
To explain our findings, we first need to define some terms:
TCP Receive Window: Maximum amount of data that a particular endpoint can receive and buffer. The sending host has to stop after sending the maximum amount of data and wait for ACK and window updates.
MTU: Maximum Transmission Unit, which is the largest packet that the network interface can accept.
MSS: Maximum Segment Size, which is the maximum amount of TCP data that can fit into a single packet, calculated as the MTU minus the protocol headers.
TCP Window Scale: An optional factor by which the TCP Receive Window is scaled; this allows receive windows to exceed the maximum of 65535 bytes that can be specified in the TCP Receive Window field.
Of the TCP attributes that we observed, the one that provided the murkiest fingerprinting results was the TCP Window Scale. The values for it, when present, range from 0 to 14. With this information, we can usually determine if the target is running a general family of operating systems.
FIGURE 1– TCP Window Scale by operating system.
Combining the TCP Receive Window and MSS offered the next significant improvement. In our past work, leveraging the Receive Window size sometimes yielded values that seemed to change unexpectedly. The reason why became clear when we looked at the data from the lab.
The key points were:
Changes to the link-layer MTU impacts the value of MSS, since MSS is calculated as the MTU minus the size of certain TCP/IP headers.
MSS is different between IPv6 and IPv4 due to the IPv6 IP headers being 20 bytes larger.
For Linux-based systems, Receive Windows less than the maximum value were almost always an even multiple of MSS. Due to the MSS difference mentioned above this means that the Receive Windows would vary as well.
Critically, the MSS multiplier for Linux-based OSs correlated with the Linux kernel version.
With the information above in hand, we can organize Linux systems into specific kernel version buckets based on the observed multiplier. That is quite a bit of information from the response to a single SYN packet!
FIGURE 2 – Relationship between IPv4/IPv6 MSS Multiplier and Linux Kernel version.
The kernel version also offers a hint as to the relative age of the system. A MSS multiplier of 4 indicates that the machine is likely running an ancient version of Linux, far beyond EOL, and certainly not something that should still be in production.
TCP-based fingerprinting by itself doesn’t improve fingerprinting of RHEL derivatives as much as we’d like. Since most of the systems in our analysis had SSH running, we looked for patterns in RHEL-derivative type and version in the light of SSH version negotiation advertisements (for example, SSH-2.0-OpenSSH_8.7) combined with the Linux kernel version. This strategy quickly yielded results. We found that we could generally identify the distribution’s major version, and in some cases, minor version range as well.
The screenshots below demonstrate how specific patterns pop out under bulk analysis.
FIGURE 3 – Relationship between different Enterprise Linux distribution versions and various network attributes.
As we can see in this screenshot, by combining SSH version advertisement and various measured TCP attributes, it is possible to narrow the Linux distribution involved, sometimes down to individual point releases. Even when it is not possible to precisely determine the version, it is almost always possible to determine if the distribution in question is derived from RHEL.
FIGURE 4 – runZero detecting operating systems derived from Red Hat Enterprise Linux.
While determining which RHEL-based distribution an asset is running from just SSH remains unsolved, the work involved resulted in greatly improving the ability to assert the OS family, major version, and sometimes minor versions of the OS. This provides customers insight into the state of their asset fleet as well as the age, support, and end of life status of these assets. The same techniques also allow us to fingerprint other operating systems, such as OpenBSD, down to the specific release version.
Precise fingerprinting is the foundation for delivering actionable asset discovery, exposure management, and attack surface management data to any type of organization. The runZero Research Team’s process behind precise fingerprinting enables security and IT teams to better understand where and when to take action against potential threats in their environments.
Want to learn more about runZero’s unique research on the state of asset security? Check out the runZero Research Report for a deeper look into the drivers behind CAASM.
About Version 2 Digital
Version 2 Digital is one of the most dynamic IT companies in Asia. The company distributes a wide range of IT products across various areas including cyber security, cloud, data protection, end points, infrastructures, system monitoring, storage, networking, business productivity and communication products.
Through an extensive network of channels, point of sales, resellers, and partnership companies, Version 2 offers quality products and services which are highly acclaimed in the market. Its customers cover a wide spectrum which include Global 1000 enterprises, regional listed companies, different vertical industries, public utilities, Government, a vast number of successful SMEs, and consumers in various Asian cities.
About runZero runZero, a network discovery and asset inventory solution, was founded in 2018 by HD Moore, the creator of Metasploit. HD envisioned a modern active discovery solution that could find and identify everything on a network–without credentials. As a security researcher and penetration tester, he often employed benign ways to get information leaks and piece them together to build device profiles. Eventually, this work led him to leverage applied research and the discovery techniques developed for security and penetration testing to create runZero.
The Secure Shell (SSH) protocol is an encrypted network protocol used to access an interactive shell and perform file transfers between systems over untrusted networks. SSH is the de facto management protocol for non-Windows machines (and even some Windows systems), replacing the Telnet protocol from days past.
The most recent version of the protocol, SSH-2, was standardized in 2006 and provides a high level of security when configured correctly. runZero analyzed aspects of SSH in the ecosystem to explore how SSH is being deployed in the real world.
My voice is my passport. Verify me.
The Secure Shell protocol consists of three phases. First, a secure transport is negotiated, similar to TLS. After the transport key negotiation is complete, the client attempts to authenticate, specifying one of a handful of known methods, and the server replies indicating whether the authentication succeeded and what remaining authentication methods are available if not. Finally, after successful authentication, a session is opened. This session enables access to channels, which in turn provide interactive shells, port forwarding, agent forwarding, and file transfer capabilities, among other options.
The three most common authentication mechanisms are:
Of the three mechanisms, publickey is by far the most secure and considered best practice. This type of authentication also supports key certificates, which provide even stronger security for key issuance and revocation. In publickey authentication, a user’s public key is stored in their profile on the destination system and only someone with the corresponding private key can authenticate. This prevents compromise through password-guessing attacks.
FIGURE 1 – A partial screenshot of runZero showing the results of an SSH scan.
In our survey of SSH endpoints, 54% support both password and publickey authentication. This is the default for many modern SSH services, and allows the optional use of a strong public key while allowing for the ease of password setup. In general, best practices recommend that the password mechanism be used only to set up public key authentication, after which it should be disabled. Leaving password authentication enabled exposes systems to password enumeration attacks and the potential for weak passwords set by users.
Password authentication is more common on storage and networking devices, where accounts are less likely to be associated with individual persons. Often, though, these systems still support publickey authentication, which should always be preferred over password authentication where possible.
Looking at the big picture, 95% of SSH endpoints offer publickey authentication. Whether these systems are configured to use it is another question entirely. What is perhaps somewhat disheartening is that, while 95% of endpoints support the most secure mechanism, approximately 92% still support some form of password authentication as well.
FIGURE 2 – Distribution of SSH authentication method combinations.
Dupes and Duplicity
SSH servers identify themselves by way of an SSH host key pair. Just as key pairs allow users to prove their identity, so too do host keys allow servers to prove their identity to users. Or at least prove their possession of the correct key.
This functionality is critically important. Without it, users could be tricked into thinking that they had logged into a totally different, possibly spoofed or malicious, system, with obvious security ramifications. However, unlike TLS, most SSH servers are not configured to use any form of Public Key Infrastructure (PKI) or other chain-of-trust to establish proof of server identity. Such functionality is available, but is not in widespread use.
Instead, most SSH clients will use a technique called Trust on First Use (TOFU). In this scheme, the client will trust a host key the first time it receives it for a given host. Going forward, if the host key changes, the SSH client can alert the user to the problem. While this doesn’t allow the user to confirm the host’s identity, it at least allows them to confirm that the host’s identity hasn’t changed.
ubuntu@u2404-infra-02: ̃$ ssh 192.168.50.127
The authenticity of host ‘192.168.50.127(192.168.50.127)’ can’t be established.
ED25519 key fingerprint is SHA256:wdNLQA-2vyp6Qv+8T7Ac2rF6vRJz34P5RCQo9VJAa+Ms.
This key is not known by any other names.
Are you sure you want to continue connecting
(yes/no/[fingerprint])? █
While host keys are ostensibly used to uniquely identify a host, oftentimes multiple hosts have the same host key. This is sometimes intentional, such as when automatically provisioning many ephemeral systems. Unfortunately, it can also happen accidentally, such as during virtual machine image cloning, and this can have very undesirable consequences since it undermines the concept of key trust.
We performed a limited audit to see how frequently host keys were being reused across our data set. We identified more than 350 instances where the same host key was shared across unrelated environments. Further exploration across the wider Internet revealed thousands of additional shared host keys. These are often the result of a vendor generating keys as part of an operating system (OS) image instead of regenerating them when the OS first boots or is provisioned for the customer. In the case of publicly available VM images or hardware, malicious actors could collect the key pairs from the images and use them in attacks. The real world impact would be that malicious actors with certain network access could perform spoofing or meddler-in-the-middle attacks to force users or automation to interact with them instead of the intended targets.
FIGURE 3 – Reuse of individual keys across our data set by device type.
Auditing SSH key reuse
runZero scans attempt to collect information for all SSH key types. This allows our customers to audit the keys types in use as well as how the specific keys are used across their environments.
FIGURE 4 – A partial screenshot of runZero showing the SSH key information collected.
runZero has a Service attributes report that can help our customers audit key reuse. There are two ways to access this report. The first way is to go to the Reports section and run the Service attributes report for a specific key field. We recommend using the sha256 hash for the key type. For example, in the case of RSA keys the service attribute ssh.hostKeyRSA.sha256.
FIGURE 5 – A partial screenshot of runZero showing how to launch the Service attributes report.
FIGURE 6 – A partial screenshot of runZero showing the output of the Service attribute report for ssh.hostKeyRSA.sha256.
Customers can then click on the key hash on the left to see where it is used. This is a Service report so it is important to keep in mind that the same key may be seen across multiple services or addresses on the same asset.
The second way to view the report is by viewing the SSH service on an asset and clicking the magnifying glass next to the attribute name (green square in Figure 7). This will take customers directly to the report.
FIGURE 7 – A partial screenshot of runZero showing the attribute name and value.
Clicking on the magnifying glass next to the value (blue square in Figure 7) will show every place that this particular key is used.
Remember to download the runZero Research Report to learn more about the state of asset security.
About Version 2 Digital
Version 2 Digital is one of the most dynamic IT companies in Asia. The company distributes a wide range of IT products across various areas including cyber security, cloud, data protection, end points, infrastructures, system monitoring, storage, networking, business productivity and communication products.
Through an extensive network of channels, point of sales, resellers, and partnership companies, Version 2 offers quality products and services which are highly acclaimed in the market. Its customers cover a wide spectrum which include Global 1000 enterprises, regional listed companies, different vertical industries, public utilities, Government, a vast number of successful SMEs, and consumers in various Asian cities.
About runZero runZero, a network discovery and asset inventory solution, was founded in 2018 by HD Moore, the creator of Metasploit. HD envisioned a modern active discovery solution that could find and identify everything on a network–without credentials. As a security researcher and penetration tester, he often employed benign ways to get information leaks and piece them together to build device profiles. Eventually, this work led him to leverage applied research and the discovery techniques developed for security and penetration testing to create runZero.
The 2024 SC Media Awards Honor Companies Offering Cutting-Edge Products and Services Across Many Areas of Cybersecurity
AUSTIN, TEXAS — August 30, 2024 — runZero, a leading provider of Cyber Asset Attack Surface Management (CAASM) and top rated on Gartner Peer Insights, today announced that the company has been recognized as an Excellence Award Finalist in the Most Promising Early-Stage Startup category for the 2024 SC Awards. This announcement was made on Thursday, August 29, 2024, as part of SC Media’s 2024 SC Awards coverage.
Celebrating its 27th year, the SC Awards recognize the solutions, organizations, and individuals that have demonstrated exceptional achievement in advancing the security of information security. This year, the SC Awards received a remarkable number of entries across 34 specialty categories, with many notable companies earning nominations for their leadership and commitment to cybersecurity.
The SC Awards were evaluated by a distinguished panel of judges, including cybersecurity professionals, industry leaders, and members of the CyberRisk Alliance community from sectors such as healthcare, financial services, education, and technology.
“The finalists for the 2024 SC Awards truly represent the forefront of cybersecurity innovation and leadership,” said Tom Spring, Editorial Director at SC Media. “These solutions, organizations, and professionals have demonstrated outstanding capabilities in addressing today’s complex and ever-changing threat landscape. We are proud to recognize their contributions to the cybersecurity community.”
Many CAASM solutions in the market rely heavily on integrations to inventory assets, leading to incomplete visibility into unknown and unmanaged assets, while others focus solely on IT devices, lacking coverage for OT and IoT assets. The runZero Platform combines powerful proprietary active scanning and native passive discovery with integrations to overcome these limitations, providing a comprehensive, unified solution that delivers complete visibility and accurate, in-depth fingerprinting for all IT, OT, and IoT devices across on-prem, cloud, and remote environments.
“We are honored to be recognized by SC Media for our unique approach to CAASM and exposure management,” said Julie Albright, chief operating officer at runZero. “This nomination speaks volumes to our commitment to helping organizations address the urgent cybersecurity challenge of improving visibility into managed and unmanaged assets with a solution that is easy to implement and produces results immediately.”
Over the coming week, the SC Media editorial team will provide in-depth coverage of runZero, including a featured profile on the SC Media website and promotion across their social media. Winners of the 2024 SC Awards will be announced on September 17, 2024.
About CyberRisk Alliance
CyberRisk Alliance provides business intelligence that helps the cybersecurity ecosystem connect, share knowledge, accelerate careers, and make smarter and faster decisions. Through our trusted information brands, network of experts, and more than 250 innovative annual events we provide cybersecurity professionals with actionable insights and act as a powerful extension of cybersecurity marketing teams. Our brands include SC Media, the Official Cybersecurity Summits, Security Weekly, InfoSec World, Identiverse, CyberRisk Collaborative, ChannelE2E, MSSP Alert, LaunchTech Communications and TECHEXPO Top Secret.
Version 2 Digital is one of the most dynamic IT companies in Asia. The company distributes a wide range of IT products across various areas including cyber security, cloud, data protection, end points, infrastructures, system monitoring, storage, networking, business productivity and communication products.
Through an extensive network of channels, point of sales, resellers, and partnership companies, Version 2 offers quality products and services which are highly acclaimed in the market. Its customers cover a wide spectrum which include Global 1000 enterprises, regional listed companies, different vertical industries, public utilities, Government, a vast number of successful SMEs, and consumers in various Asian cities.
About runZero runZero, a network discovery and asset inventory solution, was founded in 2018 by HD Moore, the creator of Metasploit. HD envisioned a modern active discovery solution that could find and identify everything on a network–without credentials. As a security researcher and penetration tester, he often employed benign ways to get information leaks and piece them together to build device profiles. Eventually, this work led him to leverage applied research and the discovery techniques developed for security and penetration testing to create runZero.
Make new friends, but keep the old: one is silver, the other gold.
Despite enormous advances within information technology, security practitioners are still plagued by common problems. Advances in cybersecurity defenses and overall security awareness are helpful, but organizations still struggle with end-of-life (EOL) assets scattered across the attack surface. This can be a surprisingly difficult problem to solve and, most importantly, from the attacker’s perspective, EOL assets still provide easy footholds into an environment.
End-of-life is not the end
All of the system hardening and security patches in the world cannot protect a system that is not updated to use those features. System vendors generally provide patches and updates for a limited timespan. After that point, end users must invest in an upgrade to a newer version of the system or fend for themselves and hope for the best with an EOL, outdated asset lurking on the attack surface.
EOLed systems often stick around for years, mostly forgotten but still part of an organization’s infrastructure and, therefore, its attack surface. New vulnerabilities are still discovered and exploited in these outdated systems as the April 2024 D-Link NAS issue illustrated. Despite the known exposure, being EOL means that fixes will not be forthcoming.
While this may seem like an academic exercise, EOLed systems are surprisingly common. Our findings show many still-active EOLed operating systems in various environments.
Operating system end-of-life
Operating systems typically have multiple phases of vendor support, referred to as a support lifecycle. The duration of the lifecycle and services provided in various stages vary from vendor to vendor, usually tapering off with fewer updates and patches in later stages.
The two phases we are most concerned with are:
Mainstream support during which vendors release patches that may add new features, fix bugs, or mitigate security vulnerabilities.
Extended support during which only critical bugs and vulnerabilities are addressed.
While some vendors’ terminology and phases may slightly differ, generally speaking, most support lifecycles can be broadly mapped to these two phases.
When a vendor stops providing upgrades for non-critical issues, the product is considered in an “End-of- Life” (EOL) status. There may be an additional period known as “Extended-End-of-Life” (EEOL) during which the vendor continues to provide updates for critical issues. EOL and EEOL can happen concurrently or separately depending on the system and the vendor. Most importantly, after EOL, systems no longer receive critical updates or security patches, and thus become much greater risks to keep around.
But around they are! Systems have a long tail: if they still work, replacing them with a supported alternative may be more trouble than it’s worth. In some cases, the responsible staff can’t or won’t; in others, the system may host critical functions that are not supported on newer systems. Uptime guarantees and financial considerations may also play a role.
When we look at our sample data for operating systems that are past their extended EOL dates, we see that chart toppers are a pretty even split between Windows and various Linux distributions:
FIGURE 1– Top OS past extended EOL.
The presence of Ubuntu 18.04 isn’t surprising as it only reached Extended EOL just over a year ago in June of 2023. Ubuntu is often a go-to Linux distribution for businesses and home users alike as well as very popular in cloud environments. Windows Server 2012 R2 is also unsurprising; it reached extended EOL only very recently, in October of 2023. While running an OS a year past extended EOL is unfortunate, it’s not unusual for server migrations to drag on past EOL dates due to logistical and compatibility concerns.
The next major group is composed of various Windows 10 releases that, were they combined, would dominate the chart at 21.55%. Most of these are running the Windows 10 21H2 which reached extended EOL very recently in June 2024. Windows 10 was originally released in July of 2015. Microsoft has generally released two major updates for it every year since. Typically, updates released in the first half of the year are supported for 18 months and those released in the second half are supported for 30 months. There are some variations on this theme, with Long-Term Servicing Channel (LTSC) editions, for example, having longer lifespans. Windows 10 22H2 is the final version of Windows 10 and will reach extended EOL in October 2025.
FIGURE 2 – Windows 10 past extended EOL.
Exposed systems past extended EOL
While operating systems outside of their extended lifespans are always worth looking into, those with exposure to an external attack surface are particularly worrisome. Of all systems exposed to an external attack surface and for which EOL data was available, 15.99% were past their extended EOL dates. That means that roughly 16% of all devices exposed to external attackers are probably not receiving security updates.
For server operating systems specifically, when we group them by family, we see that the largest block are Windows hosts. The percentage may be higher than expected based on Figure 1 above. This is due the long tail of various Windows Server versions going back to Server 2008 R2.
FIGURE 3 – Server operating systems with external attack surface exposure, past extended EOL.
Case study: the Boa web server
The Boa webserver is an open source web server designed to have low resource requirements for users and to be compatible with embedded applications. The last official release of the Boa webserver, version 0.94.14rc21, was in February of 2005. For comparison, the Colts have won a Super Bowl more recently than the latest release of the Boa web server, and the Colts haven’t won a Super Bowl since 2007!
There are known vulnerabilities in Boa that have been exploited in critical infrastructure in the past. For example, in November 2022, Microsoft disclosed that Boa web servers in Internet-of-Things (IoT) devices were a common attack vector against power grids in India.
While it is relatively easy for an administrator to determine if a server is running Boa, it is much harder to detect in an embedded device. Boa is common in embedded devices like security cameras and IP phones that are widely deployed in enterprise networks. Therefore, curating an accurate inventory of an organization’s embedded devices, not just servers, that are running Boa is critical for protecting these networks.
FIGURE 4 – Boa web server version distribution in runZero data.
Embedded devices running Boa
Network-attached camera
92.3%
Media & telephony devices
5.5%
Environmental control devices
0.9%
Network devices
0.9%
Industrial control devices
0.3%
FIGURE 5 – Device types still running Boa in sample runZero data.
New-Old Friends
We’d be remiss if we didn’t mention common operating systems that will reach extended EOL soon. If any of these operating systems are running in your environment, we strongly recommend that you start planning for replacement or mitigation sooner rather than later.
FIGURE 6 – Common OS approaching extended EOL.
Final Thought
The prevalence of EOL systems within organizational networks remains a significant security concern. Despite advancements in security technology and practices, these outdated assets continue to provide attackers with easy entry points. Addressing this issue requires a proactive approach to asset discovery, exposure mitigation, and vigilant attack surface management to ensure that all components of your network, regardless of age, are secure and up-to-date.
runZero customers can find assets that are past their extended EOL by using the Policy: Extended End-of-Life operating systems canned query. You may need to add the OS EOL Ext. column in the Asset inventory in order to view the value.
Don’t forget to download the runZero Research Report to learn more about the state of asset security.
About Version 2 Digital
Version 2 Digital is one of the most dynamic IT companies in Asia. The company distributes a wide range of IT products across various areas including cyber security, cloud, data protection, end points, infrastructures, system monitoring, storage, networking, business productivity and communication products.
Through an extensive network of channels, point of sales, resellers, and partnership companies, Version 2 offers quality products and services which are highly acclaimed in the market. Its customers cover a wide spectrum which include Global 1000 enterprises, regional listed companies, different vertical industries, public utilities, Government, a vast number of successful SMEs, and consumers in various Asian cities.
About runZero runZero, a network discovery and asset inventory solution, was founded in 2018 by HD Moore, the creator of Metasploit. HD envisioned a modern active discovery solution that could find and identify everything on a network–without credentials. As a security researcher and penetration tester, he often employed benign ways to get information leaks and piece them together to build device profiles. Eventually, this work led him to leverage applied research and the discovery techniques developed for security and penetration testing to create runZero.
