Tenable’s Security Response Team takes a look back at the major vulnerability and cybersecurity news of 2020 to develop insight and guidance for defenders.

Søren Kierkegaard, the Danish philosopher, once wrote that “life can only be understood backwards” but “it must be lived forwards.” Tenable’s Security Response Team is tasked with looking at the threat landscape on a day-to-day basis and, while that provides us with the ability to see things in the moment, it’s only when we look back at the year that was that we can see the bigger picture.

As we were finalizing our inaugural 2020 Threat Landscape Report (TLR), the most notable cybersecurity event in 2020 — and arguably the last decade — was revealed in December. The breach of SolarWinds and its Orion Platform software captivated our collective attention in the final weeks of 2020. While the full picture of the breach and its impact remains incomplete, we believe that as additional information emerges throughout 2021, our ability to truly grasp the full effects and impact will be realized.

SolarWinds became the most significant event of 2020, but for the broader industry, there are many pressing matters to be addressed, such as the top 5 vulnerabilities exploited throughout 2020. These include three legacy vulnerabilities in virtual private network solutions from Citrix, Pulse Secure and Fortinet. These top 5 vulnerabilities, as well as other key takeaways and insights from the year in vulnerabilities, are outlined in the TLR, which security professionals can use to move forward in 2021 with a greater sense of clarity. 

The 2020 Threat Landscape Retrospective

The report begins with an overview of the vulnerability landscape. There were 18,358 new CVEs assigned in 2020, a six percent increase from 2019. From 2015 to 2020, the number of reported CVEs increased at an average annual percentage growth rate of 36.6%.

Source: National Vulnerability Database (NVD) as of January 5, 2021

While the numbers are daunting, they don’t really tell the full story. The TLR explores the nuances of vulnerabilities disclosed last year: noteworthy vulnerabilities, whether or not they were branded; zero-day disclosures from attackers and researchers; the whirlwind summer months and all of the challenges brought on by the COVID-19 pandemic.

Next, we explore the threat landscape in 2020. How were attackers leveraging the vulnerabilities disclosed in 2020, and several that were significantly older? Troublingly, the primary theme of the threat landscape was that threat actors are relying on unpatched vulnerabilities in their attacks. This isn’t anything new but this year, government agencies issued several advisories warning about attackers leveraging vulnerabilities that have patches available and yet remain unmitigated. The TLR explores key insights from these government alerts along with ransomware attacks and major breaches throughout the year.

Timeline of Notable Government Alerts in 2020

The final section of this report will likely be of particular use to security practitioners. It offers a digest of the key vulnerabilities in 2020 — the technical details, whether and how they’ve been exploited, all categorized by vendor or product. If you ever need to describe a vulnerability to a key stakeholder, this is your resource.

How to use Tenable’s 2020 Threat Landscape Retrospective report

• Understand some of the pitfalls from the shift to the remote workforce
• Learn how ransomware gangs are breaching organizations and the tactics they’re employing to extract ransom demands
• Learn some of the common ways data breaches occur and what your organization can do to prevent them from happening
• Identify and patch any of the vulnerabilities referenced in the report

Learn more

• Download the full report here
• Attend the webinar: Tenable Research 2020 Recap and Defender’s Guidance for 2021

Researchers identify seven vulnerabilities in popular Domain Name System software.

Background

On January 19, researchers from the JSOF Research labdisclosed seven vulnerabilities in dnsmasq, a widely used open-source application for network infrastructure. Dubbed “DNSpooq” by the JSOF team, the acronym is a play on words as the vulnerabilities allow for Domain Name System (DNS) spoofing. The JSOF team also released a detailed whitepaper with technical details around their research.

Image Source: JSOF

The vulnerabilities were discovered over the summer of 2020 and JSOF coordinated with the CERT Coordination Center (CERT/CC) and various other entities to alert vendors that implement dnsmasq within their own products and services.

While JSOF notes that over 40 vendors may be affected by these flaws, due to varying implementations, it is unclear which vendors may be impacted by these vulnerabilities or if they are impacted at all.

Analysis

The seven flaws that comprise of DNSpooq can be split into two categories of vulnerabilities: DNS cache poisoning and buffer overflow. While it is possible that the buffer overflow vulnerabilities can be used to gain remote code execution (RCE), the more likely scenario is a denial of service (DoS) condition when successfully exploited.

Poison the Well: DNS Cache Poisoning Attacks

The researchers identified the following three DNS Cache Poisoning vulnerabilities:

All three vulnerabilities are the result of DNS cache poisoning, a type of attack that could allow an attacker to inject a malicious DNS entry into the cache, which could be used to redirect network packets to a malicious server. This particular type of attack can be abused to re-route traffic including HTTP, SSH, remote desktop protocol and others.

Image Source: JSOF

The cache poisoning attacks are made possible by abusing a weak hash to reduce entropy. The transaction ID (TXID) and source port should be random and provide 32 bits of entropy, however JSOF found that the hashing algorithm used is not cryptographically secure and an attacker could abuse this to reduce the entropy significantly. When DNS Security Extensions (DNSSEC) is disabled, a custom CR32 algorithm is used for hashing.

The research outlines at least three potential scenarios in which an attacker could exploit the flaws. The first scenario outlines the potential to attack a dnsmasq resolver that has port 53 open to the internet. This would allow an attacker to send crafted DNS packets using a spoofed IP address and a registered domain name. JSOF believes “approximately 1 million vulnerable dnsmasq instances” are vulnerable according to a Shodan search.

The second and more likely scenario would be an attacker abusing the flaws from a machine an attacker controls within the local area network (LAN). While an attacker with access to a machine within a LAN can likely leverage other vulnerabilities more easily, this scenario could be exploited by an insider threat. The attacker could impact all devices connected to the LAN and redirect traffic to steal confidential or sensitive information.

The third and most complex scenario involves using malicious JavaScript to attempt to inject malicious DNS queries within the local LAN when a user on that same LAN browses an attacker-controlled website or a website with malicious advertisements. JSOF notes in their whitepaper that not all browsers allowed for this attack scenario, and there could be other mitigating factors on a network that would prevent this attack from being successful.

Over the Top: Buffer Overflow Flaws

The four remaining flaws in the table below are buffer overflow vulnerabilities:

CVE-2020-25681 and CVE-2020-25862, the two highest rated flaws earning an 8.1 CVSSv3 score, could be abused to achieve RCE. However, as is the case with the other CVEs listed in this advisory, the most likely scenario would be a DoS condition.

DNSSEC: When the Cure Becomes Worse Than The Disease

In a bit of irony, in order for a device to be affected by the four buffer overflow vulnerabilities, the DNSSEC feature must be enabled. Devices with DNSSEC disabled would NOT be affected by the buffer overflow flaws. However, JSOF notes it is important to enable DNSSEC as it is used to prevent cache poisoning attacks.

Chaining attacks to increase effectiveness

While the highest rated CVSS score is an 8.1 and the lowest being only a 4, JSOF notes that these vulnerabilities by themselves are low impact. However, chaining one or more of the vulnerabilities together can give an attacker a more robust attack with a much higher impact. While chained attack scenarios have become more common lately, it does highlight how important every component within a network can be. With DNS being a major backbone of the internet, these seven vulnerabilities highlight that common protocols and network software are a prime target for skilled threat actors.

Proof of concept

At the time this blog post was published, no proof-of-concept (PoC) code had been made available for any of these vulnerabilities. Based on the complexity in some environments, we don’t anticipate to see a reliable PoC in the near future.

Solution

To address these vulnerabilities, version 2.83 of dnsmasq has been released. When this blog was published, it was not clear if each of the vendors contacted through coordination with CERT/CC and JSOF have responded. However, we expect patches for various software from multiple vendors and network hardware to be released over time.

Identifying affected systems

A list of Tenable plugins to identify these vulnerabilities will appear here as they’re released. We have also released an audit and compliance check that can be obtained from our GitHub page.

For our standalone plugin for dnsmasq, identified as plugin ID 145073, users are required to enable the “Show potential false alarms” setting, also known as paranoid mode, in their scan policy in order to enable this plugin in a scan.

We also recommend enabling only this specific plugin in a paranoid scan. Scan policies configured to have all plugins enabled will see an increase in the number of triggers, as it will include all paranoid plugins during the scan.

Enabling Paranoid Mode

To enable this setting for Nessus and Tenable.io users:

1. Click Assessment > General > Accuracy
2. Enable the “Show potential false alarms” option

To enable this setting for Tenable.sc (formerly SecurityCenter) users:

1. Click Assessment > Accuracy
2. Click the drop-down box and select “Paranoid (more false alarms)”

Get more information

• JSOF Blog post for DNSpooq
• JSOF Technical Whitepaper
• US CERT ICS Advisory (ICSA-21-019-01)
• CERT Coordination Center Vulnerability Note VU#434904

Join Tenable's Security Response Team on the Tenable Community.

Learn more about Tenable, the first Cyber Exposure platform for holistic management of your modern attack surface.

Get a free 30-day trial of Tenable.io Vulnerability Management.

Tenable launches new Capture the Flag event for the security community, running from February 18–22.

Capture the Flag events are a tried and true way of testing your cybersecurity skills, practicing new ones and seeing how you measure up against others in the industry.

At Tenable, we wanted to put on a CTF specifically for our community. We’re proud to announce the first Tenable Capture the Flag will be held in February 2021!

Whether you’re a seasoned pro who started their career with Nessus or are just starting out in security, all are welcome to compete. Win prizes and bragging rights through a series of security-related challenges — either solo or with a team.

We’re excited to put together our very own CTF and see what this community can accomplish. Tenable team members, from zero-day research to vulnerability detection, have put their heads together to develop a broad set of challenges to give competitors of diverse backgrounds a chance to have fun as you put your skills to the test.

Event Details 

Register here to save your spot! You can register as an individual or a team of up to five participants. The event will run from Thursday, February 18, 2021 at 12:00 pm ET to Monday, February 22, 2021 at 12:00 pm ET. The competition will be run through the CTFd.io platform. Please use a valid email address when registering; it will be used for competition updates and prize distribution.

Competition Structure

There will be a variety of challenge types in this CTF through which competitors can earn points. Points available for challenges will increase as the difficulty of the challenges increase. Some challenges will grant fewer points over time or may decrease in point value if you use hints to solve them. Competitors won’t be required to use Tenable products to participate in the competition but Nessus Essentials may be a useful tool for some challenges.

Prizes

The top three teams or individuals will be awarded prizes. Only participants in the U.S. are eligible for monetary prizes. Winning participants outside of the U.S. will be recognized in the award ceremony and with a digital certificate or badge. You can find full contest terms here. Winning submissions will receive a single prize, whether a team or individual.

• First place - $500 Amazon Gift Card 
• Second place - $300 Amazon Gift Card
• Third place - $200 Amazon Gift Card

Note: Participants will also have a chance to win other prizes, such as a limited-release Tenable CTF t-shirt! Stay tuned — more details will be available on the competition platform.

This is meant to be a friendly competition — please no spoilers! Be careful not to share any challenge solutions publicly until after the competition wrap-up and award ceremony on February 25, 2021. (Sign-up details for the Tenable CTF Debrief & Awards Ceremony webinar will be coming soon.)

If you have any questions, please contact ctf@tenable.com. 

Don’t wait! Sign up now to secure your spot in the Tenable Capture the Flag:

Register Now

Oracle’s first Critical Patch Update of 2021 addressed 329 security updates across 25 product families, including five new critical flaws in Oracle WebLogic Server.

Background

On January 19, Oracle released the Critical Patch Update (CPU) for January 2021, its first quarterly release for the year. This quarterly update contains fixes for 202 CVEs in 329 security updates across 25 Oracle product families. Out of the 329 security updates published this quarter, over 42% were assigned a medium severity. Critical vulnerabilities only accounted for 14% of the security updates patched this quarter.

* Chart is accurate as of January 19, 2021

Analysis

This quarter’s update includes fixes for 47 critical CVEs. The Oracle Fusion Middleware category contained the highest number of patches at 60, representing just over 18% of the patches from this quarter. A full breakdown of the patches can be seen in the table below:

Two product families contained no exploitable vulnerabilities

