Universal Plug and Play (UPnP), a ubiquitous protocol used by “billions of devices,” may be vulnerable to data exfiltration and reflected amplified TCP distributed denial of service (DDoS) attacks.
Background
On June 8, researcher Yunus Çadirci published an advisory for CallStranger, a vulnerability in the Universal Plug and Play (UPnP) protocol. UPnP is currently managed by the Open Connectivity Foundation (OCF). As its name implies, UPnP is a protocol designed to allow a variety of networked devices to universally communicate with each other without any special setup or configuration.
Because of its ubiquitous nature, UPnP is used by a wide variety of devices, including personal computers, networking equipment, video game consoles and internet of things (IoT) devices such as smart televisions. As a result, Çadirci says this particular vulnerability potentially affects “billions of devices.”
Analysis
CVE-2020-12695 is a server-side request forgery (SSRF)-like vulnerability in devices that utilize UPnP. The vulnerability exists due to the ability to control the Callback header value in the UPnP SUBSCRIBE function.
Image may be NSFW. Clik here to view.Image may be NSFW. Clik here to view.
The SUBSCRIBE function is part of the UPnP standard that allows devices to monitor changes in other devices and services. For example, the PoC published on GitHub shows port 2869 for Microsoft’s Xbox One — which is used to monitor device changes on the network for features like media sharing — as vulnerable.
In order to exploit the flaw, an attacker would need to send a specially crafted HTTP SUBSCRIBE request to a vulnerable device.
An attacker could utilize this vulnerability in the following scenarios:
Intranet device port scanning to gather additional data from trusted assets within an organization’s LAN, bypassing organizational Data Loss Prevention (DLP) standards.
Send large amounts of traffic to arbitrary destinations. Targets flooded by the affected devices could crash under the increased network load, resulting in a denial of service (DoS). This is a result of UPnP attempting to establish a TCP handshake with multiple SYN packets for all Callback values in the SUBSCRIBE request.
Exfiltrate sensitive device data by directing callback information to arbitrary targets.
With the exception of the DoS, these scenarios provide a stealthy method for an attacker to steal data from a compromised network. This sensitive information could potentially open up an organization to further attack.
Proof of concept
The original proof of concept (PoC) created by Çadirci has been added to his GitHub repository.
Solution
Since CallStranger is a protocol-level vulnerability, OCF has made changes to the UPnP protocol specification. Therefore, manufacturers of affected devices are in the process of determining its impact. As a result, we anticipate newly affected devices will be reported and patches will be released over time for devices still receiving product support. Tenable product coverage for this vulnerability can be found in the “identifying affected systems” section below.
At the time this blog post was published, the CallStranger website listed the following operating systems, networking equipment, printers, IoT devices and applications as reportedly vulnerable.
Operating Systems
Vendor/Model
Version
Windows 10
10.0.18362.719
Xbox One OS
10.0.19041.2494
Networking Equipment
Vendor/Model
Version
ASUS
RT-N11
Broadcom ADSL
-
Cisco Wireless Access Point
WAP150 WAP131 WAP351
D-Link
DVG-N5412SP
Huawei
HG255s (HG255sC163B03) HG532e MyBox
NEC AccessTechnica
WR8165N
Netgear
WNHDE111
Ruckus ZoneDirector
-
TP-Link
Archer C50
ZTE
ZXV10 W300 H108N
Zyxel
AMG1202-T10B
Printers
Vendor/Model
Version
Canon Selphy
CP1200
Dell
B1165NFW
EPSON EP, EW, XP Series Printers
-
Hewlett Packard Deskjet, Photsmart and Officejet ENVY
-
Samsung
X4300
Internet of Things
Vendor/Model
Version
Canal Digital ADB
TNR-5720 SX
Belkin Wemo
-
Nokia HomeMusic Media Device
-
Panasonic
BB-HCM735 VL-MWN350
Philips
2k14MTK TV (TPL161E_012.003.039.001)
Samsung
UE55MU7000 (T-KTMDEUC-1280.5, BT - S) MU8000
Siemens
CNE1000
Trendnet
TV-IP551W
Applications
Vendor/Model
Version
ASUS Media Streamer
-
LG Smartshare Media
-
Sony Media Go Media
-
Stream What You Hear
-
Ubiquiti UniFi Controller
-
Identifying affected systems
A list of Tenable plugins to identify this vulnerability will appear here as they’re released. Additionally, the table below lists several Tenable plugins to help identify devices within your network that may have UPnP enabled.
Microsoft continues its streak of patching over 100 CVEs, addressing 129 CVEs in June, including a fix for a new SMBv3 vulnerability dubbed SMBleed.
For the fourth month in a row, Microsoft has patched over 100 CVEs, addressing 129 in the June 2020 Patch Tuesday release. The updates this month include patches for Microsoft Windows, Microsoft Edge, ChakraCore, Internet Explorer, Microsoft Office, Microsoft Office Services and Web Apps, Windows Defender, Microsoft Dynamics, Visual Studio, Azure DevOps and Adobe Flash Player.
CVE-2020-1226 and CVE-2020-1225 | Microsoft Excel Remote Code Execution Vulnerability
CVE-2020-1226 and CVE-2020-1225 are remote code execution (RCE) vulnerabilities in Microsoft Excel. Exploitation of these vulnerabilities could result in arbitrary code execution with the same permissions as the current user. An attacker would need to convince a user to open a malicious Excel file in order to exploit these vulnerabilities.
CVE-2020-1194 | Windows Registry Denial of Service Vulnerability
CVE-2020-1194 is a denial of service (DoS) vulnerability due to the Windows Registry improperly handling filesystem operations. An attacker would need access to the system in order to launch a crafted application to exploit this flaw. While the details on this vulnerability are vague, Microsoft notes that the patch corrects how the Windows Registry handles filesystem operations and only allows the tracing to be captured under the default path.
CVE-2020-1284 | Windows SMBv3 Client/Server Denial of Service Vulnerability
CVE-2020-1284 is a DoS vulnerability that exists due to the manner in which the Microsoft Server Message Block 3.1.1 (SMBv3) protocol handles certain requests. This flaw can be exploited on an authenticated server or against an SMB client. Successful exploitation of this vulnerability will cause the target system to crash. An authenticated attacker would need to send a specially crafted packet to exploit this vulnerability against a vulnerable SMB server. To target an SMB client, an attacker would need to host a maliciously configured SMBv3 server and convince the client to connect to it.
CVE-2020-1206 | Windows SMBv3 Client/Server Information Disclosure Vulnerability
CVE-2020-1206, dubbed SMBleed, is an information disclosure vulnerability in Microsoft Server Message Block 3.1.1 (SMBv3) protocol due to the way it handles certain requests. Successful exploitation of this vulnerability could lead to information disclosure from a target system which could reveal further attack vectors. Exploiting this vulnerability on a server would require an unauthenticated attacker to send a specially crafted packet to the target SMBv3 server. Exploiting this vulnerability against a vulnerable SMB client would require an attacker to host a maliciously configured SMBv3 server and convince the client to connect to it.
CVE-2020-1301 | Windows SMB Remote Code Execution Vulnerability
CVE-2020-1301 is an RCE vulnerability in Microsoft Server Message Block 1.0 (SMBv1) protocol due to the way it handles certain requests. Successful exploitation of this vulnerability could allow an attacker to execute arbitrary code on a target system. Exploitation of this vulnerability would require the attacker to be authenticated and send a specially crafted packet to the target SMBv1 server.
CVE-2020-1286 | Windows Shell Remote Code Execution Vulnerability
CVE-2020-1286 is an RCE vulnerability due to the Windows Shell not properly validating file paths. An attacker could exploit this flaw to execute arbitrary code on a host, subject to the privileges of the current user account. An attacker must entice a user to open a specially crafted file or visit a malicious website designed to exploit this vulnerability.
CVE-2020-1208 and CVE-2020-1236 are RCE vulnerabilities in the Windows Jet Database Engine due to improper handling of objects in memory. Successful exploitation of this vulnerability could execute arbitrary code on a target system. Exploitation of this vulnerability would require an attacker to convince a victim to open a specially crafted file or visit a malicious website.
CVE-2020-1248 is an RCE vulnerability found in the Windows Graphics Device Interface (GDI). The flaw is a result of how GDI handles objects in memory and would allow an attacker to take control of an affected system. Microsoft rates the flaw as “Exploitation Less Likely” and notes that an attacker would need to convince a user to open a crafted file or visit a malicious website in order to exploit this vulnerability.
CVE-2020-1213, CVE-2020-1214, CVE-2020-1215, CVE-2020-1216, CVE-2020-1230, and CVE-2020-1260 are RCE vulnerabilities due to the way that the VBScript engine handles objects in memory. Exploitation of these vulnerabilities could result in arbitrary code execution with the same permissions as the current user. There are multiple scenarios where an attacker could exploit these flaws. They include convincing a user to visit a malicious or compromised website, or open a malicious Microsoft Office document.
CVE-2020-1181 | Microsoft SharePoint Server Remote Code Execution Vulnerability
CVE-2020-1181 is an RCE vulnerability found in Microsoft SharePoint Server. The vulnerability exists in the way that SharePoint Server mishandles ASP.net requests, allowing an authenticated attacker to execute code as the application’s pool process. The attacker would need to invoke a malicious page from the SharePoint server in order to exploit this vulnerability.
CVE-2020-1300 | Windows Remote Code Execution Vulnerability
CVE-2020-1300 is an RCE vulnerability that exists in Microsoft Windows due to improper handling of cabinet files. Successful exploitation of this vulnerability could allow an attacker to execute arbitrary code on a target system. Exploitation of this vulnerability would require an attacker to convince a victim to open a specially crafted cabinet file or alternatively spoof a network printer and convince a user to install a malicious cabinet file by disguising it as another file, such as a printer driver.
Tenable solutions
Users can create scans that focus specifically on our Patch Tuesday plugins. From a new advanced scan, in the plugins tab, set an advanced filter for Plugin Name contains June 2020.
Image may be NSFW. Clik here to view.
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 Tenable.io:
Image may be NSFW. Clik here to view.
A list of all the plugins released for Tenable’s June 2020 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.
Three months after an out-of-band patch was released for SMBGhost, aka EternalDarkness (CVE-2020-0796), researchers disclosed two new flaws affecting Microsoft’s Server Message Block (SMB) protocol, including working proof-of-concepts.
Background
As part of Microsoft’s June 2020 Patch Tuesday release on June 9, researchers disclosed two new vulnerabilities in Microsoft Server Message Block (SMB), a protocol used to facilitate the sharing of files, printers and serial ports between computers.
In September 2011, Microsoft initially announced plans to release Server Message Block version 2.2. However, after reviewing all the changes, they decided that marking this release as a minor revision “doesn’t do justice [sic] the work that has gone in.” As a result, Microsoft announced in April 2012 that SMB version 2.2 would now be referred to as Server Message Block version 3.0 (SMBv3) as part of Windows 8 and Windows Server 2012.
SMB version 3.1.1 is the latest iteration of SMBv3, which was released in May 2015 as part of Windows 10 and Windows Server 2016.
Analysis
SMBGhost Inadvertently Revealed
On March 12, Microsoft published an out-of-band advisory for CVE-2020-0796, a remote code execution (RCE) flaw in SMBv3 that was inadvertently revealed in Microsoft’s March 2020 Patch Tuesday release. Within one day, security researchers from KryptosLogic and SophosLabs published proof-of-concept (PoC) scripts that could trigger a blue screen of death (BSoD) on vulnerable systems. At the time there was an expectation that a PoC achieving RCE would be released.
Gaining RCE using CVE-2020-0796
In April, a report from researchers at Ricerca Security states they were able to construct a PoC for CVE-2020-0796 to gain RCE. However, the researchers opted not to publicly share their script to “avoid abuse,” instead offering it to their paying customers.
At the end of May, a researcher known by the pseudonym “chompie” published a tweet that showed a working PoC for CVE-2020-0796 capable of gaining RCE.
Image may be NSFW. Clik here to view.
One day later, chompie decided to publicly release their PoC for “educational purposes” with the expectation that ZecOps would be publishing a PoC of their own “in the coming days.” The researcher stressed that the PoC “needs some work to be more reliable.”
Image may be NSFW. Clik here to view.
Wait and SMBleed
On June 9, Microsoft released an advisory for CVE-2020-1206, an information disclosure vulnerability in SMBv3 due to an issue in handling compressed data packets. It was discovered and disclosed by researchers at ZecOps, who have dubbed the flaw “SMBleed.”
SMBleed builds on previous research surrounding SMBGhost. ZecOps published a blog post at the end of March that included a PoC for gaining local privilege escalation using SMBGhost. In their latest blog post, ZecOps says the SMBleed vulnerability exists in Srv2DecompressData, which is “the same function as with SMBGhost.” It is likely that they identified SMBleed during their analysis of SMBGhost.
SMBleedingGhost: Achieving RCE with SMBleed and SMBGhost
ZecOps cautions that unauthenticated exploitation of SMBleed, while possible, is “less straightforward.” As a result, they combined both SMBleed and SMBGhost to gain unauthenticated RCE. They’ve not yet provided technical details about chaining the two flaws together. However, they did share a PoC as well as a GIF that shows them gaining RCE.
In our blog for CVE-2020-0796, we alluded to the potential similarity between SMBGhost and EternalBlue (CVE-2017-0144), an RCE vulnerability in SMBv1 that was used as part of the WannaCry attacks in 2017. The comparison was clear to many, so much so that CVE-2020-0796 was initially dubbed EternalDarkness by security researcher Kevin Beaumont, in addition to its SMBGhost moniker. However, since the vulnerability only affects SMBv3, its potential for a WannaCry-level impact was mitigated by the fact that the flaw only resides in specific versions of Windows, such as Windows 10 and Windows Server 2016.
SMBLost In Space
In addition to SMBleed, Microsoft also released an advisory for CVE-2020-1301, an RCE vulnerability in SMBv1 due to an improper handling of a specially crafted SMBv1 request. The vulnerability was disclosed to Microsoft by researchers at Airbus’ cybersecurity division.
On June 9, Airbus published a blog post by vulnerability researcher Nicolas Delhaye, detailing their discovery of CVE-2020-1301, which they’ve dubbed SMBLost.
Unlike SMBGhost and SMBleed, SMBLost is more akin to EternalBlue because it impacts SMBv1. However, as Delhaye notes in his blog, SMBLost is “much less harmful” than SMBGhost and EternalBlue due to two mitigating circumstances:
SMBLost is post-authentication (valid credentials), whereas SMBGhost and EternalBlue are pre-authentication (no credentials).
The presence of a shared partition on the vulnerable SMBv1 server (e.g. “c:\” or “d:\”) is required for exploitation, which Delhaye notes is “less common.”
Airbus provided a proof of concept for SMBLost in their blog, which results in denial of service (DoS) by way of a BSoD.
As a caveat, the blog post mentions that using SMBLost to gain RCE “seems conceivable,” but they believe it will be “difficult to make it reliable.” In the case of SMBGhost, a similar situation occurred where the only PoCs to emerge initially were for a DoS and Local Privilege Escalation (LPE). While there is no RCE currently available for SMBLost, it is possible that determined researchers or attackers could find a way to develop a reliable PoC to gain RCE in the near future.
The following versions of Microsoft Windows and Windows Server are affected.
CVE-2020-1206
Product
Version
Windows Server
Version 1903 (Server Core Installation)
Version 1909 (Server Core Installation)
Version 2004 (Server Core Installation)
Windows 10 1903
32-bit Systems
ARM64-based Systems
x64-based Systems
Windows 10 1909
32-bit Systems
ARM64-based Systems
x64-based Systems
Windows 10 2004
32-bit Systems
ARM64-based Systems
x64-based Systems
CVE-2020-1301
Product
Version
Windows Server
2008 for 32-bit Systems Service Pack 2
2008 for 32-bit Systems Service Pack 2 (Server Core installation)
2008 for Itanium-Based Systems Service Pack 2
2008 for x64-based Systems Service Pack 2
2008 for x64-based Systems Service Pack 2 (Server Core installation)
2008 R2 for Itanium-Based Systems Service Pack 1
2008 R2 for x64-based Systems Service Pack 1
2008 R2 for x64-based Systems Service Pack 1 (Server Core Installation)
2012
2012 (Server Core Installation)
2012 R2
2012 R2 (Server Core Installation)
2016
2016 (Server Core Installation) 2019
2019 (Server Core Installation)
Version 1803 (Server Core Installation)
Version 1903 (Server Core Installation)
Version 1909 (Server Core Installation)
Version 2004 (Server Core Installation)
Windows RT
8.1
Windows 7
32-bit Systems Service Pack 1
x64-based Systems Service Pack 1
Windows 8.1
32-bit Systems
x64-based Systems
Windows 10
32-bit Systems
x64-based Systems
Windows 10 1607
32-bit Systems
x64-based Systems
Windows 10 1709
32-bit Systems
ARM64-based Systems
x64-based Systems
Windows 10 1803
32-bit Systems
ARM64-based Systems
x64-based Systems
Windows 10 1809
32-bit Systems
ARM64-based Systems
x64-based Systems
Windows 10 1903
32-bit Systems
ARM64-based Systems
x64-based Systems
Windows 10 1909
32-bit Systems
ARM64-based Systems
x64-based Systems
Windows 10 2004
32-bit Systems
ARM64-based Systems
x64-based Systems
Microsoft released patches for SMBleed and SMBLost as part of their June 2020 Patch Tuesday release. It is also noteworthy that Microsoft provided patches to address SMBLost for Windows 7 and Windows Server 2008, both of which reached the end of their support cycle in January 2020. Tenable strongly recommends applying these patches as soon as possible.
If upgrading is not feasible to address both SMBleed and SMBGhost, Microsoft has recommended disabling SMBv3 compression.
Image may be NSFW. Clik here to view.
Once upgrading is feasible and patches have been applied, Microsoft recommends removing the SMBv3 workaround.
While the mitigating circumstances make SMBLost less impactful than SMBGhost and EternalBlue, researchers are clearly poking around the SMB protocol, hunting for vulnerable code. Be diligent about applying patches, and if you haven’t already, disable SMBv1 as soon as possible.
Identifying affected systems
A list of Tenable plugins to identify these vulnerabilities will appear here as they’re released.
In the last of our three-part series, Tenable Research evaluates the prevalence of vulnerabilities across the global population, as well as the implications of those findings on attackers' economic incentives.
This is the third and final installment of our blog series on persistent vulnerabilities and their causes. The new report from Tenable Research seeks answers to the following research questions:
Do the characteristics of vulnerabilities affect their persistence? Or, is persistence merely related to the remediation process and its pace?
Are there vulnerability remediation differences between organizations? And, are there differences within each organization?
Our previous articles detailed the methodology and key findings behind this research, as well as the lifespan of vulnerabilities within a given organization. In this post, we examine remediation trends across organizations to understand how vulnerabilities persist throughout the global asset population. We conclude with a reflection on how the security community can reduce attackers’ economic incentives by rooting out prevalent vulnerabilities.
Persistence 101: How to identify enduring vulnerabilities
The main objective of remediation is to minimize the exposure to vulnerabilities, especially the ones representing the highest risk. When a vulnerability is either lagging behind in remediation or has a low remediation rate overall (see Figure 1), we talk about persistence. Here, we focus on exploitable vulnerabilities and include a prevalence measure (i.e., To what degree must a vulnerability exist across the global user and asset population to make it a viable and attractive target for attackers?).
The level of risk that vulnerabilities pose to organizations fluctuates. The faster the assessment and remediation cycle within an organization, the better it can properly manage risk. Figure 1 shows the timelines associated with seven exploitable vulnerabilities.
Image may be NSFW. Clik here to view.
Figure 1. Example of individual vulnerabilities remediation timelines
We see Adobe CVE-2018-4988 has the fastest remediation pace and reached 81 percent remediation overall. We also clearly see an outlier in the Oracle WebLogic Server CVE-2018-2628, which consistently carries a delay in remediation over time. Another outlier is the dnsmasq heap buffer overflow CVE-2017-14491, which does not have a large delay initially, but only reaches 53 percent remediation after over a year. These two are considered persistent vulnerabilities.
High outliers indicate wide variance across organizations
Figure 2 shows the distribution of remediation data. A large increase in variability over time points to a huge disparity in the remediation pace across organizations and the longtail difficulties of remediation. The dispersion grows at a phenomenal rate over time, as the median time to remediate 75 percent of instances of a vulnerability globally is higher than tenfold the median to reach 25 percent. It is also shown by the overlap in successive levels. Many vulnerabilities reach a 50-percent and even 75-percent overall remediation rate before others reach 25-percent. Let’s take a look at the outlier sets and their characteristics.
Image may be NSFW. Clik here to view.
Figure 2. The distribution of remediation data
Image may be NSFW. Clik here to view.
Client-side vulnerabilities are among the most persistent threats
Vulnerabilities in the outlier sets are mainly client-side vulnerabilities, as shown in Table 1.
Image may be NSFW. Clik here to view.
Table 1. List of top affected products in outlier sets
This suggests either a bias toward server-side vulnerabilities or user engagement difficulties. Given that most attacks on enterprise networks are the result of successful spear phishing or web attacks,1 this gap in managing client-side vulnerabilities must be closed.
Figure 3 shows the distribution of exploitability in the persistent set. Over 60 percent of the client-side persistent vulnerabilities were exploited in the wild.
Image may be NSFW. Clik here to view.
Figure 3. Distribution of exploitability
Oracle WebLogic constitutes another big source of outliers. The reason, in this case, might simply be the complexity involved in patching and upgrading WebLogic, which can be a lengthy process with varying requirements. But, it might also be related to the network setup, other countermeasures or the type of asset – for example, production assets may undergo systematic fixes while development assets remain unaddressed until the next major upgrade.
Characteristics of exploitable persistent vulnerabilities
Table 2 shows the main characteristics of the exploitable persistent set.
Image may be NSFW. Clik here to view.
Table 2. High-level characteristics of the exploitable persistent set
The prevalence of high-severity, low-attack-complexity and exploited-in-the-wild vulnerabilities among this persistent set confirms issues in prioritization pointed out in part two of this series. That is, defenders are not dealing with higher-risk vulnerabilities faster than other vulnerabilities.
In reality, defenders haven’t had the proper tools to prioritize and monitor attackers’ actions and the threat landscape. On the other hand, issues in prioritization might also be a result of additional environmental and human factors hindering remediation performance. In the next section, we look at some of these additional aspects, including whether fast-remediating organizations fare any better with regard to highly prevalent persistent vulnerabilities. Figure 4 illustrates the overall prevalence of the persistent vulnerabilities in the data set.
Image may be NSFW. Clik here to view.
Figure 4. Overall prevalence of persistent vulnerabilities
Prevalent vulnerabilities affect even high-performing organizations
Most organizations are falling behind in the remediation race (i.e., not closing as many vulnerabilities as were opened in a given timeframe). We measured the pace in our sample by calculating the average number of open and closed vulnerabilities in the assessment and remediation windows for all vulnerabilities.
Results show that only 5.5 percent (Figure 5) of organizations have achieved a remediation rate higher than their assessment rate.
Image may be NSFW. Clik here to view.
Figure 5. The distribution of remediation pace across organizations
The question we’re asking here is: What does the prevalence of persistent vulnerabilities look like across different pace profiles? Figure 6 shows most of the persistent vulnerabilities are still prevalent among the top performers, as compared to the overall data in Figure 4, indicating that higher remediation capacity and pace has little effect on those vulnerabilities’ persistence.
Image may be NSFW. Clik here to view.
Figure 6. Prevalence of persistent vulnerabilities among top performers
This suggests a different answer to our first research question: while vulnerability characteristics are not related to localized persistence, they do play a role in cases of global persistence.
Larger software footprints likely mean greater persistence and prevalence
The most prevalent persistent vulnerabilities (CVE-2018-8353, CVE-2018-8355 and CVE-2018-8373) are a set of remote memory-corruption vulnerabilities, affecting multiple versions of Internet Explorer, which could allow remote attackers to execute arbitrary code. Exploitation in the wild of CVE-2018-8373, for instance, was spotted just a day after Microsoft’s July 2018 Patch Tuesday, long before its NVD publication date.
So, why is this vulnerability both persistent and prevalent across the board? It is most likely related to the list of CPEs or affected software configurations. The more operating systems and product versions the vulnerability affects, the harder it is to fix, leading to persistence.
As a matter of fact, the outlier set has an average of 14.8 CPEs, compared to an average of 8 CPEs in the top 100 most swiftly remediated vulnerabilities (i.e., within 20 days). A longer list of CPEs would also reflect a larger volume of assets in many cases, as shown in Figure 4 and 6, and consequently a higher difficulty to remediate comprehensively.
Economic incentives are key to an effective defense
Another key factor to consider when evaluating remediation behavior and priorities is whether the strategies in place reduce economic incentives for attackers. Attackers are economically driven; they seek to reduce cost and increase revenue by exploiting prevalent vulnerabilities. Studies have already suggested that attacker economic incentives should be considered for defensive strategies.2 3
One can argue that the prevalence of vulnerabilities is a much more interesting indicator of risk than the number of vulnerabilities present on a system. Attackers are slow to introduce new vulnerabilities into their toolkits and they tend to use existing vulnerabilities if there are enough vulnerable systems. Organizations might find it useful to think about the security of the whole community, and even rethink their own remediation behavior and priorities to reduce the economic appeal of vulnerabilities by reducing their prevalence. Increasing the costs and decreasing revenue may effectively deter the development and deployment of attacks.
Conclusion: Bringing prioritization into your remediation strategy
As we’ve discussed, our analysis shows that exploitable and higher-risk vulnerabilities are not remediated faster than any other vulnerability. To improve this, organizations need better prioritization methods that incorporate components like threat intelligence and asset criticality. The industry needs to step up and provide tools and resources for organizations to effectively reduce risk.
Data-driven insights are critical for determining the real risk that vulnerabilities present to an organization. Tenable has a 4.5-petabyte data lake of threat, vulnerability and asset information it analyzes to predict vulnerability priority, asset criticality and identify key maturity metrics to drive process improvement. Predictive Prioritization combines Tenable-collected vulnerability data with third-party vulnerability and threat data and analyzes them to identify the vulnerabilities with the highest likelihood of exploitation within the short term future.
By leveraging these kinds of tools, organizations can opt out of the remediation race and finally gain ground against cyberthreats, by focusing on the risks that matter most.
Tenable Research discovered multiple vulnerabilities in Plex Media Server, a popular media streaming and sharing service, that could allow attackers to gain full system privileges and access to personal files. Plex has since administered patches and mitigations for these vulnerabilities.
Background
Tenable Research has disclosed three vulnerabilities in Plex Media Server, affecting versions prior to 1.18.2. The Plex application and service allows users to organize and stream their own media through a Netflix-like experience. Users can share personal media libraries among friends and discover related content from traditional streaming sources around the web. This type of service is very popular as people are homebound due to public health orders.
Vulnerabilities
CVE-2020-5742
This vulnerability is due to a weak cross-origin resource sharing (CORS) policy. The attacker would likely exploit this vulnerability through phishing. Since Plex users often share their media by way of email notifications, these phishing attempts may see higher than average success rates. After clicking through to the login screen, users cannot tell if they’re logging into their own Plex server or the attacker’s. Once the victim has logged into the attacker’s media server, the attacker can forge requests to the victim’s media server. For example, the attacker could download a private photo album from the victim’s server. This vulnerability impacts Windows, macOS and Linux versions.
Image may be NSFW. Clik here to view.
CVE-2020-5741
Once a Plex user’s media server is exposed due to CVE-2020-5742, the attacker obtains access to an admin authentication token that would allow them to execute arbitrary code remotely with the same privileges as the media server. From there, the attacker could pivot to other machines on the network or install backdoors. This vulnerability impacts Windows.
CVE-2020-5740
This is a local privilege escalation to SYSTEM. Once the attacker has gained code execution, they would be able to exploit this vulnerability to elevate their privileges to the highest level. This vulnerability impacts Windows.
Attack Scenarios
By chaining these three vulnerabilities together, an attacker can move from a successful phishing attack to full SYSTEM privileges. To understand more about the technical details of how an attacker might chain this attack, read here.
With SYSTEM privileges, the attacker would have unlimited access to the underlying operating system and any local files. If the attacker was only able to get far enough in the chain to exploit CVE-2020-5741, they could still access the underlying operating and file system, but their level of access would be limited to the privileges of the compromised account.
Even if the attacker only exploits CVE-2020-5742 via phishing, they would still be able to access any media and services on the Plex media server. This is more concerning than a compromised Netflix account, since users store personal pictures, videos and audio files on Plex.
Vendor Response
Plex has released patches for CVE-2020-5740 and CVE-2020-5741 in a rolling process. Users should update to the latest version to address these two vulnerabilities. Plex Media Server will not automatically update by default but users can enable this within their settings. Users can always check the general settings page to see if new updates are available.
Plex also administered a mitigation for CVE-2020-5742 that alerts users when they are logging into a server that is not hosted by Plex.
Image may be NSFW. Clik here to view.
Tenable has published plugins to detect vulnerable instances of Plex Media Server.
Get More Information:
Visit the Tenable TechBlog on Medium to read more about researcher Chris Lyne's work uncovering these vulnerabilities.
Researchers discovered 19 new zero-day vulnerabilities in a TCP/IP software library developed by Treck. Dubbed Ripple20, the batch includes CVE-2020-11901, which has the potential to take control of an internet-connected device.
Image may be NSFW. Clik here to view.
Researchers discovered 19 new zero-day vulnerabilities in a TCP/IP software library developed by Treck. Dubbed Ripple20, the batch includes CVE-2020-11901, which has the potential to take control of an internet-connected device.
Background
The JSOF research lab, a group of researchers who focus on low-level software vulnerabilities, disclosed 19 vulnerabilities they’ve named “Ripple20.” The batch affects an embedded Internet of Things (IoT) TCP/IP software library developed by Treck Inc., a developer for embedded internet protocols. This library is found in a wide array of devices from over 70 hardware vendors. When exploited, these vulnerabilities could lead to device takeover and allow an attacker to pivot from affected devices to other critical infrastructure. These vulnerabilities follow the disclosure of CVE-2020-10136, an IP-in-IP packet processing vulnerability disclosed earlier this month, which also affects IoT device TCP/IP libraries developed by Treck. Ripple20 also echoes multi-vulnerability disclosures like URGENT/11, which has continued to widen in impact over time.
Analysis
The Ripple20 vulnerabilities exist within the embedded TCP/IP software libraries developed by Treck. These libraries are licensed and used by a broad spectrum of devices manufactured by a number of vendors. JSOF notes that tracking and identifying all of the potentially affected vendors and devices is difficult for both logistical and legal reasons. Their disclosure details just how difficult it was to identify the affected supply chain, as the scope of potential risks was diverse and vast.
CVE-2020-11901 is a DNS vulnerability that would allow an attacker to obtain remote code execution (RCE) on devices redirected to a malicious web address. An attacker would first need to hijack the device’s hostname resolution by either poisoning its DNS server, or spoofing an otherwise legitimate IP address like a device update server. Standard security configurations often allow outbound connections to have fewer restrictions than inbound ones, allowing exploitation of these vulnerabilities to have a larger potential impact.
CVE-2020-11896 and CVE-2020-11897 are vulnerabilities caused by malformed packets being sent to a device that has IP tunneling enabled. JSOF confirmed CVE-2020-11896 on a Digi Connect ME 9210 by sending malformed ICMP echo requests, which allowed JSOF to inject shellcode on the device. An attacker could either obtain consistent RCEs on vulnerable devices, or cause a denial of service (DoS) until the device is reset.
The remainder of the vulnerabilities outlined in the disclosure range from RCE to sensitive information disclosure, creating a wide breadth of risks for unmitigated and unpatched devices.
A full list of CVEs can be found in the table below:
CVE ID
CVSSv3*
Potential Impact
CVE-2020-11896
10
Remote Code Execution
CVE-2020-11897
10
Out-of-Bounds Write
CVE-2020-11901
9
Remote Code Execution
CVE-2020-11898
9.1
Exposure of Sensitive Information
CVE-2020-11900
8.2
Use After Free
CVE-2020-11902
7.3
Out-of-bounds Read
CVE-2020-11904
5.6
Out-of-Bounds Write
CVE-2020-11899
5.4
Out-of-bounds Read
CVE-2020-11903
5.3
Exposure of Sensitive Information
CVE-2020-11905
5.3
Exposure of Sensitive Information
CVE-2020-11906
5
Integer Underflow
CVE-2020-11907
5
Integer Underflow
CVE-2020-11909
3.7
Integer Underflow
CVE-2020-11910
3.7
Out-of-bounds Read
CVE-2020-11911
3.7
Incorrect Permission Assignment for Critical Resource
CVE-2020-11912
3.7
Out-of-bounds Read
CVE-2020-11913
3.7
Out-of-bounds Read
CVE-2020-11914
3.1
Out-of-bounds Read
CVE-2020-11908
3.1
Exposure of Sensitive Information
*CVSSv3 Scores were provided by JSOF and may be subject to change
Proof of concept
JSOF has posted a Proof of Concept video to their YouTube channel demonstrating an attack:
Vendor response
Since September 2019, JSOF, Treck, CERT organizations and security vendors have been working together with hardware vendors to confirm affected devices. Confirming all of the affected devices will take considerable continued effort and time. JSOF has a live list of affected vendors that can be found in the technical section of the disclosure page.
Solution
Users are encouraged to reach out to their device vendors for support and updates if available. For devices that are no longer supported by their manufacturer, users can either upgrade to a supported device, or apply the recommended mitigation steps. Vendors that have already released updates include HP, Bosch, Braun, Caterpillar, GHS and Rockwell.
Users can also potentially mitigate attacks by a multitude of security practices. JSOF provides a list on the disclosure page of potential mitigation options.
Identifying affected systems
A list of Tenable plugins to identify these vulnerabilities will appear here as they’re released.
In a new report, Navy, Air Force and Defense Information Security Agency (DISA) leaders provide insights into managing cyber risk and protecting critical infrastructure. Here is a quick summary.
A recent survey of senior Department of Defense (DoD) cyber officials revealed a consistent focus on delivering accurate and actionable cyber risk information to support “operationally informed risk decisions.”
The Federal News Network (FNN) published the results of this survey in a report titled “Cyber Technologies in DoD: Protecting Core Infrastructure.” Respondents included: Bill Marion, the former Air Force deputy chief information officer; Chris Cleary, the Navy’s first chief information security officer; and Roger Greenwell, the Defense Information Security Agency (DISA)’s risk management executive and chief information officer.
Below, we highlight a few of the most salient quotes that speak to the way these teams are adapting their security approach in response to the rapidly evolving threat landscape.
Streamlining implementation of the Risk Management Framework (RMF)
To start, each of the respondents addressed service-specific measures they’ve taken in implementing the Risk Management Framework (RMF), a set of criteria developed by the DoD to standardize how all federal IT systems are architected, secured and monitored.
Recalling the Air Force’s strategic goal of achieving “cybersecurity that works,” Marion outlined his team’s “risk-informed approach” designed “to empower our senior cybersecurity officials to fuse operational requirements, system forensics and threats to inform risk assessment and tolerance over the system life cycle.”
The Navy, according to Cleary, is pursuing an “RMF reform initiative, which focuses on streamlining the existing RMF implementation process.” This sets out four separate lines of effort that “have spawned improvement initiatives across the spectrum of RMF steps and tasks.” He pointed to automation of the RMF as an emerging area with the potential to deliver significant improvements.
Greenwell pointed to the commercial cloud environment, and the capabilities that it offers, as a primary focus area for DISA as they look to manage the migration of applications to that environment. He cited as a priority the ability of mission partners to better “see and leverage the information within the enterprise assessment and authorization tools for their risk management decisions.”
When it comes to RMF reform, the Army and the National Institute of Standards and Technology (NIST), publisher of the RMF, are thinking along the same lines as these DoD leaders. The FNN report includes a section on the Army’s “Project Sentinel,” which is an effort to “fix RMF authorization bottlenecks.”
The FNN report also provides a summary of NIST plans in support of RMF implementation improvements, including details on the next update to Special Publication 800-53, the document that provides the foundation of the RMF. NIST plans to publish that update, revision 5, later this year. Among other upgrades, revision 5 will include a pivot to online delivery that will allow authorizing officials to select only the controls that apply to the specific cyber problem set they need to solve, in contrast to current practice that requires working through a static, 480-page list of security controls.
Prioritizing risk in policy and investment decisions
In an environment of limited resources, setting priorities is essential in achieving objectives. With that in mind, the respondents unanimously cited effective cyber risk management as a top priority to be considered in developing policy and making investments. Marion cited a “paradigm shift from compliance to a predetermined set of controls, to now making operationally-informed risk decisions” as a major achievement for the Air Force.
Addressing the Navy’s cyber investment strategy, Cleary talked about prioritizing ashore, afloat, and air networks “based on the priorities laid out in the National Defense Strategy and based on cost effectiveness” with the aim of “provid[ing] mission assurance in a cyber-contested environment across critical warfare areas.”
Greenwell sounded a similar note for DISA risk prioritization, focusing on the need to “optimize our investments and bring more powerful capabilities to the warfighter.” He emphasized that DISA was “continuously reviewing the threats, the advancing capabilities of our adversaries and the evolution of technology to prioritize our investments.”
Protecting the expanding attack surface
These cyber leaders were unanimous in their focus on the increasing connectivity of devices never previously exposed to outside intervention. This rapidly expanding attack surface is a key factor driving cyber risk prioritization decisions.
Marion, for example, noted that “as the landscape gets more interconnected and complex, the drive for innovation can create potential seams, which introduce additional risk vectors.” He pointed to studies chartered by the Defense Authorization Act as having provided “extremely valuable insights on the risks to our weapon systems and industrial control systems (ICS).”
Similarly, the US Cyberspace Solarium Commission report included a recommendation that Congress should direct the DoD to conduct a vulnerability assessment of all segments of the nuclear command, control, and communications enterprise and National Leadership Command Capabilities, and to continually assess weapon system cyber vulnerabilities.
Marty Edwards, a former federal cyber official and currently Tenable’s vice president of operational technology (OT) security, applauded this increased focus on the expanded attack surface, noting that “the ability for DoD to view and take action across the board on all devices within their vast array of networks is critical.” He added, “Systems that directly support mission operations are very often closely linked or depend upon ICS and/or OT - and that makes them far more critical to the mission owner in my eyes than most enterprise IT-centric systems."
Report cyber risk, not cyber vulnerabilities
For much of the 21st century, vulnerability management has been largely a CVSS-driven process of identifying known vulnerabilities, patching those vulnerabilities and reporting progress on that patching to organizational decision-makers. One point that came through this survey loud and clear is that senior cyber leaders are no longer only interested in knowing the status of cyber vulnerabilities – they want to understand the cyber risk associated with each vulnerability, in order to make well-informed decisions about how to establish priorities and best protect their most critical assets.
At Tenable, we understand the critical need to deliver actionable cyber risk information to decision-makers, which is why we’ve moved far beyond traditional vulnerability management. The Tenable Risk-Based Vulnerability Management Solution delivers comprehensive, continuous visibility and informs technical and business decisions, enabling you to:
Assess all your assets for vulnerabilities and misconfigurations continuously
Measure the vulnerability’s risk to your business using threat intelligence and asset criticality
Predict which vulnerabilities present the most risk to your organization, so you know what to focus on first
Deliver risk-based information to decision-makers
Tenable’s Risk-Based Vulnerability Management Solution is built upon a five-step Cyber Exposure Lifecycle, which helps you continuously improve your security program. Applying the solution via this lifecycle will help you gain complete visibility into your attack surface and prioritize your remediation efforts based on the 3% of vulnerabilities that pose the greatest risk to your organization– reducing your cyber risk over time.
To learn more about how DoD officials are managing cyber risk, check out the full report from Federal News Network.
50 years after the protests at Stonewall, the fight for LGBTQIA+ equality and racial justice continues. Here’s a reflection from our Pride@Tenable community on the need for intersectional solidarity.
What is Pride? For those of us in the LGBTQIA+ community, Pride symbolizes the fight for equality. Every day we fight to be our authentic selves, to love who we love, and to be treated equally and with respect.
At Tenable, we embrace diversity and inclusivity. We have a variety of communities created through our Diversity and Inclusion Council that allow Tenable employees to openly express themselves, discuss important issues and support each other. Pride@Tenable was first created back in 2019 and was a supporter of the inaugural Howard County Pride Festival near Tenable’s headquarters in Columbia, MD. This year, Pride@Tenable has shifted its focus toward supporting and listening to our Black@Tenable community to fight against racial injustice.
Though Pride may seem like a celebration now, this was not always the case. Pride is, at its core, a protest. A protest to be seen, to be heard, and – most of all – to advocate for our right to live authentically.
The roots of the first Pride protest
Pride traditions started 50 years ago. Before the first Pride march, LGBTQIA+ rights were virtually non-existent. In fact, being LGBTQIA+ was illegal in most countries, including the United States. On June 28, 1969, New York City police raided an LGBTQIA+ bar known as the Stonewall Inn in Manhattan’s Greenwich Village. Fed up with the constant harassment and mistreatment, patrons of the Stonewall Inn waged a six-day battle and protest. Among those on the front lines were many Black and Trans members of the LGBTQIA+ community, including Marsha P. Johnson, a Black, Trans liberation activist and drag queen.
At the core of the Stonewall riots was the intersection of being Black and being LGBTQIA+. So, it is important to show LGBTQIA+ solidarity with the movement for racial justice and equality. Without Black LGBTQIA+ activists championing the fight for equality, we may not have the rights we have today. We should work to understand, and empathize and sympathize with, the Black community, standing together in the fight against injustice and inequality.
One year after Stonewall marked the first gay Pride march, held in commemoration of the rebellion. This was the first time that people of the LGBTQIA+ community vocally advocated for gay rights. The official slogan for that first parade was, “Say it loud, gay is proud.”
A time to celebrate and remember that the fight continues
Today, the goals of Pride events are to underscore that gay rights are human rights and to celebrate the many contributions of LGBTQIA+ people to our society.
It wasn’t until 2015 that gay marriage was legalized in all 50 states. It wasn’t until just a few weeks ago that a landmark U.S. Supreme Court ruling extended the legal protections of the 1964 Civil Rights Act to prohibit discrimination based on sexual orientation and gender identity. The battle for LGBTQIA+ rights is not over. Each day, members of the LGBTQIA+ community face the same troubling reality: to live authentically is to risk being discriminated against. We must constantly question if we may be harassed for being LGBTQIA+, or if our partner will be granted health insurance, or if we will be treated differently in any social encounter.
Pride is part of how we embrace diversity. A variety of backgrounds, experiences and interests makes us stronger as a company and helps us innovate in the cybersecurity industry. To celebrate Pride this year, we scheduled viewing parties and created virtual Pride-themed Zoom backgrounds for all of Tenable so allies and members alike could celebrate together.
As we celebrate Pride, please remember that though we have reasons to celebrate, Pride is a continued fight for human rights – one that should honor the legacy of the Black LGBTQIA+ community. We must stand together. Love always wins and kindness is always wise.
Critical authentication bypass vulnerability in PAN-OS devices could be exploited in certain configurations, which are commonly recommended by identity providers.
Background
On June 29, Palo Alto Networks published an advisory for a critical vulnerability in PAN-OS. PAN-OS is the custom operating system (OS) that Palo Alto Networks (PAN) uses in their next-generation firewalls.
Analysis
CVE-2020-2021 is an authentication bypass vulnerability in the Security Assertion Markup Language (SAML) authentication in PAN-OS. The vulnerability was given a CVSSv3.1 score of 10.0 by Palo Alto Networks. According to their advisory, the flaw exists due to “improper verification of signatures.” An unauthenticated, remote attacker could exploit the vulnerability to obtain access to “protected resources” within a network. The most ideal target, in this case, is Palo Alto Networks’ GlobalProtect VPN.
If you use Palo-Alto firewalls with SAML -- particularly with GlobalProtect VPN -- you probably want to urgently patch this.
Also researchers should probably avoid disclosing details publicly for a window to give orgs time to mitigate.https://t.co/vh18ZgsurC
PAN-OS devices may be configured to use SAML authentication with single sign-on (SSO) for access management. Palo Alto Networks lists the following resources that use SAML SSO as potentially affected by this vulnerability:
The advisory specifies that this vulnerability could be exploited when the following conditions are met:
Prerequisite #1: SAML authentication required.
As implied in the vulnerability description, a device must be configured to use SAML authentication in order to be vulnerable. If the device is not configured to use SAML authentication, it is not vulnerable.
Prerequisite #2: “Validate Identity Provider Certificate” must be disabled.
While these prerequisites may seem uncommon, it appears that notable organizations providing SSO, two-factor authentication, and identity services recommend this configuration or may only work using this configuration. These providers include:
Cybercriminals capitalized on the availability of proof-of-concept (PoC) exploit code for the vulnerabilities and have utilized them in a variety of attacks, from nation-state threats to a rash of ransomware attacks. These flaws have remained popular in 2020, as the Cybersecurity Infrastructure Security Agency lists a few of these flaws as being “routinely exploited by sophisticated foreign cyber actors.”
Several notablesecurityresearchers as well as the United States Cyber Command have warned that CVE-2020-2021 will likely be leveraged by attackers in the near future.
Please patch all devices affected by CVE-2020-2021 immediately, especially if SAML is in use. Foreign APTs will likely attempt exploit soon. We appreciate @PaloAltoNtwks’ proactive response to this vulnerability.
— USCYBERCOM Cybersecurity Alert (@CNMF_CyberAlert) June 29, 2020
Proof of concept
At the time this blog post was published, there was no working PoC code available for this vulnerability. However, we expect a PoC will become available in the near future.
Solution
Palo Alto Networks has released patches for PAN-OS 8.x and 9.0.x and 9.1.x. PAN-OS 7.1 is not affected by this vulnerability. The following table lists the PAN-OS affected and fixed versions.
PAN-OS Version
Vulnerable
Affected Versions
Fixed Versions
7.1
No
-
-
8.0.x
Yes
8.0.0 and greater
-
8.1.x
Yes
8.1.15 and lesser
8.1.15 and greater
9.0.x
Yes
9.0.9 and lesser
9.0.9 and greater
9.1.x
Yes
9.1.3 and lesser
9.1.3 and greater
Tenable strongly encourages patching your PAN-OS devices whether or not your devices have the specific prerequisites required for exploitation.
If upgrading is not feasible at this time, Palo Alto Networks provides several mitigation options. The quickest solution would be to disable SAML authentication altogether and switch to a different authentication method.
Additional mitigation options include:
If available, use a certificate from an identity provider (IdP) that is signed by a certificate authority (CA)
Enable the “Validate Identity Provider Certificate” option
The reason providers suggest disabling the “Validate Identity Provider Certificate” option is because they are using self-signed certificates, which will not work when “Validate Identity Provider Certificate” is enabled. If the provider does offer a CA-signed certificate, it is strongly recommended to use that certificate with the option enabled.
Identifying affected systems
A list of Tenable plugins to identify this vulnerability will appear here as they’re released. Because the vulnerability is configuration dependent, our plugins will detect potentially vulnerable hosts that would then need to be manually confirmed to be vulnerable based on the specific deployment scenarios. With the design of this plugin, 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.
Image may be NSFW. Clik here to view.
Enabling Paranoid Mode
To enable this setting for Nessus and Tenable.io users:
Click Assessment > General > Accuracy
Enable the “Show potential false alarms” option
To enable this setting for Tenable.sc (formerly SecurityCenter) users:
Click Assessment > Accuracy
Click the drop-down box and select “Paranoid (more false alarms)”
As the number of security vulnerabilities continues to skyrocket, prioritization is necessary for organizations to effectively reduce their cyber risk.
For more than two years, I’ve explained to security professionals at all levels that the dramatic increase in vulnerabilities discovered each year, coupled with the expanding attack surface from the emergence of modern networks, has created the perfect storm that has buried them in a proverbial pile of vulnerabilities. In fact, I frequently grab their attention by making a sweeping statement:
“Regardless of your company size, you will never have enough human or financial resources to remediate every vulnerability across your attack surface.”
But this statement is more than just a marketing tagline or cheap ploy for attention. It’s a fact that organizations of all sizes grapple with every single day. Think about it: small companies may only have tens of thousands of vulnerabilities, but they also have a correspondingly small team. In fact, the “team” may consist of one person who manages security on a part-time basis, in addition to other primary responsibilities. On the other end of the spectrum, large enterprises likely have tens of millions of vulnerabilities, outpacing the bandwidth of even a fully-staffed operation of dozens of full-time security analysts spread across multiple teams.
Why legacy methods are no longer sustainable
To break this open, we really only have to ask ourselves, how many vulnerabilities can a single security analyst handle per day? Per week? Per month? Of course, the answer can vary dramatically for each individual vulnerability, but let’s presume that it takes roughly two hours to fully assess a single vulnerability. I believe that’s a fair estimate, considering the fact that when analysts pull a vulnerability, they have little more than a Common Vulnerabilities and Exposures (CVE) entry to begin with.
How does one move from an otherwise meaningless CVE ID to a determination of relative importance to the organization? By investigating numerous public sources for information on the characteristics of the vulnerability and how it works, as well as its current and past prevalence. The investigation may even include sources such as social media sites and chatter on the dark web.
At an average rate of two hours per vulnerability, analysts can only reasonably be expected to assess four vulnerabilities a day, or roughly 80 per month. Even the smallest organization discovers more vulnerabilities than that each month. Looking at it through this lens, it’s easy to see how 81 percent of security teams fall behind in their assessments, with no real hope of catching up.
Focus on the few vulns that pose actual risk
While I stand by the big statement that you’ll never be able to fix everything, the good news is that you don’t have to! In fact, odds are that your team is already staffed enough to remediate everything that truly matters. That’s because, according to Tenable Research, only about 20 percent of vulnerabilities ever have an exploit available, and only a fraction of those are actually ever exploited in the wild.
By understanding your vulnerabilities in the context of business risk, your team can use that data to prioritize its efforts, reducing the greatest amount of risk with the least amount of effort. That means going beyond just Common Vulnerability Scoring System (CVSS) base scores to also include contextual elements such as the criticality of affected assets, continuously updated threat and exploit intelligence and predictive technologies to determine which vulnerabilities are most likely to be exploited in the near future.
Join the elite group of risk-minded security leaders
According to Tenable Research, only 5.5 percent of organizations are gaining ground in their remediation efforts. By taking a risk-based approach to vulnerability management, you can be one of them. Risk-based VM helps you understand vulnerabilities in the context of business risk, so you can focus on the vulnerabilities and assets that matter most. In turn, organizations can focus their remediation efforts on the vulnerabilities that pose the most immediate risk while deprioritizing those that are unlikely to ever be exploited.
Just as Magento 1 reaches end of life, attackers are exploiting a vulnerability in a Magento plugin from 2017. Site owners should prepare to migrate their stores immediately.
Background
On May 17, ZDNet published an article about an FBI flash security alert shared with the private sector regarding attacks against Magento stores. Magento is a popular e-commerce platform used by many companies. There are two separate offerings of Magento: Magento Open Source (formerly known as Magento Community Edition), which is freely available to all users, and Magento Commerce (formerly known as Magento Enterprise Edition), which is the enterprise solution. In May 2018, Adobe announced it would be acquiring Magento Commerce, the company behind Magento.
Since 2016, Magento sites have become the target of a type of attack named Magecart, a name derived from Magento and shopping cart. Magecart attackers inject malicious JavaScript code into legitimate Magento sites in order to steal customer payment card information during online checkout.
Despite the name and initial connection to Magento, Magecart has since become a catch-all term to describe various types of malicious code injections into e-commerce sites with the intention to steal payment card data.
The May 6 FBI alert provides additional information about the recent activity involving Magento and a specific Magento plugin.
Web applications like Magento enable organizations large and small to build e-commerce websites rapidly and fulfill a critical business need. However, such apps also pose challenges in terms of ensuring that these websites are secure from attackers. The modular nature of these web applications, such as the ability to enhance them with plugins or extensions, adds an additional layer of complexity when it comes to securing these websites. Given the nature of web applications, attackers usually don’t need credentials to exploit and the exploits themselves are generally easy to run. Regular scanning using a web application security product can help determine the accurate cyber exposure and help with risk-based mitigation.
Analysis
CVE-2017-7391 is a cross-site scripting (XSS) vulnerability in the Magento Mass Importer (also known as MAGMI or Magmi) plugin for Magento stores. The flaw exists due to insufficient handling of user-supplied input in the prefix parameter for requests made to ajax_gettime.php. The vulnerability was discovered by Haojun Hou of Venustech’s ADLab.
To exploit the flaw, an attacker would need to send a specially crafted request to a Magento site using the vulnerable version of the Magmi plugin. Exploitation of the flaw would allow an attacker to inject arbitrary HTML or javascript code within the browser in the context of the vulnerable application. The SecurityFocus entry for this vulnerability mentions that an attacker would be able to “steal cookie-based authentication credentials and launch other attacks.”
The FBI alert references an example where a United States e-commerce website was exploited using this vulnerability to “successfully retrieve environment credentials,” which were used to download web shells onto the vulnerable site to enable persistence and file uploading capabilities.
The vulnerability was addressed by wrapping the prefix parameter using the htmlspecialchars PHP function that converts reserved characters like ampersands, double quotes, single quotes, less-than and greater-than symbols into their respective HTML/character entities.
Image may be NSFW. Clik here to view.
This fix is supposed to prevent an attacker from injecting script code in requests to the ajax_gettime.php file as part of the prefix parameter.
Magento 1 End of Life
The FBI issuing an alert like this is significant, because it shows that the Magecart attackers are still actively targeting vulnerable Magento sites. To complicate things, Magento announced in 2018 that it would end support for Magento 1 in June 2020. Specifically, the end of life (EOL) for Magento 1 is June 30. This notice provided Magento site owners time to migrate their sites to Magento 2 in anticipation of the EOL.
Magento 1 Receives Last Batch of Security Patches
On June 22, Adobe released ASPB20-41, its final set of security updates for Magento Commerce and Magento Open Source. After June 30, Magento 1 will no longer receive security updates. Therefore, it is imperative for Magento site owners to transition away from Magento 1 as soon as possible. It is likely that attackers may be sitting on vulnerabilities in Magento 1 that they’ve not yet utilized, as they wait for Magento 1 to officially reach EOL before targeting vulnerable sites.
According to the developers of the Magmi plugin, CVE-2017-7391 was addressed in Magento version 0.7.23 of the plugin. However, there is no official “release” page for the plugin. The latest release still shows up as 0.7.22.
Image may be NSFW. Clik here to view.
Therefore, users hoping to retrieve the patched version of the plugin would need to clone the latest version of the plugin’s GitHub repository. Otherwise, their Magento sites will still be vulnerable to CVE-2017-7391.
Whether or not site owners are able to upgrade to the patched version of the Magmi plugin, we strongly recommend taking some preventative measures to help mitigate attacks targeting Magmi by securing its installation:
Apply IP source allowlisting to ensure only specific IP addresses are capable of accessing the Magmi web interface
Use a custom unpredictable folder name instead of the default /magmi path when installing Magmi so attackers can’t easily locate the web interface
Ensure that the conf/magmi.ini file located in the Magmi installation directory is not accessible from the web to avoid sensitive information exposure, for example, using Apache Module mod_access to deny access to .ini files.
Since Magento 1 will no longer receive security updates, administrators and site owners are strongly advised to upgrade to Magento 2 as soon as possible.
Identifying affected systems
To identify the Magmi vulnerability using our Web Application Scanner (WAS), please use Plugin ID 112441.
In addition, Tenable customers will soon be able to utilize our Magento Unsupported Version Detection plugin (Plugin ID 11250) for WAS to identify targets running unsupported versions of Magento.
For critical infrastructure organizations, the gains of automation and IoT technology have also meant heightened threats. These are the steps security directors can take to reduce cyber risk across their industrial operations.
Companies and organizations are inherently risk-averse. Having regular and predictable business cycles, cash flows and monthly recurring revenues is rewarded by investors and stakeholders. When a company takes on risk, the decision is almost always scrutinized with a cost-benefit analysis. While some forms of risk are manageable and others are not, it is incumbent upon organizational leaders to eliminate risk wherever possible and manage the risk that is impossible to eradicate.
Risk management is paramount for organizations that provide “critical infrastructure” services, whose operational technology (OT) ensures the fabric of our national security and modern ways of life. Many countries have independently identified which vertical industries are considered critical in their region. In the United States, the Department of Homeland Security has identified sixteen distinct critical industries that are of strategic importance. As these sectors have modernized their operations in recent decades, the gains in efficiency have also brought new attack surfaces.
How automated systems expose infrastructure to cyber threats
Over the course of the last two months, we have become quite familiar with the term “essential workers” and the risks associated with scaled-down workforces. But this is only part of the critical infrastructure equation. Virtually every vertical in the “DHS-16” also relies on automation to produce and deliver their essential product or service. Everything from generators and turbines to actuators and robots is all controlled by programmable logic controllers (PLC) and the greater OT environment to make things happen. Without their flawless operation, we would not be able to generate electricity, drink clean water or benefit from any of the other critical products or services that define “normal” life.
Risk is constantly changing and critical infrastructure organizations are acutely aware of this. One area that has gained C-level attention in recent years is ensuring the security around OT infrastructure. Whereas two decades ago, boardroom discussions revolved around the security of IT operations, attention has shifted to OT operations because of newly formed attack surfaces and attack vectors. These include the rapid adoption of new technologies such as IT/OT convergence and industrial IoT devices, as well as new threat actors such as malicious (or negligent) insiders or nation-state attacks.
Gaining the upper hand on industrial cyber risk
Despite the increased focus on securing OT environments, critical organizations are still looking for a better approach when it comes to industrial cybersecurity. Fortunately, there are a few steps that every organization can take to reduce risk across their critical infrastructure.
1. Secure the brains of your industrial operations.
PLCs are central to the operation of OT environments. These devices control the pumps and motors and robots that power massive utility and manufacturing plants. Regular programming changes to the PLC may be normal, but they can also result from a programming error or malware that affected an unauthorized change. Automatic “snapshotting” of configuration changes maintains a “last known good state” of your control systems and preserves an audit trail of any changes that are made. Recording this activity, at specific intervals or any time users make a change, is an essential first step in reducing risk around your most critical infrastructure assets.
2. Gain full visibility across your OT Infrastructure.
Siloed organizations that separately deploy IT and OT security leave critical blindspots in their wake. With security incidents such as Lockergoga, attacks are now architected to infect and propagate across the converged IT/OT infrastructure. While most organizations have some visibility into their IT footprint, it is also essential to have a full inventory of OT assets in your environment.
Unlike IT devices which often have a lifespan of 36 months, OT devices can maintain a lifespan of decades. Over that period of time, teams often change, maintenance may become lax and in almost all cases meticulous documentation of things like patches and firmware updates are missed. By deploying industrial-grade security that can view your entire organization’s infrastructure, along with asset inventory down to ladder logic and backplane information, you can eliminate the risk of not knowing the full range of assets you need to protect.
3. Use multiple detection methodologies to identify threats early.
Gaining deep situational awareness of each asset in your environment is crucial to protecting common infiltration points and targets of cyberattacks. It’s equally important to remain vigilant about what is traversing your network, keeping in mind that network traffic and behavior are early warning signs for attacks and attack propagation. Reducing attack risk requires multi-detection capabilities which include policy, anomaly and signature-based detection. Using multiple detection methods can prevent both known and zero-day attacks, while also leveraging the power of the security community to find more threats and thus secure the environment from more attacks earlier.
4. Focus remediation efforts on critical assets and actual exploits.
Whichever OT vendors are present in your infrastructure, chances are you’ll see many vulnerabilities announced over their product lifetimes. In fact, critical infrastructure organizations often operate with hundreds of thousands of vulnerabilities at any given time! It can be unmanageable and impractical to track and remedy all of those vulnerabilities with new ones being announced every day.
The good news is you don’t have to. Risk is primarily associated with vulnerabilities that become exploits. Once you have a detailed understanding of the specific vendors, model numbers, patch levels and firmware versions inside your OT environment, you can utilize functionality that identifies the vulnerabilities and exploits most relevant to your environment. With a prioritized list of vulnerabilities, based on asset criticality and type of exploit, you’ll be able to triage your response and reduce the highest-risk elements first to keep your environment secure.
More information on protecting OT environments
Critical Infrastructure will likely continue to widen in scope and additional demands may be placed on these organizations to produce to specific requirements. Continuously re-evaluating risk helps identify areas for improvement. Deploying the right security tools, built for OT environments but easily integrated with existing IT security, can help ensure the rock-solid dependability of the organizations that comprise our critical infrastructure.
For more information on how to upgrade your OT security posture, here are some resources that can help:
Three days after an advisory was disclosed for a critical remote code execution vulnerability in F5’s BIG-IP, active attempts to exploit vulnerable hosts have been observed in the wild.
Background
On June 30, F5 Networks published support articles identified as K52145254 and K43638305 to address two vulnerabilities in BIG-IP, its family of products which includes software and hardware solutions that provide access control, application availability and security solutions. These products include:
The vulnerabilities were disclosed to F5 by Mikhail Klyuchnikov, a senior web application security researcher at Positive Technologies.
Image may be NSFW. Clik here to view.
Analysis
CVE-2020-5902 is a critical vulnerability in the BIG-IP Traffic Management User Interface (TMUI) also known as the Configuration Utility. The vulnerability received a CVSSv3 rating of 10.0, the highest possible score. The vulnerability is exploitable when network access to the TMUI is exposed via the BIG-IP management port or Self IPs. Successful exploitation of this flaw would grant an attacker a variety of privileges, including the ability to execute arbitrary system commands or Java code, create or delete files, as well as disable services on the vulnerable host. The advisory states that the vulnerability could also “result in complete system compromise.”
CVE-2020-5903 is a cross-site scripting vulnerability in TMUI/Configuration Utility. This vulnerability received a CVSSv3 rating of 7.5, which makes this a “high” severity flaw. According to F5’s advisory, exploitation would grant an attacker the capability to execute JavaScript code under the same privileges as the current user. If the current user has administrative privileges that grant them Advanced Shell access, an attacker would be able to “completely compromise the BIG-IP system through Remote Code Execution.”
A senior security engineer at F5 elaborated further that BIG-IP versions 11.5.3 and later have switched the default behavior of Self IPs to “Allow None,” whereas versions 11.5.2 and prior use “Allow Default” for Self IPs. They added that when upgrading from a previous version, the existing configuration is carried over, including on devices after 11.5.3. Users will need to update this configuration after upgrading.
Correct. 11.5.3 and later releases have Allow None as default for Self-IPs. 11.5.2 and earlier have Allow Default.
Note that upgrading from earlier versions keeps the existing config. So if the config dates back to an older version this may need to be changed.
Security researcher Kushagra Pathak has scanned over 12,000 hosts and confirmed around 8,500 remain vulnerable.
Image may be NSFW. Clik here to view.
Active exploitation observed in the wild
According to severalreports, active scanning and exploitation of CVE-2020-5902 have already been observed. NCC Group specifically notes that attackers are leveraging the vulnerability to try to capture “web.xml” or “/etc/hosts” from vulnerable hosts.
We're seeing active exploitation of the @F5Networks K52145254: TMUI RCE vulnerability #CVE-2020-5902 issue. The threat actor is after web.xml or /etc/hosts - https://t.co/9AKpWGSrEj.
— NCC Group Infosec (@NCCGroupInfosec) July 4, 2020
Additionally, Kevin Beaumont, senior threat intelligence analyst at Microsoft, discovered that attackers had planted a cryptocurrency miner on one of his F5 honeypots.
We anticipate exploitation attempts will increase in the coming days, now that more proof of concept (PoC) scripts have been published and researchers are sharing more details publicly.
Potential impact of CVE-2020-5902
A Twitter thread published by a security researcher known as “kevvyg” calls this vulnerability “one of the most impactful” they’ve seen in decades because of its “ability to compromise any application sitting behind one [LTM or GTM].” This comment underscores the severity of the flaw, and its CVSS score highlights just how simple it is to exploit.
This is probably one of the most impactful vulnerabilities I've seen in my 20+ years in infosec. It's not just the ability to compromise one LTM or GTM. It's the ability to compromise any application sitting behind one. (8/x)
— kevvyg and the Wrong Opinions (@kevvyg) July 5, 2020
Proof of concept
Several PoC scripts for CVE-2020-5902 have been published to GitHub. However, at the time this blog was published, there was no PoC for CVE-2020-5903.
Image may be NSFW. Clik here to view.
Solution
F5 has released patches to address both vulnerabilities across its suite of products. The following table lists the branch and affected versions, as well as fixed versions.
Branch
Affected Versions
Fixed Version
11.x
11.6.1 through 11.6.5
11.6.5.2
12.x
12.1.0 through 12.1.5
12.1.5.2
13.x
13.1.0 through 13.1.3
13.1.3.4
14.x
14.1.0 through 14.1.2
14.1.2.6
15.x
15.0.0
None
15.1.0
15.1.0.4
Patching this vulnerability should be a priority, as the United States Cyber Command warned that for both flaws organizations should “remediate immediately.”
URGENT: Patching CVE-2020-5902 and 5903 should not be postponed over the weekend. Remediate immediately. https://t.co/UBKECuN7Vv
— USCYBERCOM Cybersecurity Alert (@CNMF_CyberAlert) July 3, 2020
If patching is not feasible at this time, F5 provides several temporary mitigations that are sufficient to address the vulnerability:
For Self IPs, F5 recommends blocking access to TMUI via Self IPs. This is achieved by modifying the Port Lockdown setting for each Self IP by setting it to Allow None. The preferred way to open ports on the device is to use the Allow Custom setting and prevent access to the TMUI.
Despite some of these temporary mitigations, F5 warns that authenticated users capable of accessing the TMUI will “always be able to exploit this vulnerability” until the vulnerable host is patched, which is why patching is the preferred fix.
Identifying affected systems
A list of Tenable plugins to identify these vulnerabilities can be found here. Please note that, due to a technical issue, our plugin for CVE-2020-5902 (Plugin ID 137918) was originally labeled as “Low” severity. This issue has been addressed and the plugin now displays the correct severity.
As cyberthreat actors increasingly target critical infrastructure, both the federal government and private sector have key roles to play in securing essential services. Here are some of the latest joint efforts advancing this mission.
Every day, we turn on lights, run the water and charge our devices without thinking anything of it. But the reality is the vast infrastructure of operational technology (OT) that makes these things possible is increasingly exposed to serious cyberthreats. Bad actors and foreign state actors know how much we rely on our critical infrastructure and are happy to exploit that reliance.
Across the cyber industry, there’s a heightened focus on OT security, including here at Tenable, where we’re making important strides. But the private sector can’t do this alone – the federal government has an important role to play too, and it will take a collaborative, whole-of-government partnership with industry to effectively secure the nation’s OT.
Breaking down silos within the federal government
Put simply, OT cybersecurity is too important to be managed in silos. Cross-agency collaboration in the federal government and with industry can help improve vulnerability management by sharing actionable information between agencies, limiting duplicative efforts and improving results. Recently, the Departments of Homeland Security (DHS), Energy (DOE) and Defense (DOD) extended their joint effort to develop common cyberthreat indicators and defense capabilities to protect critical infrastructure in the energy sector, allowing them to share threat information, better patch vulnerabilities and more. This is good progress, as doing so will help all three agencies improve their cyber capabilities without duplicating efforts.
The role of the private sector
The federal government has an important role to play in OT security, and they’re headed in the right direction. But we can take this even further. The private sector brings forth an incredible amount of expertise, innovation and research that’s critical to solving this problem. Just like we can’t do it without our partners in government, they can’t secure the nation’s critical infrastructure without us.
Just this month, the National Institute for Standards and Technology’s (NIST) National Cybersecurity Center for Excellence (NCCoE) announced a project with ten private sector companies, including Tenable, to develop a practical solution, aligned with the NIST Cybersecurity Framework, to help manufacturers protect their industrial control systems (ICS) from cyberattacks. The result of the project – a freely available guide for companies and organizations to leverage – is exactly the type of public-private partnership we need to solve some of our greatest OT challenges.
There are also other programs already in place that should be expanded upon, like the ICT Supply Chain Risk Management Task Force, which brings together industry leaders to work with CISA on important supply chain issues. Further, the IT Sector Coordinating Council (IT-SCC) coordinates with the Department of Homeland Security and the federal government on critical infrastructure protection and cybersecurity issues. Linking the Task Force’s OT expertise and the IT-SCC’s cybersecurity recommendations and guidance with initiatives like the Control Systems Interagency Working Group (CSIWG) Executive Engagement Forum (EEF) would go a long way in promoting advanced OT security.
At Tenable, we’re proud to work with our government partners on important cybersecurity issues every day, and we look forward to helping improve cross-functional collaboration for OT security to help keep the nation’s critical infrastructure running.
Gartner recently published its April 2020 “Voice of the Customer” report which synthesizes Gartner Peer Insights’ customer reviews from the previous year into insights for IT decision-makers. The report analyzes more than 555 reviews and ratings in the vulnerability assessment market in the 12-month period ending Feb. 29, 2020.
We’re proud that Tenable was rated the highest of all 2020 “Customers' Choice” vendors in Product Capabilities with a 4.7 out of 5 stars in the 2020 Gartner Peer Insights "Voice of the Customer": Vulnerability Assessment report.1 We believe this is a valuable peer perspective that can play a key role in helping you choose the best solution for taking a risk-based approach to vulnerability management.
Reviewers represented a broad range of company sizes, industries, and geographical regions. We think this shows Tenable’s breadth of reach and the diversity of customers that have provided positive reviews of our products.
Tenable has an Overall Rating with the most 5-out-of-5 star ratings of all the March 2020 Customer's Choice vendors for Vulnerability Assessment on Gartner Peer Insights, based on a total of 142 ratings as of 7/7/2020. Below are a few excerpts:
"Tenable is easy to use and easy to understand. You can configure their reports down to the level of each individual cell in a table, and it’s not hard to learn. I wish we’d switched a long time ago." - Analyst, Network & Infrastructure, Transportation Industry
"User of Tenable products since 2001 and would consider it to be "Best of Breed" Tenable.sc has allowed easy implementation and consolidation of information from our 40 plus Nessus scanners and 25,000 plus agents across our environment ... Using both SC and io, we were able to quickly and effectively address issues associated critical and exploitable vulnerabilities on and off site." -Chief Information Security Officer, Government Industry
“Tenable IO Is The Best I Have Seen For Reporting and Remediation Of Vulnerabilities … I Love The VPR Rating That Compliments The CVSS By Giving Real Data On Threat Intelligence.” - Systems Administrator, Education Industry
"We have been using Tenable.io for over 2 years now and I continue to be impressed by the continued product improvement. We moved away from another solution and that decision continues to pay dividends. Given the size and complexity of our organization, they have worked with us on our needs and introduced features like the ability to do asset tagging and adjust vulnerability scores, enabling us to focus on what matters most - risk." - Director of Enterprise Security Operations, Manufacturing Industry
"About Tenable I like the most is risk based prioritization based on threat modeling, highest CIS certified solution (with 126 benchmarks) & Maximum CVE coverage against their close competitors. Others are: Role based access – Asset tagging and assignments to asset owners for vulnerability related risks Workflow automation – For effective vulnerability management by automating remediation and response." - Manager, Transportation Industry
Helping our customers focus on the vulnerabilities and assets that matter most is at the core of everything we do. We are committed to delivering the most comprehensive risk-based vulnerability management solution, including:
A contextual view of risk: Go beyond using a common vulnerability scoring system (CVSS) rating by supplementing that score with essential contextual data, including threat and exploit intelligence; an assessment of asset criticality; and continuous analysis of 20 trillion threat, vulnerability and asset data points.
Continuous visibility: Our platform renders an accurate risk score for every vulnerability within seconds by using machine learning automation to process and analyze essential security data.
Risk-based prioritization: Reduce the greatest amount of business risk with the least amount of effort by using our vulnerability priority rating (VPR), asset criticality rating (ACR) and predictive prioritization to help you focus on the 3% of vulnerabilities that pose the most risk.
1. Based on 156 total reviews, as of Feb. 29, 2020
Note: Gartner Peer Insights Customers’ Choice constitute the subjective opinions of individual end-user reviews, ratings, and data applied against a documented methodology; they neither represent the views of, nor constitute an endorsement by, Gartner or its affiliates.
Researchers disclosed a critical flaw in SAP NetWeaver Application Server that could allow an attacker to gain access to any SAP application. Organizations are strongly encouraged to apply patches as soon as possible.
Background
Around 5 p.m. PST on July 13, SAP disclosed two vulnerabilities in SAP NetWeaver Application Server JAVA (AS JAVA), including a critical flaw reported by the security firm Onapsis. SAP NetWeaver is considered the “central foundation for the entire SAP software stack” and allows access to SAP data over Hypertext Transfer Protocol (HTTP). The flaws reside in the LM Configuration Wizard, a component of AS JAVA.
Analysis
CVE-2020-6287 is caused by a complete lack of authentication in the SAP NetWeaver AS Java’s LM Configuration Wizard. Due to the lack of authentication, a remote unauthenticated attacker could execute “critical actions,” including creating an administrator user and providing them with the “keys to the kingdom” over the SAP NetWeaver AS JAVA system. An attacker could gain access to adm, the operating system user that has “unlimited access to all local resources related to SAP systems.” The vendor assigned this vulnerability a CVSSv3 score of 10.0, the highest possible CVSS score. This vulnerability has been dubbed Remotely Exploitable Code On NetWeaver (or “RECON”) by security researchers at Onapsis.
CVE-2020-6286 is a path traversal vulnerability due to the lack of input validation for a path in a “certain parameter” of the web service. An unauthenticated, remote attacker could exploit this vulnerability and “download zip files to a specific directory.” The vendor assigned this vulnerability a CVSSv3 score of 5.3.
Vulnerability potentially affects multiple SAP solutions
According to an alert from the Cybersecurity Infrastructure Security Agency (CISA), CVE-2020-6287 is present by default in SAP applications running on top of SAP NetWeaver AS Java v7.3 and newer, including SAP NetWeaver v7.5. Additionally, this could potentially affect a variety of other SAP Java-based business solutions, including the following:
According to Onapsis, which identified and reported CVE-2020-6287 to SAP, more than 40,000 SAP customers may be affected. Based on a BinaryEdge search, there are at least 4,000 publicly accessible SAP NetWeaver AS JAVA systems. However, it is very likely that there are additional publicly accessible and vulnerable systems.
Image may be NSFW. Clik here to view.
Proof of concept
At the time this blog post was published, there was no proof-of-concept (PoC) code publicly available. However, considering the simplistic nature of potential exploitation for this vulnerability and publicly available patches that can be reverse engineered, we anticipate that a PoC will be published very quickly.
Solution
To address these CVEs, SAP released security updates in SAP Security Note #2934135 as part of their Security Patch Day for July 2020. According to the SAP Security Note #2934135, if the patch cannot be applied, the proposed workaround is to disable the LM Configuration Service (tc~lm~ctc~cul~startup_app application). While the workaround is defined as “defense in depth,” SAP notes that this is “not a solution.” SAP provides additional information on disabling the LM Configuration Service in SAP Security Note #2939665. Based on the severity of this vulnerability, we strongly recommend applying patches as soon as possible, focusing on internet-facing systems which are more at risk than internal systems.
Identifying affected systems
A list of Tenable plugins to identify these vulnerabilities will appear here as they’re released.
Microsoft addresses 123 CVEs, including CVE-2020-135, dubbed “SIGRed,” a wormable remote code execution vulnerability in Windows DNS Server.
For the fifth month in a row, Microsoft has patched over 100 CVEs, addressing 123 CVEs in the July 2020 Patch Tuesday release. Included this month is a highly critical remote code execution (RCE) vulnerability in Windows DNS Server (CVE-2020-1350). The updates this month include patches for Microsoft Windows, Microsoft Edge, Microsoft ChakraCore, Internet Explorer, Microsoft Office and Microsoft Office Services and Web Apps, Windows Defender, Skype for Business, Visual Studio, Microsoft OneDrive, Open Source Software, .NET Framework and Azure DevOps.
CVE-2020-1350 | Windows DNS Server Remote Code Execution Vulnerability
CVE-2020-1350 is an RCE vulnerability within the Windows Domain Name System (DNS) server due to an issue in how the DNS server parses requests. The vulnerability has a 10.0 CVSSv3 score, the highest possible rating. The flaw has existed for 17 years, affecting Windows Server versions from 2003 to 2019, and was discovered by Sagi Tzadik and Eyal Itkin from Check Point Research who have dubbed this vulnerability “SIGRed.” Microsoft acknowledges that this vulnerability is “wormable,” or potentially spreadable via malware between affected hosts in a network without any user interaction.
DNS is a core networking component and any compromise of a DNS server could have a severe impact within an organization. This vulnerability received a patch for Windows Server 2008, which went end of life in January 2020, underscoring the severity of this issue. Microsoft recommends patching this vulnerability as soon as possible and offers a workaround for those that cannot immediately patch. The workaround, described in KB4569509, works by setting the maximum length of a DNS message over TCP to 62,580 bytes (0xFF00): this prevents a Windows DNS server from resolving hostnames when the DNS response from an upstream server exceeds this maximum threshold.
CVE-2020-1032, CVE-2020-1036, CVE-2020-1040, CVE-2020-1041, CVE-2020-1042, and CVE-2020-1043 are RCE vulnerabilities in Hyper-V RemoteFX vGPU due to the host server not properly validating input from guest operating systems. If an attacker executes malicious code on a guest operating system, they could attack third-party video drivers on the Hyper-V host, which could result in the host operating system executing malicious code.
The related patches do not fix this vulnerability. Instead, these patches disable RemoteFX, a visual enhancement suite provided by Microsoft to improve the video quality of RDP sessions. Without RemoteFX, visual display tasks during RDP sessions will likely be handled by the host CPU, rather than the GPU on Server 2012 and older hosts. Microsoft Server 2016 and newer have Discrete Device Assignment (DDA) which handles these tasks, as RemoteFX was deprecated in Windows Server 2019.
CVE-2020-1400, CVE-2020-1401 and CVE-2020-1407 are RCE vulnerabilities that exist when Windows Jet Database Engine improperly handles objects in memory. Successful exploitation of these vulnerabilities would allow an attacker to execute arbitrary code on an affected system. To exploit this vulnerability, an attacker must convince a victim to open a specially crafted file or visit a malicious website.
CVE-2020-1446 | Microsoft Word Remote Code Execution Vulnerability
CVE-2020-1446 is an RCE vulnerability that exists in Microsoft Word when it fails to handle objects in memory. Successful exploitation of this vulnerability would allow an attacker to perform actions in the context of the current user, with the user’s rights and permissions. Exploitation of this vulnerability requires an attacker to send a specially crafted file to a victim, or to convince a user to visit a crafted website hosting a malicious file which the user must open with a vulnerable version of Microsoft Word.
CVE-2020-1374 is an RCE vulnerability in the Windows Remote Desktop Client caused by malicious code running on a remote server. When a client connects to an infected server, they become susceptible to an RCE attack. An attacker would either need to compromise a trusted server, or use some other method, like a Man in the Middle (MitM) style attack, to intercept a user’s RDP attempts and redirect them to a malicious server.
CVE-2020-1481 is an RCE vulnerability that exists in the ESLint extension for Visual Studio Code when it validates source code after opening a project. Successful exploitation of this vulnerability would allow an attacker to execute arbitrary code in the context of the current user, with the same rights and permissions.
Exploitation of this vulnerability would require an attacker to convince a victim to clone a repository that contains malicious executable code and open it with a vulnerable version of Visual Studio Code. If the target is an Admin user, the code could be configured to create accounts with admin rights and permissions, install malicious programs and view, alter or delete data.
CVE-2020-1381 and CVE-2020-1382| Windows Graphics Component Elevation of Privilege Vulnerability
CVE-2020-1381 and CVE-2020-1382 are elevation of privilege vulnerabilities that exist when the Windows Graphic Component improperly handles objects in memory. Successful exploitation of these vulnerabilities would allow an attacker to run processes in an elevated context. Exploitation of these vulnerabilities would require an attacker to log onto a vulnerable system and execute a specially crafted application to take control of the system.
CVE-2020-1403 is an RCE vulnerability in the mishandling of memory objects in the VBScript engine. An attacker would have to convince a user to execute malicious code, either through phishing or convincing a user to visit a malicious website, where the user would download and execute a crafted file. Once the user executes the malicious code, commands can then be executed against the local host as the current user.
Tenable solutions
Users can create scans that focus specifically on our Patch Tuesday plugins. From a new advanced scan, in the plugins tab, set an advanced filter for Plugin Name contains July 2020.
Image may be NSFW. Clik here to view.
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 Tenable.io:
Image may be NSFW. Clik here to view.
A list of all the plugins released for Tenable’s July 2020 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.
CVE-2020-1350 is a critical remote code execution (RCE) vulnerability in Windows DNS servers due to the improper handling of DNS requests. It was assigned a CVSSv3 score of 10.0, the highest possible score. To exploit this vulnerability, an attacker would send a malicious request to a vulnerable Windows DNS server. Successful exploitation would grant the attacker arbitrary code execution privileges under the Local System Account context. Microsoft warns that systems at risk include “Windows servers” that have been “configured as DNS servers.”
Second major wormable flaw patched this year
In March of this year, Microsoft released patches for CVE-2020-0796, a wormable RCE vulnerability in Microsoft Server Message Block 3.1.1, known as EternalDarkness or SMBGhost. While we have yet to see SMBGhost used in a wormable fashion, SIGRed marks the second wormable Microsoft vulnerability patched this year.
SIGRed can be triggered via the browser
Researchers at Check Point found that they could remotely trigger the vulnerability through a web browser. This is achieved by “smuggling” a DNS query in an HTTP request as part of the POST data. However, this vulnerability can only be exploited through browsers that accept HTTP requests over the standard DNS port (53), which include Internet Explorer and Microsoft Edge versions that are not using Chromium.
As part of a demonstration, Check Point Researchers show how they could trigger the vulnerability by sending a link to a user in an email, which when opened would smuggle the DNS query inside of the HTTP request.
Proof of concept
At the time this blog post was published, there was no working proof-of-concept (PoC) code available for this vulnerability. However, we have seen at least one fake PoC that "Rickrolls" users. In the past, we’ve also observed some malicious scripts that masquerade as PoCs being published to GitHub. We strongly advise caution when dealing with alleged PoCs. However, we anticipate that it won’t be long before researchers and attackers have developed their own working PoCs.
Solution
Microsoft has released patches to address SIGRed across a variety of Windows Server releases. Despite Windows Server 2008 reaching end of life in January 2020, Microsoft has published security patches to prevent unsupported systems from being compromised by a potential worm.
Tenable strongly encourages organizations to apply these patches as soon as possible.
Windows Server 2008 for 32-bit Systems Service Pack 2 Windows Server 2008 for 32-bit Systems Service Pack 2 (Server Core) Windows Server 2008 for x64-based Systems Service Pack 2 Windows Server 2008 for x64-based Systems Service Pack 2 (Server Core)
Windows Server 2008 for 32-bit Systems Service Pack 2 Windows Server 2008 for 32-bit Systems Service Pack 2 (Server Core) Windows Server 2008 for x64-based Systems Service Pack 2 Windows Server 2008 for x64-based Systems Service Pack 2 (Server Core)
Penetration tests and vulnerability assessments make for an excellent tandem approach to cybersecurity.
While similar — and sometimes confused for each other — penetration tests and vulnerability assessments are decidedly not the same thing. There are important, fundamental differences that actually allow these two tactics to be used in tandem.
Vulnerability assessments and penetration tests both look for weaknesses in your network. In the former, the key goal is to identify, quantify and analyze vulnerabilities within IT infrastructure, enumerating all of the hypothetical routes to a cyberattack. This applies to everything from compromised IoT devices to applications with glitches in their source code. The process is often automated, and in many organizations, can ultimately identify hundreds, if not thousands, of vulnerabilities.
A penetration test, meanwhile, is an authorized attack on your own systems — a form of ethical hacking— that exploits vulnerabilities so that a pen tester can attempt to gain access to systems and data. The idea is to see how easy or difficult it is to overcome your defenses, testing the hypothetical risks found during a vulnerability assessment. Pen testers use a well-known arsenal of "white hat" hacking tools to complete their sanctioned attacks, including the Social Engineering Toolkit1 and Pen Testers Framework.2 But a pen tester's manual skill and creativity are just as important to successfully find an exploitable system, map the network, gain access to other systems and test defenses. Think of it as the infosec version of criminal profiling: Only by imagining the mindset of a malicious hacker and mimicking their activities can a well-intentioned pen tester truly understand the risk an organization faces and adequately prepare to face it.
Focus your penetration testing with active scanning
Active scanning proactively searches for vulnerability signs at the time the scan is initiated. Passive scans monitor network activity and wait to see indicators of vulnerabilities. Active scanning is a core function of Nessus Professional, and for organizational users, it is the most direct method of searching for vulnerabilities and an excellent complement to any penetration test. As an example, if a pen tester is looking for an exploitable hole in a website, they could use a web application scanner to identify specific ways in which applications are vulnerable to attacks, such as cross-site scripting or SQL injections, and then explore those areas in greater detail (either with pen testing tools or manual methods).
Image may be NSFW. Clik here to view.
Vulnerability scan results save time and resources by identifying the areas a pen test should focus on most closely. For example, imagine that scan results show your Apache framework is vulnerable. But if you know you can easily mitigate the vulnerability by removing the application entirely, simply go ahead and do that! That's a much more efficient approach than using pen testing resources to explore the weaknesses of a program in great detail.
The goal of active scanning should be to focus pen testing efforts, not expand them. If you’re using penetration testing to double-check everything your active scanning solution finds, you’re just adding more work.
Vulnerability scanning is necessary for hardening systems to ensure information security. At Tenable, results from your Nessus scans can be integrated with popular penetration testing tools. This makes it even easier to start penetration testing from a solid foundation.
Find the unknowns with offline assessments
While active scanning can help focus your penetration testing efforts, what about identifying flaws and vulnerabilities while offline? This is especially important if you have not been running your scans on a frequent basis: Any new applications you added between scans won't have been screened for weaknesses, leaving you potentially exposed to glitches you didn't know about. Unmanaged assets with vulnerabilities — or those with settings that aren’t consistent with policy — are great targets to exploit.
Nessus Professional's Live Results feature, once activated, performs an offline vulnerability assessment separately from your standard scan every time plugins are updated. Based on its examination of data from past scans, it searches for possible glitches and sends alerts of suspicious findings. At that point, you can run an active scan with Nessus to validate the findings.
Preceding a penetration test and other usual scans with Live Results can make life easier for the pen tester. Live Results can help guide infosec professionals while they conduct their tests, aiding them in identifying how their examination can be redirected. From there, testers can comprehensively assess the situation and conclude which vulnerabilities must be closely tested and explored to gauge how easily they can be exploited.
The combination of active scanning with offline vulnerability assessments using Live Results from Nessus represents a strong strategy for improving penetration testing success and protecting your network.
Try it out for yourself with a free 7-day trial of Nessus Professional.
Oracle’s third Critical Patch Update of 2020 contains a record-breaking 443 security patches addressing 284 CVEs, including critical vulnerabilities in Oracle Communications Applications and Oracle Fusion Middleware products.
Background
On July 14, Oracle released the Critical Patch Update (CPU) Advisory for July 2020 as part of their quarterly release of security patches. This update contains fixes for 284 CVEs in 443 security patches across 29 Oracle product families. This quarter’s update continues an upward trend, overtaking the previous Oracle CPU patch record set by April 2020's update.
Image may be NSFW. Clik here to view.
Analysis
This quarter’s CPU includes more than 30 critically rated CVEs across a wide range of Oracle products. The following is the full list of product families with vulnerabilities addressed in this month’s release along with the number of patches released and vulnerabilities that are remotely exploitable without authentication.
Oracle Product Family
Number of Patches
Remote Exploit without Auth
Oracle Communications Applications
60
46
Oracle Fusion Middleware
52
48
Oracle Retail Applications
47
42
Oracle MySQL
40
6
Oracle Financial Services Applications
38
26
Oracle E-Business Suite
30
24
Oracle Virtualization
25
0
Oracle Supply Chain
22
18
Oracle Construction and Engineering
20
15
Oracle Database Server
19
1
Oracle Enterprise Manager
14
10
Oracle Java SE
11
11
Oracle PeopleSoft
11
9
Oracle Systems
7
1
Oracle Insurance Applications
6
4
Oracle JD Edwards
6
6
Oracle Siebel CRM
5
5
Oracle Commerce
4
3
Oracle Food and Beverage Applications
4
0
Oracle GraalVM
4
3
Oracle Health Sciences Applications
4
4
Oracle Berkeley DB
3
0
Oracle GoldenGate
3
1
Oracle Hyperion
3
0
Oracle Global Lifecycle Management
1
0
Oracle TimesTen In-Memory Database
1
0
Oracle Hospitality Applications
1
1
Oracle iLearning
1
1
Oracle Utilities Applications
1
1
Notable Vulnerabilities
Considering the large number patches released in this quarter’s CPU, it may be hard to digest, filter and prioritize these vulnerabilities. However, a few notable vulnerabilities stand out due to their criticality and potential for being targeted by attackers.
CVE-2020-14701 and CVE-2020-14706 are vulnerabilities in the User Interface component of the Oracle Communications Applications SD-WAN Aware and SD-WAN Edge products respectively. Oracle has highlighted these vulnerabilities as “easily exploitable” as they allow an unauthenticated attacker with network access via the Hypertext Transfer Protocol (HTTP) to compromise SD-WAN Aware and SD-WAN Edge.
Successful exploitation of these vulnerabilities would result in a complete takeover of SD-WAN Aware and SD-WAN Edge. While the vulnerabilities are in these products, Oracle has noted that “attacks may significantly impact additional products.” These are the only details currently available from Oracle, though the company has assigned both vulnerabilities a CVSSv3.1 score of 10.0, the highest score possible, suggesting easy exploitability with potentially significant impact, making them important vulnerabilities to prioritize.
CVE-2020-14625, CVE-2020-14644, CVE-2020-14645 and CVE-2020-14687 | Oracle Fusion Middleware WebLogic Server Vulnerabilities
CVE-2020-14625, CVE-2020-14644, CVE-2020-14645, and CVE-2020-14687 are vulnerabilities in the Core component of the Oracle WebLogic product of Oracle Fusion Middleware. Oracle has highlighted these vulnerabilities as “easily exploitable” as they allow an unauthenticated attacker with network access via Oracle’s T3 and Internet Inter-ORB Protocol (IIOP) to compromise the server.
Successful exploitation of these vulnerabilities would allow an attacker to gain full control over the Oracle WebLogic Server. Given their ease of exploitation, Oracle has assigned these vulnerabilities a critical CVSSv3.1 score of 9.8. Oracle WebLogic vulnerabilities regularly appear in the quarterly CPU advisories and historically have been prime targets for exploitation. Less than one month after the April 2020 CPU, CVE-2020-2883, an Oracle WebLogic vulnerability, was reported as exploited in the wild. This prompted Oracle to release a separate alert urging people to patch as soon as possible.
Solution
Customers are advised to apply all relevant patches provided by Oracle in this CPU. Please refer to the July 2020 advisory for full details.
Identifying affected systems
A list of Tenable plugins to identify these vulnerabilities will appear here as they’re released.