This quarter and for the first time in recent memory, Oracle assigned no exploitable CVEs to two particular product families: Oracle Global Lifecycle Management and Oracle Secure Backup. This means that these two products did not contain any vulnerabilities that Oracle considered to be exploitable by an attacker. However, Oracle did note that this quarter’s updates include third party patches for five CVEs:

Five New Critical Vulnerabilities in Oracle WebLogic Server

As part of this quarter’s patch update, Oracle addressed five new vulnerabilities in Oracle WebLogic Server, a prominent application server solution within Oracle’s Fusion Middleware Product Family. Each quarter, we keep an eye out for newly disclosed flaws in WebLogic Server because of their favorability with attackers. This is supported in the findings from our 2020 Threat Landscape Retrospective Report, where we highlight four noteworthy vulnerabilities in Oracle WebLogic Server that were exploited in-the-wild.

The five vulnerabilities in WebLogic Server addressed this quarter includes:

All five vulnerabilities are considered “easily exploitable” according to Oracle, and successful exploitation would lead to a complete takeover of the WebLogic Server.

Fusion Middleware release contains patches for CVE-2020-14750

According to a note from Oracle in this quarter’s release, the Fusion Middleware product family contains patches for CVE-2020-14750, a patch bypass for CVE-2020-14882, which was initially patched in Oracle’s October 2020 CPU release. However, due to the discovery of the patch bypass and in-the-wild exploitation, Oracle released a fix as part of an out-of-band (OOB) patch. The January 2021 CPU includes this fix as part of the Fusion Middleware release to ensure organizations that did not apply the OOB patch receive these critical patches.

Proof of concept

At the time this blog post was published, a writeup on the exploitation of CVE-2021-2109, a WebLogic remote code execution vulnerability, was available. Details from the writeup include screenshots showing exploitation and technical details which could be used to create a working proof-of-concept.

Solution

Customers are advised to apply all relevant patches in this quarter’s CPU. Please refer to the January 2021 advisory for full details.

Identifying affected systems

A list of Tenable plugins to identify these vulnerabilities will appear here as they’re released.

Get more information

• Oracle Critical Patch Update Advisory - January 2021
• Oracle January 2021 Critical Patch Update Risk Matrices
• Oracle Advisory to CVE Map

Join Tenable's Security Response Team on the Tenable Community.

Learn more about Tenable, the first Cyber Exposure platform for holistic management of your modern attack surface.

Get a free 30-day trial of Tenable.io Vulnerability Management.

With the rise of daisy-chained cyberattacks, security teams must consider the contextual risk of each vulnerability, including its potential to be leveraged in a full system compromise.

Faced with limited time and resources, every security team must prioritize threats. Vulnerabilities that are rated lower in severity might be tabled to fix later; however, with the explosion of critical vulnerabilities, “later” usually means “never.” More often than not, medium and low-risk vulnerabilities, and even certain high and critical severity ones, end up having long lives in organizations’ environments.¹ These unpatched vulnerabilities are all an attacker needs to not only gain access but escalate privileges and move laterally, triggering a much more serious breach of the system. 

In this post, we look at the risks of these increasingly common exploit chains, and the importance of alternative frameworks such as MITRE ATT&CK in assessing the situational risk associated with vulnerabilities. This approach can help security teams prioritize, for example, a local vulnerability that might have been overlooked but has the potential to allow an attacker to breach an entire environment when combined with a code execution vulnerability. The severity of any given vulnerability is no longer an independent measure and should be interpreted based on the context of the environment in question.

Daisy-chain maneuvers in the wild

For years, advanced persistent threat (APT) groups and skilled attackers have translated obscure and lower-risk vulnerabilities into devastating attacks, proving that security flaws rated as lower risk by the Common Vulnerability Scoring System (CVSS) can become enterprise-critical exposures. There are a number of examples of these “daisy-chained” attacks. Typically, they involve a sequence of initial compromise and privilege escalation vulnerabilities, but they might also exploit a simpler combination of information leakage flaws.² Defenders are often in the dark about these potential attack vectors, and having an alternative prioritization view based on threat reports and adversaries' activity has become more than necessary.

This isn’t a new trend. Over the last few months, Tenable has published multiple blog posts analyzing recent FBI and CISA (Cybersecurity & Infrastructure Security Agency) alerts regarding nation-state groups³ and APT actors⁴ chaining together vulnerabilities against a number of government agencies and U.S.-based networks. In 2019, an FBI Flash Briefing⁵ listed a dozen vulnerabilities, including low and medium severity flaws (mainly information disclosure vulnerabilities), used by a Chinese APT actor referred to as “APT10,” targeting governments and cloud computing providers both in the U.S. and abroad. 

A number of threat intelligence platforms continue to report on APT groups and malware campaigns that daisy-chain vulnerabilities and weaknesses against their targets. In Table 1, we present a few examples of CVEs (including low and medium severity vulnerabilities) that were leveraged in a vulnerability chain to fully compromise targeted systems. Note that traditional CVSS severity scores provide an incomplete view of risk. Any given vulnerability can play a major role along the attack chain, and this information should be factored in so that important vulnerabilities are not overlooked.

Table 1. Examples of vulnerabilities leveraged in full system compromise.

The MITRE ATT&CK view

MITRE ATT&CK⁶ is a knowledge base and framework that has emerged as one of the key resources for security teams in their efforts to defend against threats and threat actors. The Tactics, Techniques, and Procedures (TTPs) documented in the ATT&CK Matrix have been hugely important in both offensive and defensive planning, including visualizing and assessing potential attack vectors and defensive coverage. 

From a vulnerability management perspective, the lack of technical and exploitation details for any given vulnerability has long been a major roadblock to effective prioritization. Part of the problem has been the misinterpretation and misuse of CVSS as a metric to drive prioritization, even though it was originally designed to describe the technical nature of vulnerabilities. A threat modeling approach to vulnerability management is necessary to take into account the threat landscape, and the context of vulnerabilities and target environments. 

Tenable's Vulnerability Priority Rating (VPR) combines vulnerability and threat intelligence data to predict the likelihood of exploitation and deduce a remediation priority rating for each vulnerability. The MITRE ATT&CK mapping complements this work by detailing the tactics and techniques associated with vulnerabilities for better visibility into possible attack scenarios and mitigation priorities.

We believe MITRE ATT&CK can play a major prioritization role in allowing security teams to map their vulnerabilities onto possible attack vectors or TTPs and understand the methods adversaries could use along the attack chain that leverage those vulnerabilities. It answers the question of how a vulnerability could be leveraged to breach your system. This is key to enabling defenders to turn raw vulnerability data into a more efficient and focused prioritization and mitigation effort, including in the context of the security controls that are in place. At Tenable, we have developed this capability to help customers in their prioritization efforts, work that is detailed further in our Edge Week 2020 presentation, “Mapping CVE to MITRE.”

Case study: Mapping the Shamoon Attack

One recent daisy-chained attack that leveraged lower severity CVEs was called Shamoon.⁷ It leveraged CVE-2017-0213 in a vulnerability chain to escalate privileges. Despite this risk, the vulnerability has low and medium ratings in CVSS v2.0 and CVSS v3.0, respectively. Shamoon also leveraged CVE-2017-11774, which has a medium and high rating in CVSS v2.0 and CVSS v3.0, respectively. 

Table 2 displays the mapping associated with the Shamoon attack. The mapping shows that CVE-2017-11774 can be exploited for code and user execution. It also shows that the vulnerability leverages PowerShell and mentions malware families that have previously used it. The same applies to CVE-2017-0213, which allows for privilege escalation and lateral movement. This means that the combination can be devastating if no action is taken. 

From a prioritization standpoint, the MITRE ATT&CK mapping shows that defenders should pay more attention to assets with this combination of vulnerabilities, while taking into account their existing countermeasures and controls. Using this mapping, defenders can better identify realistic attack paths against assets and throughout their environment, and focus mitigation efforts on areas of most significant risk.

Table 2. Examples of MITRE ATT&CK mapping.

Conclusion

A full system breach rarely happens through a single vulnerability. Daisy-chaining vulnerabilities is not only extremely common but is also an important tactic for threat actors. 

MITRE ATT&CK has become the de-facto framework for defenders to position and strengthen their defenses. However, due to the lack of detailed technical and exploitation analyses for most vulnerabilities, this mapping hasn't been widely available to defenders. 

At Tenable, we believe this is more than a “nice to have." Further visibility into threats and threat actors, and how these map to local vulnerability exposures, is necessary and results in more effective prioritization and better protection of enterprise environments.

_{1. Tenable Research, “Persistent Vulnerabilities, Their Causes and the Path Forward,” June 2020
2. F5, "How Three Low-Risk Vulnerabilities Become One High," January 2018
3. Narang, Satnam, "US Cybersecurity Agency CISA Alert: Foreign Threat Actors Continue to Target Unpatched Vulnerabilities," Tenable Blog, September 17, 2020
4. Narang, Satnam, “CVE-2020-1472: Advanced Persistent Threat Actors Use Zerologon Vulnerability In Exploit Chain with Unpatched Vulnerabilities,” Tenable Blog, October 12th, 2020
5. FBI Flash Alert, “Chinese APT10 Intrusion Activities Target Government, Cloud-Computing Managed Service Providers and Customer Networks Worldwide,” January 2, 2019
6. The MITRE Corporation, “MITRE ATT&CK: Design and Philosophy,” March 2020
7. G. Ackerman, R. Cole, A. Thompson, A. Orleans, N. Carr, "OVERRULED: Containing a Potentially Destructive Adversary," FireEye Blog, July 3, 2019}

A researcher has published a proof-of-concept exploit script for a critical SAP vulnerability patched in March 2020 and attackers have begun probing for vulnerable SAP systems.

Background

On January 14, a proof-of-concept (PoC) exploit script for a critical vulnerability in the SAP Solution Manager, a centralized management solution for SAP and non-SAP systems, was published on GitHub.

The vulnerability was discovered and disclosed by security researchers Pablo Artuso and Yvan Genuer of Onapsis. It was originally patched in March 2020 as part of SAP’s Security Patch Day. The researchers presented their findings at the Black Hat security conference in 2020 in a session titled “An Unauthenticated Journey to Root: Pwning Your Company's Enterprise Software Servers.”

Analysis

CVE-2020-6207 is a missing authentication vulnerability in SAP Solution Manager, which Onapsis refers to as SolMan. As its name implies, the vulnerability exists due to a missing authentication check in a specific component of Solution Manager called User Experience Monitoring (UXMon). UXMon was previously known as EEM Manager, so references found within the PoC script for “EEM” apply to this particular component.

A remote, unauthenticated attacker could exploit this vulnerability by sending a specially crafted request to a vulnerable SAP instance that has exposed the SAP Solution Manager HTTP(s) port publicly. While the researchers note that this vulnerability can be exploited under default configurations, they also note that Solution Manager is “not frequently exposed to the internet,” limiting the overall impact. However, this limitation does not preclude a local attacker from exploiting this flaw.

Successful exploitation could allow an attacker to execute code on satellite systems as well as systems linked to the Solution Manager through the Solution Manager Diagnostic Agent (SMDAgent), also known as the Diagnostic Agent (DAA). The potential fallout from exploitation is that an attacker could execute operating system level commands and take control of associated SAP systems.

Onapsis notes that it has observed active scanning for this vulnerability and has provided additional details about the impact of this vulnerability in its most recent blog post about the flaw.

RECALL: CVE-2020-6207 evokes memories of RECON vulnerability

You may recall that in July 2020, researchers at Onapsis published details about a critical vulnerability in the SAP NetWeaver Application Server JAVA (AS JAVA). Dubbed “RECON” by the researchers and identified as CVE-2020-6287, it was one of the noteworthy vulnerabilities we highlighted in our 2020 Threat Landscape Retrospective report that was released earlier this year.

Like CVE-2020-6207, RECON was another missing authentication vulnerability, this time in the LM Configuration Wizard of Netweaver AS JAVA.

CVE-2020-6207 is at least the second notable missing authentication vulnerability disclosed in just the last year affecting SAP products.

Proof of concept

As mentioned at the beginning of this blog post, a PoC exploit script for CVE-2020-6207 was published to GitHub on January 14 by security researcher Dmitry Chastuhin.

RCE PoC for CVE-2020-6207 (Missing Authentication Check in SAP Solution Manager)https://t.co/PVg72190wMpic.twitter.com/enoqzKEVTv

— Dmitry Chastuhin (@_chipik) January 14, 2021

Chastuhin is also credited with publishing a PoC for RECON last summer.

Solution

CVE-2020-6207 was patched as part of SAP’s Security Patch Day for March 2020. Additional details can be found in Note #2890213.

While it is unsurprising at this point, the fact remains that attackers are successfully leveraging PoC exploit scripts to target unpatched vulnerabilities, whether it be nation state groups as reported by the Australian Cyber Security Centre in June 2020, or your average cybercriminals. It is extremely important for organizations that utilize SAP in their environment to be diligent and take stock to identify vulnerable systems and apply these patches immediately.

Identifying affected systems

A list of Tenable plugins to identify this vulnerability will appear here as they’re released.

Get more information

• SAP: Security Patch Day for March 2020
• Black Hat Presentation by Researchers for CVE-2020-6207
• GitHub Repository of PoC Exploit Script for CVE-2020-6207
• SAP Blog Post About PoC for CVE-2020-6207

Join Tenable's Security Response Team on the Tenable Community.

Learn more about Tenable, the first Cyber Exposure platform for holistic management of your modern attack surface.

Get a free 30-day trial of Tenable.io Vulnerability Management.

Without a detailed view of the assets and vulnerabilities across your OT environment, security leaders face increased costs and delays when it comes to incident response efforts.

Last week on Twitter there were several discussions centered around recent supply chain attacks as well as the feasibility of scanning for vulnerable devices within operational technology (OT) environments.

A number of incident responders who I respect in the community noted that the first step in any response effort is to gain a full understanding of the environment. Attempting to figure out the full extent of a breach without knowing all the devices connected to your networks and how they are segregated is much like trying to get to a destination without a map or GPS. These professionals will tell you that the lack of an upfront, up-to-date asset inventory significantly increases the cost of incident response efforts.

I often get questions from current and potential customers who are trying to understand whether they should invest in asset inventory, device management and visibility solutions, or in threat hunting and incident response solutions. Quite frankly, over the long-term, the answer is both. But if the organization does not yet have a system of record in place to fully understand the state of all of their assets, and specifically where these devices are vulnerable, then it is clear which one should be the first investment.

Today’s CISOs need continuous visibility

When the board of directors asks whether your organization has been impacted by a recent supply chain attack such as SolarWinds, no chief information security officer (CISO) ever wants to answer “I don’t know.” As the threat landscape continues to evolve at a rapid pace, answering these questions is easier said than done. Hiring a consultant to come in once a year to scan your environment and catalog your devices is no longer sufficient for what would be considered “due diligence.” Organizations must pivot to using continuous, real-time solutions to monitor the myriad of devices that come and go every day on our converged IT – OT networks.

Purpose-built tools uncover all your OT devices

Another valid concern in the OT environment is the utilization of IT-centric scanning tools. It is well-known that such tools used carelessly in these systems can lead to failures and/or process downtime by well-meaning IT security teams. Fortunately, in recent years, purpose-built asset discovery tools have been created specifically for these sensitive OT environments.

Tenable.ot is such a tool. Our active querying technology communicates with sensitive OT controllers and devices utilizing their own native protocols, in exactly the same way that the vendors themselves communicate with the devices during routine system operations. This technology provides a safe, reliable method to simply ask the device about its specific configuration parameters, firmware versions and other relevant metadata. This allows us to gain far more accurate and detailed information about the OT environment than can be inferred through passive network monitoring alone.

Adaptive assessment targets IT devices in OT environments 

It is also well known that OT environments are not simply composed of programmable logic controllers or other similar devices. These environments increasingly incorporate commercial off-the-shelf (COTS) components such as servers running contemporary operating systems like Microsoft Windows. Tenable has long been considered the industry standard when it comes to vulnerability management on such platforms. We have taken the power of Nessus and incorporated it into the Tenable.ot product line, giving you the best of both worlds. You can communicate with sensitive OT devices using their safe and reliable protocols, while also safely scanning the IT systems present in your OT environment with a specialized version of Nessus.

Comprehensive dashboards prioritize remediation actions

Of course, supply chain attacks do not care or limit themselves to one side of the firewall. If you are the CISO, you need to be able to assess the potential impact for both your enterprise and your OT deployments. This is why from day one Tenable.ot communicates these details about your OT environment up into Tenable’s risk-based vulnerability management (RBVM) solution, allowing you to visualize and prioritize — using our Vulnerability Prioritization Rating (VPR) — which systems and devices you need to mitigate first.

Preparing for an incident requires more than putting down a retainer with an incident response company. It means investing upfront in the systems that will give you the ground truth when it comes to information about the state of your assets and where you are most vulnerable.

Adopting consistent tagging practices can help to quickly identity resources, ensure change control efforts, and reduce security risks within your cloud environments.

Many organizations use the cloud to quickly deliver and scale applications across multiple cloud platforms. While engineering teams often work in parallel to build, test and deploy code across production and development environments, security teams are also working to continuously monitor and assess their cloud security posture.

As cloud footprints continue to scale, containing cloud costs and ensuring resource asset management have become top priorities. Without an effective plan to manage these changes, organizations can easily lose visibility on resources within their cloud environments. Over time, the number of unused resources will continue to increase, as will the number of resources with excessive permissions and other misconfigurations. Implementing a global tagging strategy provides an effective way to manage resources, control costs and prevent unnecessary risks. While tagging can be done manually, we see clear benefits in using Infrastructure as Code (IaC) to tag your resources.

We understand that IaC doesn't lend itself to every application or configuration; in some cases resources and tags need to be manually created. Some teams may not be using IaC at all, and have to manually deploy and tag resources. For these reasons, we also provide guidance on options available from cloud service providers that can help jumpstart your tagging strategy regardless of which method you choose. 

Why Tagging?

According to Amazon Web Services (AWS), tagging provides an effective way to "manage, identify, organize, search for, and filter resources." While tagging can be used for cost optimization purposes, it can also be used to promote accountability within your organization. When security issues or incidents arise, adding consistent tagging practices enables your security practitioners to easily identify the team that owns any given cloud resource in order to quickly address issues and mitigate risk. 

Getting Started: Establish Requirements

Tagging all of your cloud resources is considered best practice. But where do you begin? Business requirements can dictate whether to take a phased approach to your tagging strategy and help you identify priorities. We recommend identifying your critical services (i.e.: Identity and Access Management [IAM], Compute, etc.) first and applying tags to those resources. From there, you can work with your stakeholders to implement tagging on other services within your cloud environments. 

One of the first items that should be established in your global tagging policy is determining a set of required tags. Depending on business requirements, using a unique and consistent set of tags is ideal. Reviewing whether your required tags are in use by teams internally will help to prevent overlap and conflicts. Other factors to consider are whether application ownership or team names change within your organization. If so, then using tags such as "owner" or "team" may not be useful. Lastly, you should determine how your "required" tags will be applied and enforced.

Tagging using Infrastructure as Code

If your organization is using IaC in some form, your first step should be to work with your stakeholders and understand if, where and how these tools are being used across your cloud environments. Whether you have one cloud account or hundreds of accounts, tags can be easily added into your IaC with just a few lines of code, as shown in the examples below.

Image: Adding tags using CloudFormation

Image: Adding tags using Terraform

In this example, the Location tag value includes the name of the code repository from which the IAM role is deployed. Using Creation Time and Last Activity details, this IAM role was deployed from code and has not been accessed in the last 400 days. Security teams can work with code owners to remove the unused role from the account. 

Cloud Vendor Support for Tagging

For teams that have yet to embrace tagging using IaC, or simply need a solution to quickly deploy tags, AWS, Microsoft Azure and Google Cloud Platform (GCP) have several options that can help.

• AWS - Tag Editor provides a centralized solution to view and add tags on your resources across any region within an AWS account. In the example below, Location tags are being applied to two Elastic Compute Cloud (EC2) instances in separate regions.

• Azure - Resource Groups provide a great way to apply tags to resources, resource groups and subscriptions. Once you've created and associated resources with your group, you can then assign tags to any of your target resources.

• GCP - Labels are key/value pairs used to organize existing resources. By adding Labels to your resources, you can easily filter on production versus development resources, teams and services.

All three cloud platforms provide additional services and API support for advanced use cases that will help to audit and enforce tagging practices.

Understand the Benefits

Ensuring cyber hygiene practices though tagging should be a critical part of your cloud security program. Once consistent tagging practices are in place, less time is spent searching for resources and finding owners to address security risks. Below are just some of the benefits of an effective global tagging strategy:

• Improve incident response time

• Remediate security risks

• Prevent privilege escalation

• Enforce change management policies

• Identify resource owners

• Support auditing and compliance efforts

• Remove unused resources

• Reduce cloud costs 


Implementing a global tagging strategy will take time and buy-in from teams across the organization. Once these practices are in place, security teams will have improved visibility into cloud assets, enabling them to effectively reduce cyber risk and understand the organization's exposure across any cloud environment.

Learn More:

• Download the solution brief: Frictionless Assessment of AWS Assets

• Amazon Web Services (AWS) Whitepaper: Tagging Best Practices


As pandemic restrictions linger, federal agencies are preparing for a rise in classified telework. Here’s why a continued focus on cybersecurity fundamentals is imperative.

The COVID-19 pandemic accelerated the move to remote work beyond all prior expectations. While there were many exceptions to the rule in the early days of the pandemic response, we are seeing those exceptions decrease as the remote work environment matures. The sudden need for secure remote work drove innovation and flexibility as necessary attributes of a successful transition. Leaders at the Defense Information Systems Agency (DISA), for example, commented that this demand, and the resultant security upgrades, were a sort of "silver lining" within the pandemic “cloud.”

The pandemic has restricted all organizations from working in their traditional ways, and the Pentagon is no exception. Approximately one million personnel are now working remotely as a result of the Department of Defense (DoD) expanding its telework capabilities. Currently, the majority of remote work done by DoD employees is low-risk and unclassified. But as the pandemic lingers, the Pentagon and its agencies are being pushed to do more classified telework. For example, former DoD chief information officer Dana Deasy signaled that the Pentagon aimed to support sensitive, classified telework for its employees by the end of 2020. Classified work – which is defined as handling secret or top-secret designated data – has historically been completed by DoD personnel in physical facilities. These sensitive compartmented information facilities (SCIFs) safeguard classified data with physical barriers.

As the DoD looks ahead, enhancing secure telework capabilities is at the top of its “to do” list.

The quick transition to remote work across organizations has bad actors ready to take advantage, and the increase in sensitive – even classified – information being accessed remotely will frame the Pentagon and its employees as a larger target, making it even more important for the DoD to secure its cyber infrastructure.

As always, regardless of how many security measures are built into a network, continued focus on the fundamentals is necessary to maintain security. Below are three critical elements of a successful and secure remote work program that should continue to be priorities for DoD as the move to classified telework accelerates.

1. Maintain good cyber hygiene

Getting the basics right – maintaining good cyber hygiene – is essential to a successful cybersecurity program. An increased attack surface due to more telework means that before any new programs can be implemented or classified documents can be viewed remotely, the Pentagon must have a clear image of its whole environment, where it’s exposed and how those vulnerabilities could impact the organization. Good cybersecurity requires basic cyber hygiene, something that requires discipline – a foundational DoD strength – but is not unreasonably difficult to achieve. If the DoD can get the basics right, they can prevent most breaches and attacks on their systems.

Shiny new cyber tools don’t improve cybersecurity if organizations aren’t maintaining that critical focus on the fundamentals. One great resource for cyber basics is the Cybersecurity and Infrastructure Security Agency’s (CISA) Cyber Essentials Toolkits, which outline the steps IT and executive leaders need to work toward to fully implement basic cybersecurity. Maintaining good cyber hygiene must be a top priority for both the DoD and other organizations doing more telework during this time. 

2. Outline vulnerability management procedures

The vast majority of breaches occur as a result of known but unpatched vulnerabilities. According to one recent study, 60% of security breaches were linked to a vulnerability for which a patch was available but not applied. Additionally, Tenable Research has found that 26% of vulnerabilities are never fixed. These exposures pose a significant threat to organizations, and better prioritization methods are needed to focus remediation efforts on the risks that matter most . 

Risk-based vulnerability management may seem complicated at first, but it can be relatively easy to implement if organizations know what to expect and plan accordingly. This includes building good authentication and identity management practices, establishing strong cyber hygiene and having unified visibility across your attack surface, including dynamic environments such as cloud instances or web applications.

Pentagon leadership must have strong management to identify and fix vulnerabilities. This will help agencies proactively manage their cyber risk, instead of making retroactive efforts in times of emergency.

3. Establish streamlined network visibility  

Breaking down silos is another critical step for organizations to achieve network visibility. Too many organizations see their cybersecurity and other critical initiatives go in opposite directions because security and executive leaders are not communicating effectively or understanding each other.

According to our recently commissioned study of more than 800 business and cybersecurity leaders, conducted by Forrester Consulting on behalf of Tenable, when security and business leaders are aligned, they deliver demonstrable results in their ability to assess and manage critical cyber risks. Aligning overall organization and cybersecurity objectives not only improves security posture, but it also advances agency goals and benefits the entire organization. 

There will be challenges in breaking down these silos and establishing better network visibility for the DoD, just as there are for private industry. But the benefits for personnel and the organization as a whole are significant, and agencies should work to make it a top priority. Without alignment, security teams risk chasing down issues that may pose little risk, while leaving their most critical assets and systems exposed. 

Conclusion

As the DoD moves to increase the number of employees doing sensitive, classified telework at home instead of in SCIFs, it is critical for DoD leadership to reinforce secure remote work practices. Good cyber hygiene, strong vulnerability management and central network visibility must remain top of mind for the DoD as they continue to move toward more classified telework.

The recent SolarWinds breach added an exclamation point to the importance of network visibility, as noted recently by CISA’s acting director, Brandon Wales. Mr. Wales cited insufficient visibility into agency networks and cloud deployments as “blind spots” that prevented early detection and needed to be eliminated to prevent similar breaches in the future. With increased telework expanding the enterprise network, the risk of more blind spots becomes even greater, heightening the importance of this essential step in the process.

The new NERC CIP-008-6 regulation challenges power grid operators to differentiate attempts to compromise their environment from other non-malicious cyber incidents. Here’s how Tenable can help.

For more than a decade, regulatory agencies and computer security incident response teams (CSIRTs) encouraged organizations to responsibly share information on cybersecurity incidents and raise the community’s overall preparedness to manage cyberthreats. The latest example includes new requirements by the Federal Energy Regulatory Commission (FERC) that require bulk power system (BPS) utilities to report attempts to compromise their infrastructure and operations. The exact requirements, which became mandatory on Jan. 1, 2021, are defined in NERC CIP 008-6.

While the intention behind these new regulations is to raise the cyber resilience of the power grid and facilitate effective response to major security events, they also introduce two main challenges for responsible entities:

1. Technically, how to correctly differentiate attempts to compromise the environment from human errors and routine events?
2. Procedurally, how to achieve the above with minimal bureaucratic burden on already stretched-thin cybersecurity professionals?

Tenable’s approach to the new NERC CIP requirements mirrors our handling of other regulatory requirements. Security solutions purpose-built for operational technology (OT) environments should make it as easy and automated as possible for users to identify, triage and report incidents to authorities as required. Here are three aspects of Tenable’s OT security solution that can help streamline compliance for the power grid industry.

Policy-based detection streamlines compliance efforts

Tenable.ot’s policy-based detection is a deterministic, flexible and transparent engine in which customers express their network security rules as policies with a custom level of granularity. As a result, security teams can be alerted to every deviation from these policy rules. This is the ideal method to meet the requirements by NERC CIP to “have a process that includes criteria to evaluate and define attempts to compromise and to determine if an identified Cyber Security Incident is a reportable cyber incident or an attempt to compromise...” (extracted from CIP-008-6, Table R1, part 1.2).

When using policies in Tenable.ot, users can quickly establish communication alerts ranging from specific OT configuration commands to reads and writes of tags or anomalous traffic in any IT protocol. Furthermore, these alerts can be categorized by asset groups, network segments, specific time windows and other specifications. For example, if a certain group of substation controllers has a specific time window when changes are allowed, and those changes are only permitted through proprietary configuration protocols and by a closed list of engineering stations or subnets, these rules can be configured in less than a minute in Tenable.ot.

Setting user-specific policies acts like a safety net for our customers, defining the baseline for healthy operations and ensuring that no anomaly goes unnoticed. This set of policies can be exported and shared with any third-party stakeholder, providing a clear and immediate understanding of the measures taken to adhere to the regulatory requirements.

Figure 1: The policies tab in the Tenable.ot interface

Threat landscape intelligence distinguishes malicious attacks from user anomalies

In some cases, policies can be set to alert on incidents that clearly indicate the existence of malicious intent. But in many other cases, analysts face uncertainty about the origin or cause of the alert and must look for additional information that can suggest malicious intentions.

When considering the network assets that are involved in a suspected incident, Tenable.ot users have at their hand the most recent threat intelligence as reflected in the Vulnerability Priority Rating (VPR), which incorporates parameters such as threat source, intensity and recency. Taking these parameters into consideration may provide the otherwise missing link in differentiating between operational anomalies and malicious attempts to compromise, a distinction that is the essence of the new additions to NERC CIP-008-6.

Figure 2: Attack vector simulation in the Tenable.ot interface

Unified IT-OT attack simulation protects critical network segments

Among the many cybersecurity tools available for identifying suspicious incidents, those with a unified view of both IT and OT environments have an advantage when it comes to correctly identifying attempts to compromise. Understanding possible attack vectors that stem from weaknesses in the IT environment is key for correctly assessing incidents, as previous attacks and proofs of concept teach us. Without such a broad view, OT engineers might miss essential pieces of the puzzle regarding the origin of their alerts. Similarly, IT security analysts might be blind to the consequences on the OT side of indications they witness and dismiss as non-events.

Addressing this gap is at the heart of Tenable’s efforts over the last year. Several new layers of integration are now available: Reflecting OT findings in enterprise-level applications (Tenable.io and Tenable.sc), unifying IT and OT vulnerability detection technology, and leveraging Nessus as part of Tenable.ot to best identify vulnerabilities in IT assets in the OT environment.

Figure 3: Unified IT-OT dashboard in Tenable.sc

Summary

OT security professionals face increasing regulatory requirements for reporting cyber incidents, with the energy sector leading the way. Reporting attempts to compromise the grid requires highly skilled cybersecurity analysis, ready access to the data you need and clear reporting procedures. Tenable.ot, as part of the Tenable suite of security products, has exactly what it takes to identify cyber incidents and help categorize them as actual attacks, attempts to compromise, human errors or routine events.

For more information on how Tenable can help strengthen grid security, download our Guide to Compliance with NERC CIP Standards.

When securing dynamic cloud environments, the ability to continuously discover and assess cloud assets allows you to quickly detect  issues as new vulnerabilities are disclosed and as your environment changes. Here's what you need to know to get started.  

Cloud services and applications are elastic, cost efficient, and more importantly, they enable you to respond quickly to customer needs and manage an ever-increasing remote workforce. In fact, 81% of organizations have at least one application or a portion of their computing infrastructure in the cloud. 

But with the benefits of agility and efficiency comes the challenge of protecting and securing your assets and workloads in the cloud. If the lessons from high-profile breaches have taught us anything, it is that you, the data owner, are ultimately responsible for your cloud assets— not your cloud service providers.

With the increasing number of new vulnerabilities across networks, endpoints and cloud environments, you may also realize that your legacy vulnerability management (VM) tools are no match for today's complex IT landscape and cannot protect your modern attack surface. From 2015 to 2020, the number of reported CVEs increased at an average annual percentage growth rate of 36.6%. You need an effective solution to help you prioritize remediation based on the risks they pose to your organization. 

So where do you start? My suggestion is to always start with a close look at your people, process and technology, and in exactly that order. Why? Because you may have the best technology deployed, but if your security team is not talking to your cloud team, or if you have broken business processes, you won't be able to protect everything you need to in the cloud.

Three security challenges to address first

1. Your people are not talking to each other: I have seen firsthand the disconnect between the security team and the business units. As one of my IT buddies described it, "trying to work with the business groups is like walking my Yorkshire Terrier on a chilly winter morning. I pulled on the leash to go one way, my dog was pulling in the other direction because it didn't want to go along. At the end, we were both exhausted." In many companies, the security team and the cloud team operate in siloed business units. According to a recent Forrester Consulting study commissioned by Tenable, only half of the more than 400 security leaders surveyed say they work with other teams to align risk reduction objectives with business needs. When your teams are not working together, it is difficult for you to protect, control and gain visibility to your cloud assets, putting your security posture at risk.

2. Your business process has gaps: With an on-prem traditional network, it is relatively easy to keep track of workloads and applications. With cloud environments, it is difficult to know just how large your footprint might be. This is because non-IT functions such as marketing and developers often create (then sometimes abandon) cloud assets, making it difficult for you to have a realistic view of all your cloud inventory. For example, one organization I met with recently thought they had 2,000 cloud assets in AWS. After a discovery scan, they found close to 3,500 assets. After we investigated further, we found gaps in their business process with untagged cloud assets and lost child accounts. And this is not an uncommon finding in many organizations.

3. "You can't protect what you don't know about!": While this is almost a cliche, it is still very applicable when it comes to securing your cloud assets. Organizations are having a difficult time discovering and assessing ephemeral (short-lived) assets in dynamic cloud environments. According to the Forrester study, only 44% of more than 800 security and business leaders surveyed say their security team has good visibility into their organization's most critical assets. Yet, even when assets are discovered, Tenable's own research shows that only 20% of them are actually assessed for exposures. Why? Because the traditional method of vulnerability management for the cloud is difficult and time consuming. Scanners and agents need to be installed and new vulnerability detections can lag for several weeks. In short, traditional IT security is no match for the speed of the cloud.


At this point, you are probably feeling like "geez, when can we get a break?"  Well, keep on reading, because help is on the way. 

Protecting your cloud assets: 3 critical steps

1. Align your teams for the right cloud conversation: Eliminating departmental silos and creating a collaborative environment for your teams is a critical first step towards consistent visibility and control of your cloud assets. Based on the Forrester study, business-aligned security leaders are eight times as likely as their more siloed peers to be highly confident in their ability to report on their organizations' level of security or risk. When talking to the team members who are using the cloud, it is important to frame the impact of cybersecurity threats within the context of their business needs, and use keywords such "scalability," "agility," "quality" and "continuity" in your conversations. It may be helpful to set up regular review meetings and share the security team's performance metrics with business stakeholders. If permission for administrative rights is an issue, come up with creative workarounds such as creating an agreed upon set of permissions for IT security to use, perhaps even implementing it using a common cloud native format, such as creating a CloudFormation template. This approach gives the business results the security team needs as well as lowering the level of effort needed from the cloud administrator.

2. Ensure good cloud security hygiene practices: Developing security best practices that can keep up with the speed of cloud is another critical step in securing your cloud assets. Incorporating these best practices into your overall company culture can help you alleviate administrative burden and close security gaps in the business process. For example, implementing a tagging strategy for all your cloud assets can provide you with an effective way to manage resources, control costs and reduce risks. Once the enforcement is in place, developers can enjoy the freedom of spinning up test environments; the security team can keep track of what is being created, and spend less time searching for assets and owners to address security concerns. Another good cloud hygiene practice is to link all your child accounts to the appropriate parent count in the cloud. This gives the administrators a holistic view of your entire cloud estate, enabling them to effectively reduce cyber risks and understand your organization's exposure across any cloud environment.

3. Discovery and continuous assessment for vulnerabilities is key: Being able to identify and quickly assess cloud assets is the next critical step in protecting and securing your ever-changing and expanding cloud environment. If you are using cloud services such as Amazon Web Services (AWS), live discovery of cloud assets not only can help maximize the value of your existing investment, it can also give you full visibility of the assets you may or may not have previously known about. Once you have a good understanding of what you have in near real-time, you need an assessment approach that can continuously assess the cloud as new assets are deployed or as new vulnerabilities are disclosed.


As I mentioned earlier, the traditional method of vulnerability management for the cloud can be difficult and time consuming. This is where Tenable's Frictionless Assessment can help. Unlike other vulnerability management tools, Frictionless Assessment — available now in Tenable.io — leverages native AWS tools, including the AWS Systems Manager (SSM) agent, to continuously discover and assess Elastic Compute Cloud (EC2) instances for vulnerabilities without ever having to configure a scan, manage credentials or install agents. This allows you to quickly detect security issues as new vulnerabilities are disclosed and as your environment changes with instances constantly spinning up and down. It provides you with a near real-time view of your cloud environment for an accurate inventory of assets and exposures at any given time. And it is especially effective at discovering and assessing ephemeral (short-lived) assets in dynamic cloud environments.

Frictionless Assessment was designed to work at the speed of the cloud.  But it doesn't stop there. As a key element of Risk-based Vulnerability Management, Frictionless Assessment provides comprehensive insight into vulnerabilities, including support for Tenable's Predictive Prioritization to help you focus on what matters. 

If you want to learn more on how to set up a full Risk-based Vulnerability Management program in seconds and gain actionable results in minutes, check out the Frictionless Assessment Overview Video.

SonicWall releases a patch after researchers confirm exploitation of a zero-day vulnerability in SonicWall Secure Mobile Access

Background

On January 22, SonicWall published a product notification regarding a “coordinated attack on its internal systems” conducted by “highly sophisticated threat actors.” SonicWall believed the attackers had exploited “probable zero-day vulnerabilities” in specific SonicWall products used for remote access. As they continued with their investigation, they provided additional updates into the root cause of the attack, primarily to eliminate certain products that were originally believed to be affected.

On January 31, researchers at NCC Group tweeted that they had identified a “possible candidate for the vulnerability” that SonicWall was investigating, adding they observed “indiscriminate” exploitation for this flaw in the wild.

Per the @SonicWall advisory - https://t.co/teeOvpwFMD - we've identified and demonstrated exploitability of a possible candidate for the vulnerability described and sent details to SonicWall - we've also seen indication of indiscriminate use of an exploit in the wild - check logs

— NCC Group Research & Technology (@NCCGroupInfosec) January 31, 2021

SonicWall in response confirmed the findings from NCC Group regarding the presence of a zero-day in its products and tracked this under the security advisory SNWLID-2021-0001.

We can confirm there is a zero-day identified on the SMA 100 series remote access appliance. We expect to have a patch out on Feb. 2. Full details here: https://t.co/fXyUkzn5Lb

— SonicWall (@SonicWall) February 2, 2021

Analysis

CVE-2021-20016 is a critical SQL injection vulnerability in SonicWall’s Secure Mobile Access 100 (SMA 100), a line of remote access products. A remote, unauthenticated attacker could submit a specially crafted query in order to exploit the vulnerability. Successful exploitation would grant an attacker the ability to access login credentials (username, password) as well as session information that could then be used to log into the vulnerable SMA appliance.

Rich Warren, principal security consultant at NCC Group, posted a Twitter thread with some indicators that he and his team observed as part of in-the-wild exploitation of this flaw. Warren specifically suggested reviewing log files to identify “anomalous requests” to the vulnerable device.

Some more advice is to ensure that you are capturing proper centralised logging right now.

Look for anomalous requests to:

/cgi-bin/management

That do not also have a preliminary request to:

/__api__/v1/logon (200)
/__api__/v1/logon/<id>/authenticate

Indicating auth bypass

— Rich Warren (@buffaloverflow) January 31, 2021

While examining the log files, Warren specifies that requests made to the management interface as well as through the SSL VPN client and web portal of the device should be preceded by a specific type of authentication request. If the requests are not preceded by these authentication requests, it means that the vulnerability was exploited and an authentication bypass attempt was successful.

Based on the limited information that has been shared thus far, it appears that this vulnerability is likely easy to exploit, which explains why such limited information has been made public.

Ease of exploitation akin to vulnerabilities in F5 and Citrix

When asked why additional details weren’t being shared publicly, Ollie Whitehouse, chief technical officer for NCC Group, tweeted that his team did not want to make it “too easy” as had been previously observed in the case of vulnerabilities in F5 and Citrix. Whitehouse was referencing CVE-2020-5902, a remote code execution vulnerability in the Traffic Management User Interface in F5’s BIG-IP, and CVE-2019-19781, a directory traversal vulnerability in the Citrix Application Delivery Controller, Gateway and SD-WAN WANOP products. Both of these vulnerabilities were exploited en masse soon after their disclosure and the availability of proof-of-concept exploit scripts became readily accessible.

Both CVE-2020-5902 and CVE-2019-19781 are two of the Top 5 Vulnerabilities we highlighted in our 2020 Threat Landscape Retrospective report. Flaws in SSL VPNs and other remote access tools are extremely valuable for cybercriminals, as they provide an ideal initial access vector into an organization’s network. While widespread exploitation of this SonicWall vulnerability has not yet been seen, once more details become available, we fully expect cybercriminals to take advantage of this flaw, underscoring the importance of applying the available patches as soon as possible.

Proof of concept

At the time this blog post was published, there was no public proof-of-concept available for CVE-2021-20016.

Solution

On February 3, SonicWall released firmware version 10.2.0.5-29sv to address this vulnerability in its SMA 100 line of products.

The following versions of SMA are affected by CVE-2021-20016:

Customers that deploy any of the affected SMA devices are strongly encouraged to upgrade as soon as possible. In addition to upgrading, SonicWall recommends customers reset passwords for those users who have logged into the device through the web interface as well as enabling multi-factor authentication as an additional safeguard.

If upgrading to the latest firmware is not feasible at this time, customers can apply a temporary mitigation by enabling the SMA’s built-in Web Application Firewall (WAF) on the device. However, SonicWall does stress that while this mitigation does successfully thwart attempts to exploit CVE-2021-20016, it is not a replacement for upgrading to the latest patched firmware version.

Identifying affected systems

A list of Tenable plugins to identify this vulnerability can be found here.

Get more information

• SonicWall Product Notification for Vulnerability in Secure Mobile Access
• SonicWall Security Advisory for SNWLID-2021-0001 (CVE-2021-20016)

Join Tenable's Security Response Team on the Tenable Community.

Learn more about Tenable, the first Cyber Exposure platform for holistic management of your modern attack surface.

Get a free 30-day trial of Tenable.io Vulnerability Management.

Following reports of in-the-wild exploitation, Google released a patch for the third browser-based zero-day vulnerability of 2021.

Background

On February 4, Google published a stable channel update for Chrome for Desktop. This release contained a single security fix to address a critical zero-day vulnerability that had been exploited in the wild.

Analysis

CVE-2021-21148 is a heap buffer overflow vulnerability in V8, Google Chrome’s open-source JavaScript and WebAssembly engine. Its discovery is credited to Mattias Buelens, who reported the flaw to Google on January 24. As part of this release, Google notes that they are “aware of reports that an exploit” for this vulnerability “exists in the wild,” which we interpret to mean that in-the-wild exploitation attempts have been observed.

In-the-wild vuln in Chrome just fixed. CVE-2021-21148 https://t.co/PRtcxAXn8p

— Maddie Stone (@maddiestone) February 5, 2021

A detailed bug report for the vulnerability is unsurprisingly restricted at this time in order to allow users time to apply the relevant patch.

Third browser-based zero-day vulnerability disclosed in 2021

CVE-2021-21148 is the third zero-day vulnerability we’ve observed to be browser-based in 2021. In late January, Apple released iOS and iPadOS 14.4, which contained fixes for two WebKit zero-day vulnerabilities (CVE-2021-1870, CVE-2021-1871) that were exploited in the wild.

In our 2020 Threat Landscape Retrospective report, we noted that the majority of zero-day vulnerabilities disclosed in 2020 were browser-based, accounting for over 35%.

Source: Tenable’s 2020 Threat Landscape Retrospective

In 2020, Google patched three Chrome zero-day vulnerabilities in the V8 engine that were exploited in the wild, two of which were patched within two weeks of each other:

Based on our observations in 2020, we anticipate this trend in browser-based zero-day vulnerabilities will remain consistent in 2021, as browsers remain a popular attack vector for cybercriminals.

Speculation surrounding timing of vulnerability disclosure

In a bit of interesting timing, CVE-2021-21148 was disclosed to Google just one day prior to a massive revelation from Google. On January 25, Google’s Threat Analysis Group published a blog post detailing the discovery of an ongoing campaign conducted by nation-state actors to target security researchers interested in collaborating on vulnerability research. The report specifically mentions that the threat actors circulated a link to their potential victims to a malicious website that led to successful exploitation on systems that were fully patched for both Windows and Google Chrome. This was corroborated by Microsoft, which published their own blog post about the attacks, surmising that a Google Chrome zero-day was likely used to target researchers.

Naturally, speculation has emerged that there may be a connection between these attacks and the disclosure of CVE-2021-21148. However, so far, we’ve not seen any definitive connection made between the two. Maddie Stone, a security researcher on Google’s Project Zero team, has requested anyone to share any additional details about CVE-2021-21148.

Proof of concept

Despite reports of in-the-wild exploitation for CVE-2021-21148, we have found no public proof-of-concept code at the time this blog post was published.

Solution

Google addressed CVE-2021-21148 in Google Chrome version 88.0.4324.150 for Windows, macOS and Linux clients. Updated versions for most desktop systems should be available, while others (particularly Linux-based releases) should become available in the near future.

Identifying affected systems

A list of Tenable plugins to identify this vulnerability can be found here.

Get more information

• Google Chrome Stable Channel Update (88.0.4324.150)

Join Tenable's Security Response Team on the Tenable Community.

Learn more about Tenable, the first Cyber Exposure platform for holistic management of your modern attack surface.

Get a free 30-day trial of Tenable.io Vulnerability Management.

Faced with an expanding attack surface and limited resources, security teams can apply machine learning to prioritize business risks and help predict what attackers will do next.

In today’s cybersecurity landscape, gaps in your visibility are inevitable. If you’re like most infosec professionals, your reality looks something like this:

• A larger attack surface to protect: You are tasked with protecting widely dispersed computing assets due to increases in cloud adoption, remote work and connected devices.
• More vulnerabilities to track: The number of new vulnerabilities to defend against continues to rise, with 18,358 new CVEs reported in 2020, continuing a 36.6% average annual percentage growth rate over the last five years.
• A shortage of resources: As many as 70 percent of cybersecurity professionals believe their organization has been impacted by the global cybersecurity skills shortage.

The basic calculus here is obvious: More assets to protect, more vulnerabilities to remediate and a lack of resources with which to do it. As a result, data science is playing a larger role in cybersecurity, with the application of artificial intelligence and machine learning accounting for nearly half of new industry patents filed worldwide in the last four years.

Machine learning helps security teams work smarter

Since enterprises need their operations to move faster than human speed or available resources allow, machine learning is quickly becoming the technology of choice. 

In this approach, data scientists train algorithms, with varying degrees of supervision, to find valuable patterns in vast data sets. Thanks to the ability for algorithms to learn and scale, enterprises are already deploying or exploring their use in many areas of the organization: 

• In marketing, machine learning helps analyze the vast amounts of data generated by online marketing and customer interactions
• In research and development (R&D), machine learning helps businesses identify areas to explore and pinpoints potential dead ends faster
• In operations, machine learning helps increase the efficiency, accuracy and speed of business processes related to application approvals and customer service requests

Cybersecurity presents similar challenges to these areas: There is simply too much data — and too many disparate tools — to maintain adequate visibility and respond in an effective and timely manner. There may also be assets you cannot regularly scan or patch, due to the need to maintain uptime; nevertheless, your organization must find a way to forecast the likely risk those assets might pose at any given time.

Machine learning provides a mechanism for improving visibility and predicting urgent risks, and it delivers these capabilities with a speed and scale humans alone cannot replicate. Let’s examine three scenarios where data-powered predictions can help your cybersecurity team focus resources where they can have the biggest impact. 

Predict which vulnerabilities attackers will exploit next

Your organization’s attack surface is not only expanding — it’s also becoming more diverse and more transient in nature. Containers, multi-cloud and connected devices are common in many IT infrastructures. 

Security teams need a method for prioritizing vulnerabilities to ensure their resources are properly aligned with the risks they face. Legacy methods have typically used the Common Vulnerability Scoring System (CVSS), which measures the technical severity of vulnerabilities but not the risk they pose. CVSS offers only a static number, and it doesn’t help prioritize vulnerabilities as they attract more attention and their exploits mature.

Machine learning algorithms can help monitor the activity around vulnerabilities — such as the availability of exploit kits, chatter on the dark web or recent threat activity — and update prioritization on a daily basis, helping security teams make informed decisions about where to devote resources and address vulnerabilities. In fact, this risk-based approach has proven to be as much as 22 times more efficient at reducing vulnerability risk than legacy prioritization methods.

Relying on CVSS or human security analysts to deliver vulnerability prioritization and visibility leaves open the possibility that you’ll prioritize vulnerabilities that pose little risk to your organization and miss exposures that could cripple essential business functions. Adding in data science and machine learning can give you the scale and scope you need to make informed decisions, allowing you to find and fix the vulnerabilities that matter most to your organization.

Evaluate which business-critical assets might be affected 

IT organizations increasingly operate as business enablers, helping deliver the capabilities business units need to serve customers. Under this model, IT projects are often prioritized based on their business impact. Similarly, IT security teams can apply better protection against vulnerabilities by better understanding the potential business impact. 

Knowing the type of asset affected by a vulnerability, its capabilities and business purpose, and its internet exposure, for example, can help IT security teams predict the impact a vulnerability may have on key business functions.

Often deployed through a mix of manual tagging and automated scores, this asset criticality layer can further prioritize your remediation efforts. For example, it can help defenders elevate low-severity vulnerabilities affecting an essential data server or cloud application, critical exposures that might have otherwise flown under the radar. 

Identify the riskiest areas of your network that need attention

Few security teams have the ability to thoroughly assess every vulnerability on every asset across their network. In fact, one of the biggest barriers to visibility is that, on average, nearly 60 percent of enterprise assets receive only limited external scans. This leaves a sizable blind spot when trying to understand the vulnerability of assets where credentials are not available for full discovery through scanning. 

As we all know in security, what you don’t know can hurt you. Machine learning can help organizations better understand the risks associated with unknown devices by using the information you do know to predict the level of likely risk. 

Using what information is available — for example, asset features, operating system, number of open ports or, if available, previous scan history — machine learning can predict the exposure of “unknown” assets based on lookalike asset averages. These predictions can illuminate high-risk areas of your attack surface that warrant immediate and more thorough assessment.

Put machine learning to work for your security organization

Machine learning is key to protecting critical business assets in today’s environment.

Right now, security teams too often struggle from gaps in visibility. There are gaps around vulnerability prioritization; gaps around the potential business impact of particular risks; gaps around the full exposure of devices and assets deployed in your environment. 

It’s time to put machine learning to work on your behalf, increasing your visibility and prioritization efforts, and strengthening the level of protection for your most critical assets.

The recent intrusion of a Florida water-treatment plant highlights the need for strong protection of industrial control systems. Here's what you should consider.

This past Friday, in Oldsmar, Florida, an eagle-eyed technician at a water purification plant noticed a chemical change setting to the water supply. With a quick response, the technician found that remote access was made to the operational technology (OT) network in charge of purifying the water, and the unknown intruder had increased the amount of sodium hydroxide, essentially lye, from 100 parts per million to potentially harmful levels of 11,100 ppm. If not for the quick response of the technician, there could have been a direct impact to the lives of people in Pinellas County who rely on the safe delivery of this water as a drinking source. 

While in this case, the potentially calamitous, unauthorized change to the OT network was quickly detected and resolved before any damage to the public occurred, this is not always the case. Unfortunately, over recent years, OT networks have seen a dramatic uptick of security incidents. 2020 global events only accentuated the security challenge, forcing companies to “open up” their network for remote access to quarantined or otherwise limited personnel. These factors, along with technological advances such as the convergence of IT and OT environments and the rapid adoption of IoT technology, have further expanded OT attack surfaces and vectors, making industrial environments into prime targets.

For most industrial organizations, the need for vigilant security is nothing new. Threat vectors and the security forecast is constantly evolving given emerging threats. The convergence of IT and OT operations, whether planned or unplanned, is in almost all cases a reality. Setting the appropriate safeguards will help ensure secured operations for your organization and will give OT operators the tools needed to safeguard critical infrastructure. What should you consider?

Visibility that extends beyond traditional borders

Until only recently, IT security and OT infrastructures inhabited completely different worlds, thus the ability to see into either environment was bifurcated along these lines. Modern-day attacks are amorphous and travel across the traditional IT and OT security borders, as was evidenced in this most recent incident. Our ability to track these types of propagation routes requires the de-siloing of traditional visibility parameters. Being able to gain a single view of IT and OT, along with the conversations happening between the two worlds, is essential. This holistic view can help illuminate potential attack vectors and asset blind spots that may have eluded traditional security strategies.

Deep situational analysis

Whether or not an OT environment is converged, it is important to recognize the significant difference in IT and OT life cycles. While IT infrastructures update regularly, OT infrastructures often persist for years, even decades. It is not uncommon for an OT infrastructure to be as old as the plant itself. The result is that a full inventory of assets, along with maintenance and change management records, may not be current. Therefore, crucial data may be missing, including important details such as model number, location, firmware version, patch level, backplane detail and more. Since it is impossible to secure assets that you may not even know exist, having a detailed inventory of your OT infrastructure that can be automatically updated as conditions change is essential to protecting your industrial operations.

Reduction of cyber risk

When it comes to modern OT environments, cyberthreats can originate from anywhere and travel everywhere. Therefore, it is important to utilize as many capabilities and methodologies as possible to find and mitigate exposure risk. This includes network-based detection that:

• Leverages policies for allow- and block-listing capabilities
• Anomaly-based detection that can find zero-day and targeted attacks and is predicated on baseline behaviors unique to your organization
• Open-source attack databases, such as Suricata, that centralize threat intelligence from the greater security community, bringing together more eyes on any potential threat to yield significantly better security response

Since most attacks target devices rather than networks, it is essential to utilize a solution that actively queries and provides security at the device level. Because OT device protocols can vary widely, security and health checks must be unique to the make and model of the device, including the device language. These deep checks should not scan but rather be precise in query nature and frequency.

In 2020, over 18,300 new vulnerabilities were disclosed, affecting OT devices as well as traditional IT assets. However, less than half of these vulnerabilities actually had an available exploit. Gaining a full awareness of the vulnerabilities that are relevant to your environment, along with a triaged list of exploitable vulnerabilities and critical assets, will enable you to prioritize the threats with the highest risk score, thereby dramatically reducing your cyber exposure profile.

Knowing when changes happen

The core of any OT infrastructure is the programmable logic controller, or PLC, that controls the industrial or manufacturing process. In the case of water purification, the PLC orchestrates the delicate process of ensuring the appropriate mix of chemicals that renders drinking water safe. 

Attacks architected against industrial control systems (ICS) consist of making an unauthorized change to a PLC. Configuration control creates a snapshot or papertrail to highlight a delta before and after a PLC change. By taking snapshots at regular intervals, you get visibility into such changes, how they were made and by whom. Configuration control can provide a full audit trail and give ICS administrators the intelligence, insights and ability to roll back to a “last known good state” if someone actions sub-optimal or unauthorized changes to a PLC.

OT environments are core to the operation of nearly all critical infrastructure and manufacturing facilities. They have grown more sophisticated and interconnected over time, producing and manufacturing essential goods and services to exacting standards. Our need to secure these critical environments against threats is as important, if not more, than securing our IT infrastructures which are connected to them. Gaining visibility, security and control over OT environments is crucial – lives literally depend on it. 

For more information on implementing these OT safeguards, check out the whitepaper, Secure Industrial Control Systems With Configuration Control.

Zerologon has quickly become valuable to nation-state threat actors and ransomware gangs, making it imperative for organizations to apply these patches immediately if they have not yet done so.

Background

On February 9, as part of its February 2021 Patch Tuesday release, Microsoft released an additional patch for Zerologon to enable a security setting by default to protect vulnerable systems.

CVE-2020-1472, also known as “Zerologon,” is a critical elevation of privilege vulnerability in Microsoft’s Netlogon Remote Protocol. It was initially patched in Microsoft’s August 2020 Patch Tuesday. The vulnerability received a CVSSv3 score of 10.0, the maximum possible score, and a Vulnerability Priority Rating (VPR) score of 10, underscoring its severity.

Additional details shared by researchers including fully working proof-of-concept

On September 11, 2020, researchers at Secura, who were credited with discovering the vulnerability, published a blog post and whitepaper providing more details about the severe flaw. Three days later, security researcher Dirk-jan Mollema published a proof-of-concept (POC) exploit script to GitHub.

Since there are already public POCs out there now, here is mine: https://t.co/ykiCYNiSHM
Requires latest impacket version from GitHub!

— Dirk-jan (@_dirkjan) September 14, 2020

The severity wasn’t lost on the U.S. government, which issued Emergency Directive 20-04 on September 18, 2020, instructing federal agencies to apply the patch for Zerologon within a matter of a few days. The directive was prescient, as researchers at Microsoft tweeted on September 23, 2020 that they had observed Zerologon being “incorporated into attacker playbooks.”

Microsoft is actively tracking threat actor activity using exploits for the CVE-2020-1472 Netlogon EoP vulnerability, dubbed Zerologon. We have observed attacks where public exploits have been incorporated into attacker playbooks.

— Microsoft Security Intelligence (@MsftSecIntel) September 24, 2020

On October 9, the Cybersecurity and Infrastructure Security Agency (CISA) published a joint advisory (AA20-283A) with the Federal Bureau of Investigation (FBI) related to Zerologon. CISA and the FBI observed that advanced persistent threat (APT) actors were exploiting Zerologon as part of a vulnerability chain with other unpatched vulnerabilities to target federal and state, local, tribal, and territorial (SLTT) governments.

Nine days later, a blog post from The DFIR Report detailed how Ryuk, one of the most nefarious ransomware gangs in operation, incorporated Zerologon into its playbook, leveraging it to perform a takeover of a domain controller (DC).

Factoring in all of these developments and recognizing the sheer severity of the flaw, the Tenable Security Response Team crowned Zerologon the number one vulnerability in our 2020 Threat Landscape Retrospective.

Analysis

As part of its initial patch for Zerologon, Microsoft indicated the vulnerability would be addressed “in a phased two-part rollout.” The first phase addressed the underlying vulnerability on two fronts. Firstly, patched DCs will block both Windows-based domain members and non-Windows DCs that are configured to explicitly disable signing/encryption. Secondly, the patch also changes the Netlogon protocol for clients unable to use the required signing/encryption. This change mathematically strengthens the defense against Zerologon, making it exponentially more difficult to exploit.

The second phase of Microsoft’s two-part patch rollout relates to a settings change to handle insecure connections from third-party / non-Windows devices that don’t or can’t use the required signing/encryption. The restrictions enforced on Windows-based devices with the August 2020 patch will be enforced on non-Windows devices with the February 2021 patch.

Microsoft originally outlined a series of action items to address Zerologon, which includes:

1. Update: Apply the patch for CVE-2020-1472 for DCs and read-only DCs.
2. Find: Check event logs to identify which of your devices are maintaining vulnerable connections to your systems (Microsoft has provided a script for this).
3. Address: Review logs to identify systems still using a vulnerable secure channel for Netlogon.
4. Enable: Modify the Netlogon Parameters registry key and enable Enforcement mode by setting the FullSecureChannelProtection data value to 1.

The fourth step, enabling Enforcement Mode, was previously something users had to manually enable. However, with the update included in the February 2021 Patch Tuesday release, Microsoft has enabled this setting on Windows DCs by default, irrespective of whether or not users and organizations enabled it prior to this release.

The purpose of this setting is to ensure that DCs will not accept vulnerable Netlogon secure channel connections. This setting can be overridden by adding an account to the Create Vulnerable Connections list. However, please note that usage of this allowlist should only serve as a stopgap measure and not a permanent fix.

Proof of concept

At the time this blog post was published, there were 51 repositories on GitHub hosting PoC code, including exploit scripts for Zerologon.

Solution

As promised, Microsoft completed its two-phase rollout to address Zerologon in the February 2021 Patch Tuesday release. For organizations that have not applied any Patch Tuesday updates since the August 2020 release, applying this month’s release will address both phases.

Considering how quickly Zerologon has become valuable to nation-state threat actors and ransomware gangs, it is imperative that organizations apply these patches immediately if they have not yet done so.

Identifying affected systems

A list of Tenable plugins to identify this vulnerability can be found here. Tenable released a remote check plugin for Zerologon that can be used against DCs to test whether or not they’re exploitable. Please note that this plugin requires disabling the “Only use credentials provided by the user” option under Assessment Settings.

To make things easier for our customers that wish to scan using the remote check plugin, we released a scan template policy for Tenable.io, Tenable.sc and Nessus that configures the necessary settings for the scan to run successfully.

A list of tactical scans available to customers under the scan template settings

Please be advised that the safest way to test whether or not your DC is vulnerable is to leverage the scan template policy or plugin as part of a single target scan, as the configuration change to the “Only use credentials provided by the user” setting will apply to all plugins, which could overwhelm other targeted assets on your network.

Get more information

• Tenable Blog Post for Microsoft's August 2020 Patch Tuesday
• Secura Blog Post for Zerologon
• CISA Emergency Directive 20-04 for Zerologon
• CISA and FBI Joint Advisory for Vulnerability Chaining Using Zerologon
• The DFIR Report Blog Post on Ryuk Ransomware Usage of Zerologon
• Tenable's 2020 Threat Landscape Retrospective Report
• Microsoft Support Article for Zerologon

Join Tenable's Security Response Team on the Tenable Community.

Learn more about Tenable, the first Cyber Exposure platform for holistic management of your modern attack surface.

Get a free 30-day trial of Tenable.io Vulnerability Management.

Despite addressing only 56 CVEs, Microsoft’s February 2021 Patch Tuesday release contains fixes for a number of significant security threats, as well as an elevation of privilege vulnerability disclosed by Tenable’s Zero Day Research team.

Microsoft patched 56 CVEs in the February 2021 Patch Tuesday release, including 11 CVEs rated as critical and 43 rated as important.

This month's Patch Tuesday release includes fixes for .NET Core, .NET Framework, Azure IoT, Developer Tools, Microsoft Azure Kubernetes Service, Microsoft Dynamics, Microsoft Edge for Android, Microsoft Exchange Server, Microsoft Graphics Component, Microsoft Office Excel, Microsoft Office SharePoint, Microsoft Windows Codecs Library, DNS Server, Hyper-V, Windows Fax Service, Skype for Business, SysInternals, System Center, Visual Studio, Windows Address Book, Windows Backup Engine, Windows Console Driver, Windows Defender, Windows DirectX, Windows Event Tracing, Windows Installer, Windows Kernel, Windows Mobile Device Management, Windows Network File System, Windows PFX Encryption, Windows PKU2U, Windows PowerShell, Windows Print Spooler Components, Windows Remote Procedure Call, Windows TCP/IP, and Windows Trust Verification API.

Remote code execution (RCE) vulnerabilities accounted for 37.5% of the vulnerabilities patched this month, followed by elevation of privilege (EoP) vulnerabilities at 21.4%.

Despite the low number of CVEs patched this month, there are several significant patches included in this release.

CVE-2021-24074, CVE-2021-24094, and CVE-2021-24086 | Windows TCP/IP Vulnerabilities

CVE-2021-24074, CVE-2021-24094, and CVE-2021-24086 are a set of three vulnerabilities in Microsoft’s TCP/IP implementation for Windows.

These vulnerabilities were discovered internally by Microsoft researchers. In a blog post detailing their findings, they explain why a functional exploit for the two critical RCE vulnerabilities will be “difficult” to create in the short term. However, they anticipate that exploits for the denial of service (DoS) flaw will be created “much more quickly” and should be expected soon after this release. They strongly encourage customers to apply these patches quickly.

Windows TCP/IP vulnerabilities:

- Internal find at Microsoft
- Not exploited in wild
- Exploit creation for RCE is very difficult
- Pre-patch workaround is deny Source Routing, which is disallowed by default

CVE-2021-24074 CVE-2021-24094 CVE-2021-24086https://t.co/WJLhzqwRVp

— Kevin Beaumont (@GossiTheDog) February 9, 2021

If patching is not feasible at this time, Microsoft has provided a workaround that involves setting the Source Routing Behavior to “drop” requests. Microsoft notes that while IPv4 source routing is blocked by default in Windows, these requests are still processed. This configuration change ensures that the requests are not only dropped, but that they won’t even be processed.

Once patches have been applied, it is important to restore the setting back to its original state using the “dontforward” option.

CVE-2021-24078 | Windows DNS Server Remote Code Execution Vulnerability

CVE-2021-24078 is an RCE flaw within Windows server installations when configured as a DNS server. Affecting Windows Server versions from 2008 to 2019, including server core installations, this severe flaw is considered “more likely” to be exploited and received a CVSSv3 score of 9.8. This bug is exploitable by a remote attacker with no requirements for user interaction or a privileged account. As the vulnerability affects DNS servers, it is possible this flaw could be wormable and spread within a network.

CVE-2020-1472 | Netlogon Elevation of Privilege Vulnerability

CVE-2020-1472 is an EoP vulnerability in Windows Netlogon. Dubbed “Zerologon” by researchers at Secura, who discovered and disclosed the flaw, it was initially patched in Microsoft’s August 2020 Patch Tuesday release, the first of a two-part phased rollout. This month’s Patch Tuesday release contains the second and final patch. For more details about Zerologon, we released a companion blog post earlier today: Microsoft Finalizes Patch for Zerologon to Enable Enforcement Mode by Default.

CVE-2021-1732 | Windows Win32k Elevation of Privilege Vulnerability

CVE-2021-1732 is an EoP vulnerability due to the Windows kernel-mode driver improperly handling objects in memory. EoP vulnerabilities are often used post-compromise, since they require an attacker to first gain a foothold in a vulnerable system. Successful exploitation would elevate the privileges of an attacker, potentially allowing them to create new accounts, install programs, and view, modify or delete data. According to Microsoft, this vulnerability has been exploited in the wild. Kevin Beaumont, a security researcher at Microsoft, noted in a tweet that he worked on a threat analytics report about the vulnerability for Microsoft 365 customers.

I worked on a threat analytics report for Microsoft 365 customers on CVE-2021-1732, a zero day local elevation of privilege vulnerability in Win32k (patch out now). https://t.co/BHx92CVoUC

— Kevin Beaumont (@GossiTheDog) February 9, 2021

CVE-2021-1727 | Windows Installer Elevation of Privilege Vulnerability

CVE-2021-1727 is an EoP vulnerability found in the Windows Installer. According to the Microsoft advisory, this bug has been publicly disclosed and exploitation is considered “more likely.” In order to exploit this vulnerability, a local attacker would need a low-privileged user account, making this a likely candidate for inclusion as part of malicious software. Patches are available for Windows Server, Windows Server Core installations and non-server variants of all currently supported versions of Windows.

CVE-2021-1733 | Sysinternals PsExec Elevation of Privilege Vulnerability

CVE-2021-1733 is an EoP vulnerability in PsExec, a Windows Sysinternals application used for remotely executing processes on systems within a network. The vulnerability was found and reported to Microsoft by David Wells, staff research engineer on Tenable’s Zero Day Research team. Wells wrote about the flaw on the Tenable Tech Blog and notes that “the local privilege escalation vulnerability could allow a non-admin process to escalate to SYSTEM if PsExec is executed locally or remotely on the target machine.” A proof-of-concept for the flaw has been added to the Tenable Github repository.

Tenable solutions

Users can create scans that focus specifically on our Patch Tuesday plugins. From a new advanced network scan, set an advanced filter for Plugin Name contains February 2021 in the plugins tab.

With that filter set, click the plugin families to the left and enable each plugin that appears on the right side. Note: If your families on the left say Enabled, then all the plugins in that family are set. Disable the whole family before selecting the individual plugins for this scan. Here’s an example from March 2019 using Tenable.io:

A list of all the plugins released for Tenable’s February 2021 Patch Tuesday update can be found here. As always, we recommend patching systems as soon as possible and regularly scanning your environment to identify those systems yet to be patched.

Get more information

• Microsoft's February 2021 Security Updates
• Tenable plugins for Microsoft February 2021 Patch Tuesday Security Updates
• Tenable Tech Blog writeup on CVE-2021-1733: Sysinternals PsExec Elevation of Privilege Vulnerability

Join Tenable's Security Response Team on the Tenable Community.

Learn more about Tenable, the first Cyber Exposure platform for holistic management of your modern attack surface.

Get a free 30-day trial of Tenable.io Vulnerability Management.

Nine new vulnerabilities have been identified across several TCP/IP stacks embedded in millions of OT, IoT and IT devices, spurring continued scrutiny of these already vulnerable asset types.

Background

On February 10, researchers at Forescout published a report called NUMBER:JACK, which details nine vulnerabilities discovered across nine open source TCP/IP stacks. The prevalence of these stacks across embedded devices is significant. NUMBER:JACK follows in the footsteps of AMNESIA:33, a previous report by the same researchers that detailed 33 vulnerabilities across four open source TCP/IP stacks, affecting millions of operational technology (OT), internet of things (IoT) and IT devices. NUMBER:JACK adds seven additional vulnerable TCP/IP stacks, and many millions more potentially impacted devices.

Analysis

Of the nine vulnerabilities included in the NUMBER:JACK report, four exist in the same stacks that were examined during the AMNESIA:33 research (highlighted in bold below). The nine vulnerabilities are identified as follows:

Flaw stems from weakness in TCP/IP Initial Sequence Number (ISN) generation

All nine vulnerabilities are linked to the same type of flaw: a weakness in the TCP/IP protocol’s generation of the Initial Sequence Number (ISN), a 32-bit randomly generated number that is used when establishing a new session. The purpose of the randomization is to ensure connection to the intended device and to prevent an attacker from being able to tamper with an existing connection.

Historical research into sequence number attacks

These findings are the latest in decades worth of research surrounding attacks against sequence numbers. One of the earliest was first published in 1985 by Robert T. Morris. There have been subsequent pieces of research into these types of attacks covered in requests for comments (RFCs) such as RFC1948 and RFC6528.

It appears the flaws identified in NUMBER:JACK are the result of several implementations not adhering to the guidance outlined in these RFCs as well as the usage of a poor pseudorandom number generator (PRNG) algorithm.

NUMBER:JACK vulnerabilities are limited in impact, but far easier to identify

Unlike AMNESIA:33, which included several critical memory corruption flaws, the vulnerabilities identified in NUMBER:JACK are less critical, which is why none of them received a CVSSv3 score of greater than 7.5. However, despite the lack of criticality, the flaws are much easier for attackers to identify, making them more likely to be exploited.

An attacker that is able to exploit these flaws could cause a denial of service against a vulnerable device, perform an authentication bypass or malicious code injection.

Proof of concept

At the time this blog post was published, there was no proof-of-concept (PoC) code for any of the nine vulnerabilities identified in NUMBER:JACK.

Solution

Each of the maintainers/vendors of the TCP/IP stacks identified through this research were notified of these flaws in October 2020. The following table contains the list of the stacks, their vulnerable versions and fixed versions if available.

Merely identifying these vulnerabilities is just a small part of the broader challenge when dealing with vulnerabilities inside of embedded libraries. The primary issue is about identifying and addressing the underlying assets affected. There are potentially millions of devices from hundreds of vendors across the world that have utilized any one of these TCP/IP stacks. More important than the availability of any given patch is to identify the manufacturers of impacted devices so they can adequately deploy those patches and protect their users.

Identifying affected systems

A list of Tenable plugins to identify these vulnerabilities will appear here as they’re released.

Get more information

• NUMBER:JACK Report PDF

Join Tenable's Security Response Team on the Tenable Community.

Learn more about Tenable, the first Cyber Exposure platform for holistic management of your modern attack surface.

Get a free 30-day trial of Tenable.io Vulnerability Management.

Building a precise inventory of existing assets across your attack surface is essential for effective vulnerability management. Here's how the asset detection process in Nessus scanners can help.

Compiling a complete asset inventory has always been a prerequisite for effective core vulnerability management (VM). With the attack surface continuously growing in size and complexity, it is more critical than ever that you identify all the assets in your network — not just your core IT assets but also any assets related to operational technology (OT) as well as any "shadow IT" assets. Any assets that are not properly managed pose additional risk.

Once you've identified all your assets, you need visibility into each of them in order to gather accurate information to assess your risk. Most vulnerability checks rely on publicly available information regarding the specific platforms and versions affected. Therefore, the accuracy of these checks depends on precise platform, software, version and patch information coming from the assets. 

While the Nessus scanner is well known for its ability to detect vulnerabilities, its capabilities to retrieve inventory information from the network may be slightly less known. However, the impact of these capabilities is substantial for:

1. increasing asset visibility and revealing blind spots;

2. core vulnerability management (VM), which heavily relies on the data points such as installed software and version; and 

3. risk-based VM (RBVM), precisely computing cyber exposure metrics for Lumin.


For Lumin metrics such as Asset Criticality Rating (ACR), the impact of asset inventory information is direct, as ACR is computed based on device type and capabilities. Other metrics, such as Asset Exposure Score (AES), rely on core VM information, and consequently on asset inventory information too.

Asset Detection in Nessus Scanners

Asset detection in Nessus scanners is performed by a number of Nessus plugins. While the vast majority of plugins (+95%) focus on vulnerability coverage, asset detection relies on accurate information about the host, which is retrieved via specialized plugins (most of them INFO severity). Note that Nessus scanners mainly focus on the IT space, including shadow IT assets, while OT assets are covered by other Tenable products, such as Tenable.ot.

The asset detection process is logically structured in four main phases, as shown in Figure 1: port scanning; service and protocol detection; software detection; and OS fingerprinting. These are logically sequential and performed by multiple plugins, which produce outputs that are consumed in subsequent phases. However, there may be some overlap between phases (some plugins for protocol detection may run at the same time as some plugins for software detection).

Figure 1: Nessus asset detection phases and outputs

The four phases of asset detection involve:

1. Port scanning: the Nessus scanner pings the host in different ways, retrieves the open ports and determines whether the scan should proceed.

2. Service and protocol detection: Nessus probes the open ports, looking for listening services and known protocols.

3. Software detection: the main goal is to list the different apps, their versions and patches available in the host.

4. Finally, with all the information coming from previous phases, Nessus tries to determine the OS and version of the remote host.


In the following sections, we describe the particular phases and the main families and plugins involved.

Port scanning 

A Nessus scan starts by checking if a given host is alive and, if that's the case, listing the ports that are found open. The Ping Remote Host plugin (10180) is usually the first plugin to run in a Nessus scan (although it can be disabled) when trying to determine if a given hostname or IP corresponds to a live target. If this plugin receives no response from the target, the host is marked as dead and the scan stops. Otherwise, Nessus will try to perform port scanning with a number of plugins from the port scanners family, which can be done remotely or locally (if credentials are available). Finding open ports is a critical step for any network scanner as it will enable subsequent service discovery and probing as well as further communication with the remote host.

Before continuing with the scan, Nessus checks if the host is likely to be a "fragile" asset, such as a printer or an OT device, which may be negatively affected by the large number and variety of requests that active scanning sends to a target. For this reason, a feature is enabled by default that protects fragile devices. "Stopper plugins," such as 22481 and 11933, will cancel the scan if a fragile device is detected.

Figure 2: Nessus port scanning phase

Service and protocol detection 

From the list of host open ports, the scanner performs service and protocol detection, mainly through plugins from the service detection family.

Service detection plugins (mainly plugin 22964) probe the open ports and analyze the response to determine which services are running on the remote host. Information regarding known and unknown services (e.g., service banner, service version or SSL encaps) is stored to be used by downstream plugins.

Subsequently, and based on the detected services, the scanner probes for specific protocols and their versions. These include HTTP (10582, 10107), SSL / TLS (21643), SSH (10267), Telnet (10280), SMB (10394, 10150), SNMP (40448) and SMTP (10263), among many others. Note that there are a couple of special cases here: part of the SMB and SSH probing takes place right after ping host, as these two protocols can be used for credentialed scans (and having these will enable local port scanning).

Figure 3: Nessus service detection phase

Software detection

Based on the information gathered about available protocols and services, the Nessus scanner will then try to detect specific apps, their versions, patches and additional information on the remote host. These detections can be classified into three main types: 

1. local detections, based on credentialed access and local system information; 

2. remote detections, probing and fingerprinting specific protocols and services; and

3. combined detections, which rely on both local and remote means to identify. 


It is worth noting that credentialed detections have a better chance of being successful and will provide more complete and reliable information than uncredentialed ones.

Local Detections

In the case of credentialed scans, the scanner runs a number of "local enumerators" for supported operating systems (Windows and Unix-based). The mission of these is to obtain information about general characteristics of the system, including installed patches and software (13855, 97993, 83991) as well as processes and services (110483, 70329). Subsequent plugins can pull this information for particular detections or other checks. We'll be able to see this better with a couple of specific examples, one for Windows and one for a Unix-based OS.

First, let's consider the case of a typical Windows local detection, for example for the Zoom client (118801). This plugin checks for Windows registry information coming from 13855. Depending on the information found there, additional checks will be performed against the registry and the filesystem, to retrieve version information and verify the location of the installation.

Figure 4: Local Zoom Windows detection plugin and dependencies run by Nessus scanners

Now let's consider the case of the local Java detection for Unix (64815). This is a slightly more complicated detection, given the number of different ways Java may be present on a system. In this plugin, a combination of checks are performed, based on filesystem information, package manager data and running processes.

Figure 5: Local Unix Java detection plugin and dependencies run by Nessus

Remote Detections

As mentioned, remote detections rely on probing and fingerprinting. Although not as precise as their local counterparts, remote detections do not require system credentials, and may help reveal blind spots in your network. As an example, we are going to explore remote HTTP-based detections.

HTTP-based detections are probably the most prevalent among remote Nessus detections, given how common web servers, web apps and HTTP communications are. Figure 6 shows an example of the HTTP-based detection of the Apache Web Server (plugin 48204). Here we can see the flow of information coming from the service and protocol detection (e.g., 10582), how additional plugins aggregate information for HTTP servers in general (e.g., 10107, 19689) and the Apache Web server in particular (see also 111465). 

Figure 6: Remote Apache HTTP server detection plugin and dependencies run by Nessus scanners.

Combined Detections

Finally, combined detections pull information from both local and remote sources. For example, Cisco IOS detection (47864) pulls information from remote SNMP plugins (10800, 10969), and also from local enumerators (12634). However, note that most of combined detections are not aggregated into a single plugin, but present separate local and remote detection plugins, such as Weblogic (71642, 71643, 73913) or Apache HTTP Server (48204, 141262, 141394), to name a couple. 

Figure 7: Nessus platform and software information phase

OS Identification 

OS identification is the last step in the asset inventory pipeline, as the scanner considers information gathered from all the previous phases to produce its best guess. As shown in Figure 8, the OS identification plugin (11936) relies on many other plugins and multiple protocols. Each of those plugins can produce their own guess, which has an associated confidence level. These confidence levels are defined on a case-by-base basis and depend heavily on the specific protocol and fingerprints involved.

In the following table, we can see a particular example with four fingerprinting methods. The OS identification plugin will choose the one with the highest confidence (SMB local), and report its guess as the identified OS. 

Source: Tenable

Note that only a subset of the fingerprinting methods may be able to produce an OS guess. For example, an HTTP guess (25247) will only be available if we detect HTTP on the remote host, are able to grab the banner and match a known OS fingerprint in the Nessus plugins. Also, note that different methods may be able to retrieve more detailed information than others: the probabilistic fingerprinter (132935) may be able to guess the base Linux distribution, while the Linux local fingerprinter (25335) can precisely identify the specific distribution, version and build.

Figure 8: Nessus OS identification phase

Summary

Nessus asset inventory capabilities are a foundation stone for both traditional and risk-based vulnerability management. These capabilities are also useful on their own as a means for network inventory and to reveal blind spots. To this end, Tenable releases hundreds of asset detection plugins for new software and hardware yearly, so our customers are able to accurately determine their cyber exposure.

Learn more:

• Four Best Practices for Credentialed Scanning with Nessus

• How to Achieve 20/20 Visibility in Your OT Security

• Four Ways to Improve Nessus Scans Through Firewalls


Your scheduled vulnerability scans may not catch short-lived cloud assets, creating opportunities for cybercriminals to exploit security gaps.  

The elastic nature of cloud environments allows cloud assets to be provisioned and decommissioned dynamically, oftentimes by stakeholders outside of security, such as DevOps, web and e-commerce teams. These short-lived assets present challenges for security professionals trying to achieve visibility to all of their organization's cloud assets. Waiting for a scheduled vulnerability scan once a week is not going to help you catch these ephemeral assets, which can spin up and spin down in a matter of hours, causing security gaps. And these gaps can provide cybercriminals with a host of new opportunities. Dynamic, short-lived cloud assets require an equally dynamic approach to vulnerability scanning.  

Why You Should Not Ignore Short-lived Cloud Assets 

Some of you may ask "since they are so short-lived, do these ephemeral assets post a real threat to my company's overall security posture?" Others may argue that "it is not easy to keep an inventory of these short-lived assets, so we are going to stick with other more measurable assets." The truth is that scheduled vulnerability scans provide you with point-in-time snapshots, leaving considerable exposure for the cloud instances that spin up and spin down between scans.

Many cloud assets are clones of one another. When one asset is exploited for its vulnerabilities, it could have a cascade effect on other copies. Once an asset is exposed, even if it was short-lived, nobody can predict its blast radius before it is decommissioned. 

For example, imagine a service that is part of an autoscaling group. When a peak time for your business hits, this service will autoscale to the necessary size to meet capacity. What if a critical vulnerability exists on this newly deployed service? Then it autoscales up to several hundred instances of this service — with each instance containing that same critical vulnerability. 

As you can see, taking either a "maybe-we-will-get-lucky" or an "ostrich-head-in-the sand" approach to short-lived cloud assets can expose your organization to threats and have a negative impact on the reputation and business you've worked so hard to preserve. 

Using Tenable.io to Protect Ephemeral Assets in the Cloud 

Your security team needs continuous visibility into your cloud workloads and instances, which can evolve multiple times a day. Your vulnerability management program should be designed to fortify dynamic cloud environments for effective security, continuous visibility and reliable IT operations. 

Tenable.io provides a comprehensive vulnerability management approach to help you assess your cloud attack surface by detecting vulnerabilities in your entire cloud stack. Tenable.io cloud connectors for Amazon Web Services (AWS), Microsoft Azure and Google Cloud Platform (GCP) enable near real-time discovery of new short-lived compute asset deployments across your multi-cloud environments. 

In addition, Tenable.io Frictionless Assessment helps you continuously assess your cloud assets in AWS environments for vulnerabilities without the need to deploy scanners or install agents. Frictionless Assessment is especially effective against short-lived cloud assets, helping you avoid blind spots and coverage gaps. With Frictionless Assessment, you can automatically scan your cloud environments for new vulnerabilities as soon as they're identified, enabling you to rapidly assess your cloud assets for the latest software flaws..

With a tailored dashboard and reports, you can easily communicate vulnerability priority information with your business groups, including the teams that rely on short-lived cloud assets.

Learn more

• Find out how Tenable helped Netskope increase its visibility into ephemeral assets in the cloud here.

• See the three biggest challenges affecting cloud security here.

• Learn how to improve cyber hygiene with cloud resource tagging here.

• Find out more about how the shared responsibility model affects your cloud security choices here.