Tag Archives: vulnerabilities

Ripple20 vulnerabilities still plaguing IoT devices

The Ripple20 situation has improved little since the collection of IoT vulnerabilities were first revealed in June, and experts say the IoT industry may never be fully rid of them.

That’s according to researchers from JSOF, a cybersecurity consultancy based in Jerusalem, during a Black Hat USA 2020 session on Wednesday. The JSOF team offered a technical deep dive into the series of 19 zero-day vulnerabilities the firm discovered last year, which affected hundreds of millions of IoT devices across virtually all vertical industries.

The vulnerabilities are part of a TCP/IP stack called Treck TCP/IP, widely used among a long list of connected and IoT devices from vendors such as Intel, Cisco and Hewlett Packard Enterprise.

In the Black Hat session, JSOF CEO Shlomi Oberman explained that four of the vulnerabilities are critical remote code execution vulnerabilities, and eight are medium- to high-severity Common Vulnerability Scoring System weaknesses with some chance of RCE.

“The devices affected are made by vendors you all know,” Oberman said. “Large vendors, devices of high impact, as well as smaller vendors of any range of all types of IoT devices and from Fortune 500 companies to one-person shops, tiny little companies making specialist devices. The types of devices you can encounter in your hospital, at home on your network, power, water, cellular, utilities, things you use in your everyday life, transportation — pretty much anything we do is powered by devices affected by Ripple20 vulnerabilities.”

Knowing what we know about [Ripple20-]affected devices and affected vulnerabilities, we’re assuming every mid-to-large organization in the U.S. has at least one vulnerable device.
Shlomi ObermanCEO, JSOF

Because the Treck stack was used in so many different products, from routers and DVRs to medical devices and industrial control systems (ICSes), it was a challenge for JSOF researchers to identify and notify affected vendors. JSOF said the TCP/IP library has spread across the technology supply chain over the last two decades, with different versions and branches reaching hundreds of millions of devices. The researchers said this created a ripple effect across the technology industry, hence the name Ripple20.

While some major vendors have issued advisories and patches for Ripple20 vulnerabilities, others have not. Oberman said the problem is extremely widespread, and he expects more vulnerable vendors and devices will be discovered as time goes on.

“At this stage, knowing what we know about affected devices and affected vulnerabilities, we’re assuming every mid-to-large organization in the U.S. has at least one vulnerable device, whether it be a networking device, a printing device, ICS device, etc.,” Oberman said.

Ripple20 Black Hat
JSOF CEO Shlomi Oberman discussed the Ripple20 vulnerabilities at Black Hat USA 2020 on Wednesday.

Scott Caveza, research engineering manager at Tenable, also said he expects the scope of devices and vendors affected to grow even further. Tenable collaborated with JSOF recently to help identify 34 additional vendors and 47 devices vulnerable to Ripple20.

Even worse, according to Caveza, it will be nearly impossible to ever fully get rid of devices affected by the Ripple20 vulnerability.

“JSOF continues to work with various vendors and CERT/CC [Computer Emergency Response Team Coordination Center] to reach out to those vendors,” he said. “Because this library has been repurposed over many years by multiple vendors, tracking down all affected devices is a near-impossible task, and there will inevitably be devices that are found to be vulnerable but no longer supported or were released by a company that is no longer in business.”

As for how serious it is, Caveza said that “the range of severity will really depend on the device and how the Treck TCP/IP stack was implemented.”

“In some cases, this could have a very severe impact, and in others, code differences could offer some mitigations and protection,” he said. “The Treck library is found in a wide variety of IoT and operational technology devices, which may be used in critical operations and are notoriously difficult to patch. This certainly heightens the threat posed by Ripple20.”

Go to Original Article
Author:

Citrix vulnerabilities affect ADC, Gateway, SD-WAN

Citrix has urged customers to patch vulnerabilities in its networking software that hackers could exploit to commandeer computing systems.

The Citrix vulnerabilities affect the company’s Application Delivery Controller (ADC), Gateway and SD-WAN products. The firm issued a security bulletin on Tuesday, saying the issue could lead to hackers taking control of a computing system. 

In a blog post accompanying the bulletin, Citrix CISO Fermin Serna said the company’s latest patches fix the flaws and Citrix is not aware of any exploitation of the software openings.

Serna said there were other barriers to prevent attackers from exploiting the vulnerabilities. Several methods of attack use the management interface of a device; Citrix had already recommended separating such an interface from the network. Other avenues required attackers already have access to a vulnerable device.

The latest vulnerabilities are not related to earlier flaws in the same products, Serna said.  Security researchers discovered the earlier problem, called CVE-2019-19781, in December 2019. Citrix patched the vulnerability in late January.

Attack vectors grow as remote work increases

Companies use Citrix’s ADC and Gateway to deliver the vendor’s virtual desktop to remote workers. That highly distributed workforce has grown during the COVID-19 pandemic, which has increased the security demands on IT staff.

“Citrix definitely has a black eye, in general, from these exploits, but the mitigation steps being advised [are] the right ones,” independent analyst Eric Klein said.

Andrew Hewitt, an analyst at Forrester Research, said attackers see a worker’s home as a weak point in enterprise security. As Citrix is used heavily in work-from-home scenarios, it is a natural target, he said.

Go to Original Article
Author:

NSA reports flaw in Windows cryptography core

After years of criticism from the infosec community about hoarding critical vulnerabilities, the National Security Agency may be changing course.

The highlight of Microsoft’s first Patch Tuesday of 2020 is a vulnerability in the Windows cryptography core first reported to vendor by the NSA. The flaw in CryptoAPI DLL (CVE-2020-0601) affects Windows 10 and Windows Server 2016 and 2019. According to Microsoft’s description, an attacker could exploit how Windows validates ECC certificates in order to launch spoofing attacks.

The NSA gave a more robust description in its advisory, noting that the Windows cryptography flaw also affects “applications that rely on Windows for trust functionality,” and specifically impacts HTTPS connections, signed files and emails and signed executable code.

“Exploitation of the vulnerability allows attackers to defeat trusted network connections and deliver executable code while appearing as legitimately trusted entities,” NSA wrote in its advisory. “NSA assesses the vulnerability to be severe and that sophisticated cyber actors will understand the underlying flaw very quickly and, if exploited, would render the previously mentioned platforms as fundamentally vulnerable. The consequences of not patching the vulnerability are severe and widespread. Remote exploitation tools will likely be made quickly and widely available.”

Will Dormann, vulnerability analyst at the CERT Coordination Center, confirmed the issue also affects X.509 certificates, meaning an attacker could spoof a certificate chain to a trusted root certificate authority and potentially intercept or modify TLS-encrypted communication.

Johannes Ullrich, fellow at the SANS Internet Storm Center, said the flaw is especially noteworthy because “the affected library is a core component of the Windows operating systems. Pretty much all software doing any kind of cryptography uses it.”

“The flaw is dangerous in that it allows an attacker to impersonate trusted websites and trusted software publishers. Digital signatures are used everywhere to protect the integrity and the authenticity of software, web pages and, in some cases, email,” Ullrich told SearchSecurity. “This flaw could be used to trick a user into installing malicious software. Most endpoint protection products will inspect the digital signature of software the user installs, and consider software created by trusted organizations as harmless. Using this flaw, an attacker would be able attach a signature claiming that the software was created by a trusted entity.”

However, Craig Young, computer security researcher for Tripwire’s vulnerability and exposure research team, said the impact of this Windows cryptography vulnerability might be more limited to enterprises and “most individuals don’t need to lose sleep over this attack just yet.”

“The primary attack vectors most people would care about are HTTPS session compromise malware with spoofed authenticode signatures. The attack against HTTPS however requires that the attacker can insert themselves on the network between the client and server. This mostly limits the attack to nation-state adversaries,” Young told SearchSecurity. “The real risk is more likely to enterprises where a nation state attacker may be motivated to carry out an attack. The worst-case scenario would be that a hostile or compromised network operator is used to replace legitimate executable content from an HTTPS session with malicious binaries having a spoofed signature.”

Beyond patching, NSA suggested network prevention and detection techniques to inspect certificates outside of Windows cryptography validation.

“Some enterprises route traffic through existing proxy devices that perform TLS inspection, but do not use Windows for certificate validation. The devices can help isolate vulnerable endpoints behind the proxies while the endpoints are being patched,” NSA wrote. “Properly configured and managed TLS inspection proxies independently validate TLS certificates from external entities and will reject invalid or untrusted certificates, protecting endpoints from certificates that attempt to exploit the vulnerabilities. Ensure that certificate validation is enabled for TLS proxies to limit exposure to this class of vulnerabilities and review logs for signs of exploitation.”

NSA takes credit

Infosec experts credited the NSA for not only reporting the Windows cryptography flaw but also providing detailed insight and advice about the threat. Chris Morales, head of security analytics at Vectra, based in San Jose, Calif., praised the NSA for recommending “leveraging network detection to identify malicious certificates.”

“I think they did a great job of being concise and clear on both the problem and recommended courses of action,” Morales told SearchSecurity. “Of course, it would be great if the NSA did more of this, but it is not their normal job and I wouldn’t expect them to be accountable for doing a vendor job. Relying on the vendor for notification of security events will always be important.”

Young also commended the NSA’s advisory for being very helpful and providing “useful insights which are not included in either the CERT/CC note or the Microsoft advisory.”

The NSA is designated as the Executive Secretariat of the government’s Vulnerabilities Equities Process (VEP), designed to organize the process of determining what vulnerabilities found by federal agencies would be kept secret and which would be disclosed. However, the NSA has consistently received criticism from experts that it keeps too many vulnerabilities secret and should disclose more in order to help protect the public. In recent years, this criticism was loudest when leaked NSA cyberweapons were used in widespread WannaCry attacks.

The NSA advisory for the Windows cryptography flaw is rare for the agency, which has been more open with warnings about potential threats but hasn’t been known to share more technical analysis.

Also making this vulnerability an outlier is that the NSA was given attribution in Microsoft’s patch acknowledgements section. Anne Neuberger, deputy national manager at the NSA, said on a call with news media Tuesday that this wasn’t the first vulnerability the NSA has reported to Microsoft, but it does mark the first time the agency accepted attribution.

Infosec journalist Brian Krebs, who broke the story of the Windows cryptography patch on Monday, claimed sources told him this disclosure may mark the beginning of a new initiative at NSA to make more vulnerability research available to vendors and the public.

NSA did not respond to requests for comment at the time of this writing.

Go to Original Article
Author:

5/14: Hyper-V HyperClear Update

‎05-14-2019 12:54 PM

Four new speculative execution side channel vulnerabilities were announced today and affect a wide array of Intel processors. The list of affected processors includes Intel Xeon, Intel Core, and Intel Atom models. These vulnerabilities are referred to as CVE-2018-12126 Microarchitectural Store Buffer Data Sampling (MSBDS), CVE-2018-12130 Microarchitectural Fill Buffer Data Sampling (MFBDS), CVE-2018-12127 Microarchitectural Load Port Data Sampling (MLPDS), and CVE-2018-11091 Microarchitectural Data Sampling Uncacheable Memory (MDSUM). These vulnerabilities are like other Intel CPU vulnerabilities disclosed recently in that they can be leveraged for attacks across isolation boundaries. This includes intra-OS attacks as well as inter-VM attacks.

In a previous blog post, the Hyper-V hypervisor engineering team described our high-performing and comprehensive side channel vulnerability mitigation architecture, HyperClear. We originally designed HyperClear as a defense against the L1 Terminal Fault (a.k.a. Foreshadow) Intel side channel vulnerability. Fortunately for us and for our customers, HyperClear has proven to be an excellent foundation for mitigating this new set of side channel vulnerabilities. In fact, HyperClear required a relatively small set of updates to provide strong inter-VM and intra-OS protections for our customers. These updates have been deployed to Azure and are available in Windows Server 2016 and later supported releases of Windows and Windows Server. Just as before, the HyperClear mitigation allows for safe use of hyper-threading in a multi-tenant virtual machine hosting environment.

We have already shared the technical details of HyperClear and the set of required changes to mitigate this new set of hardware vulnerabilities with industry partners. However, we know that many of our customers are also interested to know how we’ve extended the Hyper-V HyperClear architecture to provide protections against these vulnerabilities.

As we described in the original HyperClear blog post, HyperClear relies on 3 main components to ensure strong inter-VM isolation:

  1. Core Scheduler
  2. Virtual-Processor Address Space Isolation
  3. Sensitive Data Scrubbing

As we extended HyperClear to mitigate these new vulnerabilities, the fundamental components of the architecture remained constant. However, there were two primary hypervisor changes required:

  1. Support for a new Intel processor feature called MbClear. Intel has been working to add support for MbClear by updating the CPU microcode for affected Intel hardware. The Hyper-V hypervisor uses this new feature to clear microarchitectural buffers when switching between virtual processors that belong to different virtual machines. This ensures that when a new virtual processor begins to execute, there is no data remaining in any microarchitectural buffers that belongs to a previously running virtual processor. Additionally, this new processor feature may be exposed to guest operating systems to implement intra-OS mitigations.
  2. Always-enabled sensitive data scrubbing. This ensures that the hypervisor never leaves sensitive data in hypervisor-owned memory when it returns to guest kernel-mode or guest user-mode. This prevents the hypervisor from being used as a gadget by guest user-mode. Without always-enabled sensitive data scrubbing, the concern would be that guest user-mode can deliberately trigger hypervisor entry and that the CPU may speculatively fill a microarchitectural buffer with secrets remaining in memory from a previous hypervisor entry triggered by guest kernel-mode or a different guest user-mode application. Always-enabled sensitive data scrubbing fully mitigates this concern. As a bonus, this change improves performance on many Intel processors because it enables the Hyper-V hypervisor to more efficiently mitigate other previously disclosed Intel side channel speculation vulnerabilities.

Overall, the Hyper-V HyperClear architecture has proven to be a readily extensible design providing strong isolation boundaries against a variety of speculative execution side channel attacks with negligible impact on performance.

Go to Original Article
Author: brucesherwin

Check Point: Qualcomm TrustZone flaws could be ‘game over’

Security researchers found vulnerabilities in the Qualcomm TrustZone secure element extension that could allow attackers to steal the most sensitive data stored on mobile devices.

TrustZone implements architectural security extensions on ARM processors that can be integrated into the bootloader, radio, Android system image and a trusted execution environment (TEE) in mobile devices. Slava Makkaveev, security researcher at Check Point Software Technologies, discovered the issues in the Qualcomm TrustZone implementation often used by major Android manufacturers.

“TEE code is highly critical to bugs because it protects the safety of critical data and has high execution permissions. A vulnerability in a component of TEE may lead to leakage of protected data, device rooting, bootloader unlocking, execution of undetectable APT and more. Therefore, a Normal world OS restricts access to TEE components to a minimal set of processes,” Makkaveev wrote in his analysis. “Examples of privileged OS components are DRM service, media service and keystore. However, this does not reduce researchers’ attention to the TrustZone.”

Makkaveev said the Qualcomm TrustZone components can be found in popular Android devices from Samsung, Google, LG and OnePlus. He used fuzzing tools to discover the vulnerabilities and exploited them in order to install a trusted app in a normal environment.

Check Point claimed the flaws affect all versions of Android up to the most recent Android 10; however, Makkaveev mentions testing on only a Nexus 6 running Android 7.1, an LG G4 running Android 6 and Moto G4/G4 Plus running an unknown version of Android.

Samsung, Motorola, LG and Qualcomm did not respond to requests for comment at the time of this post. Google responded but did not have information readily available as to whether more recent Google Pixel devices are at risk.

Liviu Arsene, global cybersecurity researcher at antimalware firm Bitdefender, based in Romania, told SearchSecurity this research is important because “high-complexity and high-reward vulnerabilities [like this] can potentially offer untethered access to critical assets and data on the device.”

“When a vulnerability in the software that sits between the hardware and the operating system running on top of it is found, successful exploitation can have serious security and privacy implications,” Arsene said. “Not because attackers could potentially access critical and sensitive data, but because attackers can compromise the security of the device, while being invisible to the victim. Depending on how the vulnerability is triggered, weaponized attackers might successfully exfiltrate sensitive data such as passwords, financial information, or even planting additional software on the device.”

Ekram Ahmed, head of public relations at Check Point, told SearchSecurity, “it’s only a matter of time before we find more vulnerabilities.”

Once someone gains access into Trust Zone, it’s game over. They can get unprecedented access to our credit cards, biometric data, keys, passwords.
Ekram AhmedHead of public relations, Check Point

“Once someone gains access into Trust Zone, it’s game over. They can get unprecedented access to our credit cards, biometric data, keys, passwords,” Ahmed said. “It wouldn’t be too difficult for a medium-skilled cyber actor to exploit. What is difficult is knowing exactly who is affected. The vulnerability is a deeper infrastructure issue.”

Arsene said he wouldn’t expect to see these Qualcomm TrustZone flaws exploited “en masse in the wild.”

“While weaponizing the vulnerability may be possible, it’s likely that only a handful of users could potentially be impacted, possibly in highly targeted attacks,” Arsene said. “However, the difficulty of pulling off these attacks lies in how easily the vulnerability can be weaponized.”

Ahmed added that Check Point notified all potentially affected device manufacturers, but the company had “strange” interactions with Qualcomm leading up to the patch being released.

“We asked them to patch, and they only told us they patched a day before we published the blog, because the media was reaching out to them,” Ahmed said. “They went months without communicating a single word to us.”

Go to Original Article
Author:

September Patch Tuesday addresses 2 Windows zero-days

September Patch Tuesday arrived with fixes for two zero-day vulnerabilities and three public disclosures that make patching the OS on both clients and servers a priority for administrators.

Microsoft addressed 79 unique vulnerabilities — 17 with a critical severity rating — including two Windows zero-days that administrators should put near the top of their patching priority list. As part of its September Patch Tuesday releases, Microsoft also closed bugs in its Internet Explorer and Edge browsers, Microsoft Office, Skype for Business, Exchange Server and Yammer. 

Microsoft squashes two Windows zero-days

A zero-day (CVE-2019-1214) in the Windows Common Log File System driver gives an attacker, who needs to have prior access to the network, a way to elevate privileges by running a specially crafted application. This vulnerability, rated important, affects all supported versions of Windows on the server and client side.

Chris Goettl, director of product management and security, IvantiChris Goettl

“This is what attackers will use to elevate their privilege level and be able to gain persistent access and start to pivot and move elsewhere the environment,” said Chris Goettl, director of product management and security at Ivanti, a security and IT management vendor based in South Jordan, Utah.

Microsoft patched another zero-day (CVE-2019-1215). This flaw in the Winsock component, rated important, lets an intruder who has gained access with local authentication run code with elevated privileges. This vulnerability affects all supported Windows systems on desktops and clients.

It’s important to weigh other factors in addition to the severity rating and the Common Vulnerability Scoring System (CVSS) score when determining the precedence of updates for systems, Goettl said. An administrator who gives critical updates top billing might miss these sorts of zero-days that have a less severe rating, he said.

“Typically, we recommend vendor severity, plus CVSS score, and use indicators like exploited or publicly disclosed as additional risk indicators that would raise the priority,” Goettl said.

Fixes issued for three public disclosures

In August, Tavis Ormandy of Google Project Zero revealed an elevation-of-privilege vulnerability in the Windows Text Service Framework. The exploit, which requires prior authentication on the system, lets the intruder run a specially crafted program to overtake the system. Microsoft closed this vulnerability (CVE-2019-1235), rated important for all supported Windows versions, by adjusting how the Text Service Framework server and client certify input from each other.

Our speculation is that the threat actors who are going to take advantage of BlueKeep are less likely to do so from a ransomware perspective.
Chris GoettlDirector of product management and security, Ivanti

“The risk of a public disclosure is that there is enough information about how to exploit this vulnerability in the wild. An attacker has an advanced start on research. They don’t have to reverse-engineer and try to figure it all out for themselves,” Goettl said.

CVE-2019-1253 — an elevation-of-privilege vulnerability rated important for Windows 10 and Windows Server 2019 systems — follows the same pattern as the other vulnerabilities: An attacker who has logged into a system can run code to elevate privileges. Microsoft’s update corrects the flaw in the Windows AppX Deployment Server, which handles tasks related to apps in the Microsoft Store.

The last public disclosure is a bug in the Windows secure boot security feature (CVE-2019-1294), rated important, that affects Windows 10 and Windows Server 2019 systems. The exploit requires physical access to a device running the OS, such as a laptop. Systems that use BitLocker and full-disk encryption would not be susceptible to this kind of attack, Goettl said.

Several Microsoft development tools patched

Administrators who manage Windows developer environments will need to examine the September Patch Tuesday releases closely for fixes affecting several coding-related tools and technologies, including the ChakraCore JavaScript component in the Edge browser, Visual Studio, the Project Rome software development kit, the .NET Framework and Team Foundation Server.

“The .NET Framework update was only for 3.5 and later, nothing earlier. This is one of those areas where people need to focus on moving forward from those older development tool sets that have reached end-of-life to continue to get security coverage from Microsoft,” Goettl said.

BlueKeep vulnerability continues to remain a concern

Microsoft continued to close holes in the Remote Desktop Client by addressing four critical vulnerabilities — CVE-2019-0787, CVE-2019-0788, CVE-2019-1290 and CVE-2019-1291 — that do not have the same “wormable” threat potential as BlueKeep and DejaBlue. The bugs fixed by the September Patch Tuesday updates would require some interaction from a user to trigger the exploit.

Even after multiple warnings from Microsoft, there has been no BlueKeep outbreak on Windows systems, despite recent exploit code releases. In one recent example, Metasploit — an open source penetration testing framework sponsored by security company Rapid7 — published a BlueKeep module on Sept. 6. The coders purposefully limited the module’s abilities to curb potential misuse.

“By default, Metasploit’s BlueKeep exploit only identifies the target operating system version and whether the target is likely to be vulnerable. The exploit does not currently support automatic targeting; it requires the user to manually specify target details before it will attempt further exploitation,” Rapid7 wrote in a blog.

Despite the outcry on Twitter related to the Metasploit release, other security vendors have released similar code, and Goettl said he suspects a global catastrophe might not come to fruition for one specific reason.

“Our speculation is that the threat actors who are going to take advantage of BlueKeep are less likely to do so from a ransomware perspective,” Goettl said. “If somebody did this from a cryptomining perspective and spread this out to hundreds of thousands of systems simultaneously — even for a few months — the revenue stream could be on the order of tens of millions of dollars, compared to the $200,000 WannaCry was able to extort over its five-month life.”

All Windows systems get critical servicing stack update

In what may be a prelude to upcoming changes to Windows updates, Microsoft issued an advisory (ADV990001) related to the servicing stack in all supported client and server Windows OSes.

The corresponding Knowledge Base articles indicate administrators should apply servicing stack updates before the latest cumulative update to ensure security updates arrive and install properly. The fact that all Windows systems require this update points to a significant change coming from Microsoft, possibly over the next few months, Goettl said. He recommended administrators put this update near the top of their priority list; otherwise, they could be in for a surprise when Patch Tuesday comes and their systems cannot install security updates.

“You should definitely start testing and planning this out. Ideally, if they can have it installed before October, that’s the best-case scenario, but definitely have it in place before November to avoid any last-minute scrambles,” Goettl said.

Go to Original Article
Author:

September Patch Tuesday addresses 2 Windows zero-days

September Patch Tuesday arrived with fixes for two zero-day vulnerabilities and three public disclosures that make patching the OS on both clients and servers a priority for administrators.

Microsoft addressed 79 unique vulnerabilities — 17 with a critical severity rating — including two Windows zero-days that administrators should put near the top of their patching priority list. As part of its September Patch Tuesday releases, Microsoft also closed bugs in its Internet Explorer and Edge browsers, Microsoft Office, Skype for Business, Exchange Server and Yammer. 

Microsoft squashes two Windows zero-days

A zero-day (CVE-2019-1214) in the Windows Common Log File System driver gives an attacker, who needs to have prior access to the network, a way to elevate privileges by running a specially crafted application. This vulnerability, rated important, affects all supported versions of Windows on the server and client side.

Chris Goettl, director of product management and security, IvantiChris Goettl

“This is what attackers will use to elevate their privilege level and be able to gain persistent access and start to pivot and move elsewhere the environment,” said Chris Goettl, director of product management and security at Ivanti, a security and IT management vendor based in South Jordan, Utah.

Microsoft patched another zero-day (CVE-2019-1215). This flaw in the Winsock component, rated important, lets an intruder who has gained access with local authentication run code with elevated privileges. This vulnerability affects all supported Windows systems on desktops and clients.

It’s important to weigh other factors in addition to the severity rating and the Common Vulnerability Scoring System (CVSS) score when determining the precedence of updates for systems, Goettl said. An administrator who gives critical updates top billing might miss these sorts of zero-days that have a less severe rating, he said.

“Typically, we recommend vendor severity, plus CVSS score, and use indicators like exploited or publicly disclosed as additional risk indicators that would raise the priority,” Goettl said.

Fixes issued for three public disclosures

In August, Tavis Ormandy of Google Project Zero revealed an elevation-of-privilege vulnerability in the Windows Text Service Framework. The exploit, which requires prior authentication on the system, lets the intruder run a specially crafted program to overtake the system. Microsoft closed this vulnerability (CVE-2019-1235), rated important for all supported Windows versions, by adjusting how the Text Service Framework server and client certify input from each other.

Our speculation is that the threat actors who are going to take advantage of BlueKeep are less likely to do so from a ransomware perspective.
Chris GoettlDirector of product management and security, Ivanti

“The risk of a public disclosure is that there is enough information about how to exploit this vulnerability in the wild. An attacker has an advanced start on research. They don’t have to reverse-engineer and try to figure it all out for themselves,” Goettl said.

CVE-2019-1253 — an elevation-of-privilege vulnerability rated important for Windows 10 and Windows Server 2019 systems — follows the same pattern as the other vulnerabilities: An attacker who has logged into a system can run code to elevate privileges. Microsoft’s update corrects the flaw in the Windows AppX Deployment Server, which handles tasks related to apps in the Microsoft Store.

The last public disclosure is a bug in the Windows secure boot security feature (CVE-2019-1294), rated important, that affects Windows 10 and Windows Server 2019 systems. The exploit requires physical access to a device running the OS, such as a laptop. Systems that use BitLocker and full-disk encryption would not be susceptible to this kind of attack, Goettl said.

Several Microsoft development tools patched

Administrators who manage Windows developer environments will need to examine the September Patch Tuesday releases closely for fixes affecting several coding-related tools and technologies, including the ChakraCore JavaScript component in the Edge browser, Visual Studio, the Project Rome software development kit, the .NET Framework and Team Foundation Server.

“The .NET Framework update was only for 3.5 and later, nothing earlier. This is one of those areas where people need to focus on moving forward from those older development tool sets that have reached end-of-life to continue to get security coverage from Microsoft,” Goettl said.

BlueKeep vulnerability continues to remain a concern

Microsoft continued to close holes in the Remote Desktop Client by addressing four critical vulnerabilities — CVE-2019-0787, CVE-2019-0788, CVE-2019-1290 and CVE-2019-1291 — that do not have the same “wormable” threat potential as BlueKeep and DejaBlue. The bugs fixed by the September Patch Tuesday updates would require some interaction from a user to trigger the exploit.

Even after multiple warnings from Microsoft, there has been no BlueKeep outbreak on Windows systems, despite recent exploit code releases. In one recent example, Metasploit — an open source penetration testing framework sponsored by security company Rapid7 — published a BlueKeep module on Sept. 6. The coders purposefully limited the module’s abilities to curb potential misuse.

“By default, Metasploit’s BlueKeep exploit only identifies the target operating system version and whether the target is likely to be vulnerable. The exploit does not currently support automatic targeting; it requires the user to manually specify target details before it will attempt further exploitation,” Rapid7 wrote in a blog.

Despite the outcry on Twitter related to the Metasploit release, other security vendors have released similar code, and Goettl said he suspects a global catastrophe might not come to fruition for one specific reason.

“Our speculation is that the threat actors who are going to take advantage of BlueKeep are less likely to do so from a ransomware perspective,” Goettl said. “If somebody did this from a cryptomining perspective and spread this out to hundreds of thousands of systems simultaneously — even for a few months — the revenue stream could be on the order of tens of millions of dollars, compared to the $200,000 WannaCry was able to extort over its five-month life.”

All Windows systems get critical servicing stack update

In what may be a prelude to upcoming changes to Windows updates, Microsoft issued an advisory (ADV990001) related to the servicing stack in all supported client and server Windows OSes.

The corresponding Knowledge Base articles indicate administrators should apply servicing stack updates before the latest cumulative update to ensure security updates arrive and install properly. The fact that all Windows systems require this update points to a significant change coming from Microsoft, possibly over the next few months, Goettl said. He recommended administrators put this update near the top of their priority list; otherwise, they could be in for a surprise when Patch Tuesday comes and their systems cannot install security updates.

“You should definitely start testing and planning this out. Ideally, if they can have it installed before October, that’s the best-case scenario, but definitely have it in place before November to avoid any last-minute scrambles,” Goettl said.

Go to Original Article
Author:

USBAnywhere vulnerabilities put Supermicro servers at risk

Security researchers discovered a set of vulnerabilities in Supermicro servers that could allow threat actors to remotely attack systems as if they had physical access to the USB ports.

Researchers at Eclypsium, based in Beaverton, Ore., discovered flaws in the baseboard management controllers (BMCs) of Supermicro servers and dubbed the set of issues “USBAnywhere.” The researchers said authentication issues put servers at risk because “BMCs are intended to allow administrators to perform out-of-band management of a server, and as a result are highly privileged components.

“The problem stems from several issues in the way that BMCs on Supermicro X9, X10 and X11 platforms implement virtual media, an ability to remotely connect a disk image as a virtual USB CD-ROM or floppy drive. When accessed remotely, the virtual media service allows plaintext authentication, sends most traffic unencrypted, uses a weak encryption algorithm for the rest, and is susceptible to an authentication bypass,” the researchers wrote in a blog post. “These issues allow an attacker to easily gain access to a server, either by capturing a legitimate user’s authentication packet, using default credentials, and in some cases, without any credentials at all.”

The USBAnywhere flaws make it so the virtual USB drive acts in the same way a physical USB would, meaning an attacker could load a new operating system image, deploy malware or disable the target device. However, the researchers noted the attacks would be possible on systems where the BMCs are directly exposed to the internet or if an attacker already has access to a corporate network.

Rick Altherr, principal engineer at Eclypsium, told SearchSecurity, “BMCs are one of the most privileged components on modern servers. Compromise of a BMC practically guarantees compromise of the host system as well.”

Eclypsium said there are currently “at least 47,000 systems with their BMCs exposed to the internet and using the relevant protocol.” These systems would be at additional risk because BMCs are rarely powered off and the authentication bypass vulnerability can persist unless the system is turned off or loses power.

Altherr said he found the USBAnywhere vulnerabilities because he “was curious how virtual media was implemented across various BMC implementations,” but Eclypsium found that only Supermicro systems were affected.

According to the blog post, Eclypsium reported the USBAnywhere flaws to Supermicro on June 19 and provided additional information on July 9, but Supermicro did not acknowledge the reports until July 29.

“Supermicro engaged with Eclypsium to understand the vulnerabilities and develop fixes. Supermicro was responsive throughout and worked to coordinate availability of firmware updates to coincide with public disclosure,” Altherr said. “While there is always room for improvement, Supermicro responded in a way that produced an amicable outcome for all involved.”

Altherr added that customers should “treat BMCs as a vulnerable device. Put them on an isolated network and restrict access to only IT staff that need to interact with them.”

Supermicro noted in its security advisory that isolating BMCs from the internet would reduce the risk to USBAnywhere but not eliminate the threat entirely . Firmware updates are currently available for affected Supermicro systems, and in addition to updating, Supermicro advised users to disable virtual media by blocking TCP port 623.

Go to Original Article
Author:

What is the Hyper-V Core Scheduler?

In the past few years, sophisticated attackers have targeted vulnerabilities in CPU acceleration techniques. Cache side-channel attacks represent a significant danger. They magnify on a host running multiple virtual machines. One compromised virtual machine can potentially retrieve information held in cache for a thread owned by another virtual machine. To address such concerns, Microsoft developed its new “HyperClear” technology pack. HyperClear implements multiple mitigation strategies. Most of them work behind the scenes and require no administrative effort or education. However, HyperClear also includes the new “core scheduler”, which might need you to take action.

The Classic Scheduler

Now that Hyper-V has all new schedulers, its original has earned the “classic” label. I wrote an article on that scheduler some time ago. The advanced schedulers do not replace the classic scheduler so much as they hone it. So, you need to understand the classic scheduler in order to understand the core scheduler. A brief recap of the earlier article:

  • You assign a specific number of virtual CPUs to a virtual machine. That sets the upper limit on how many threads the virtual machine can actively run.
  • When a virtual machine assigns a thread to a virtual CPU, Hyper-V finds the next available logical processor to operate it.

To keep it simple, imagine that Hyper-V assigns threads in round-robin fashion. Hyper-V does engage additional heuristics, such as trying to keep a thread with its owned memory in the same NUMA node. It also knows about simultaneous multi-threading (SMT) technologies, including Intel’s Hyper-Threading and AMD’s recent advances. That means that the classic scheduler will try to place threads where they can get the most processing power. Frequently, a thread shares a physical core with a completely unrelated thread — perhaps from a different virtual machine.

Risks with the Classic Scheduler

The classic scheduler poses a cross-virtual machine data security risk. It stems from the architectural nature of SMT: a single physical core can run two threads but has only one cache.

Classic SchedulerIn my research, I discovered several attacks in which one thread reads cached information belonging to the other. I did not find any examples of one thread polluting the others’ data. I also did not see anything explicitly preventing that sort of assault.

On a physically installed operating system, you can mitigate these risks with relative ease by leveraging antimalware and following standard defensive practices. Software developers can make use of fencing techniques to protect their threads’ cached data. Virtual environments make things harder because the guest operating systems and binary instructions have no influence on where the hypervisor places threads.

The Core Scheduler

The core scheduler makes one fairly simple change to close the vulnerability of the classic scheduler: it never assigns threads from more than one virtual machine to any physical core. If it can’t assign a second thread from the same VM to the second logical processor, then the scheduler leaves it empty. Even better, it allows the virtual machine to decide which threads can run together.

Hyper-V Core Scheduler

We will move on through implementation of the scheduler before discussing its impact.

Implementing Hyper-V’s Core Scheduler

The core scheduler has two configuration points:

  1. Configure Hyper-V to use the core scheduler
  2. Configure virtual machines to use two threads per virtual core

Many administrators miss that second step. Without it, a VM will always use only one logical processor on its assigned cores. Each virtual machine has its own independent setting.

We will start by changing the scheduler. You can change the scheduler at a command prompt (cmd or PowerShell) or by using Windows Admin Center.

How to Use the Command Prompt to Enable and Verify the Hyper-V Core Scheduler

For Windows and Hyper-V Server 2019, you do not need to do anything at the hypervisor level. You still need to set the virtual machines. For Windows and Hyper-V Server 2016, you must manually switch the scheduler type.

You can make the change at an elevated command prompt (PowerShell prompt is fine):

Note: if bcdedit does not accept the setting, ensure that you have patched the operating system.

Reboot the host to enact the change. If you want to revert to the classic scheduler, use “classic” instead of “core”. You can also select the “root” scheduler, which is intended for use with Windows 10 and will not be discussed further here.

To verify the scheduler, just run bcdedit by itself and look at the last line:

bcdedit

bcdedit will show the scheduler type by name. It will always appear, even if you disable SMT in the host’s BIOS/UEFI configuration.

How to Use Windows Admin Center to Enable the Hyper-V Core Scheduler

Alternatively, you can use Windows Admin Center to change the scheduler.

  1. Use Windows Admin Center to open the target Hyper-V host.
  2. At the lower left, click Settings. In most browsers, it will hide behind any URL tooltip you might have visible. Move your mouse to the lower left corner and it should reveal itself.
  3. Under Hyper-V Host Settings sub-menu, click General.
  4. Underneath the path options, you will see Hypervisor Scheduler Type. Choose your desired option. If you make a change, WAC will prompt you to reboot the host.

windows admin center

Note: If you do not see an option to change the scheduler, check that:

  • You have a current version of Windows Admin Center
  • The host has SMT enabled
  • The host runs at least Windows Server 2016

The scheduler type can change even if SMT is disabled on the host. However, you will need to use bcdedit to see it (see previous sub-section).

Implementing SMT on Hyper-V Virtual Machines

With the core scheduler enabled, virtual machines can no longer depend on Hyper-V to make the choice to use a core’s second logical processor. Hyper-V will expect virtual machines to decide when to use the SMT capabilities of a core. So, you must enable or disable SMT capabilities on each virtual machine just like you would for a physical host.

Because of the way this technology developed, the defaults and possible settings may seem unintuitive. New in 2019, newly-created virtual machines can automatically detect the SMT status of the host and hypervisor and use that topology. Basically, they act like a physical host that ships with Hyper-Threaded CPUs — they automatically use it. Virtual machines from previous versions need a bit more help.

Every virtual machine has a setting named “HwThreadsPerCore”. The property belongs to the Msvm_ProcessorSettingData CIM class, which connects to the virtual machine via its Msvm_Processor associated instance. You can drill down through the CIM API using the following PowerShell (don’t forget to change the virtual machine name):

The output of the cmdlet will present one line per virtual CPU. If you’re worried that you can only access them via this verbose technique hang in there! I only wanted to show you where this information lives on the system. You have several easier ways to get to and modify the data. I want to finish the explanation first.

The HwThreadsPerCore setting can have three values:

  • 0 means inherit from the host and scheduler topology — limited applicability
  • 1 means 1 thread per core
  • 2 means 2 threads per core

The setting has no other valid values.

A setting of 0 makes everything nice and convenient, but it only works in very specific circumstances. Use the following to determine defaults and setting eligibility:

  • VM config version < 8.0
    • Setting is not present
    • Defaults to 1 if upgraded to VM version 8.x
    • Defaults to 0 if upgraded to VM version 9.0+
  • VM config version 8.x
    • Defaults to 1
    • Cannot use a 0 setting (cannot inherit)
    • Retains its setting if upgraded to VM version 9.0+
  • VM config version 9.x
    • Defaults to 0

I will go over the implications after we talk about checking and changing the setting.

You can see a VM’s configuration version in Hyper-V Manager and PowerShell’s Get-VM :

Hyper-V Manager

The version does affect virtual machine mobility. I will come back to that topic toward the end of the article.

How to Determine a Virtual Machine’s Threads Per Core Count

Fortunately, the built-in Hyper-V PowerShell module provides direct access to the value via the *-VMProcessor cmdlet family. As a bonus, it simplifies the input and output to a single value. Instead of the above, you can simply enter:

If you want to see the value for all VMs:

You can leverage positional parameters and aliases to simplify these for on-the-fly queries:

You can also see the setting in recent version of Hyper-V Manager (Windows Server 2019 and current versions of Windows 10). Look on the NUMA sub-tab of the Processor tab. Find the Hardware threads per core setting:

settings

In Windows Admin Center, access a virtual machine’s Processor tab in its settings. Look for Enable Simultaneous Multithreading (SMT).

processors

If the setting does not appear, then the host does not have SMT enabled.

How to Set a Virtual Machine’s Threads Per Core Count

You can easily change a virtual machine’s hardware thread count. For either the GUI or the PowerShell commands, remember that the virtual machine must be off and you must use one of the following values:

  • 0 = inherit, and only works on 2019+ and current versions of Windows 10 and Windows Server SAC
  • 1 = one thread per hardware core
  • 2 = two threads per hardware core
  • All values above 2 are invalid

To change the setting in the GUI or Windows Admin Center, access the relevant tab as shown in the previous section’s screenshots and modify the setting there. Remember that Windows Admin Center will hide the setting if the host does not have SMT enabled. Windows Admin Center does not allow you to specify a numerical value. If unchecked, it will use a value of 1. If checked, it will use a value of 2 for version 8.x VMs and 0 for version 9.x VMs.

To change the setting in PowerShell:

To change the setting for all VMs in PowerShell:

Note on the cmdlet’s behavior: If the target virtual machine is off, the setting will work silently with any valid value. If the target machine is on and the setting would have no effect, the cmdlet behaves as though it made the change. If the target machine is on and the setting would have made a change, PowerShell will error. You can include the -PassThru parameter to receive the modified vCPU object:

Considerations for Hyper-V’s Core Scheduler

I recommend using the core scheduler in any situation that does not explicitly forbid it. I will not ask you to blindly take my advice, though. The core scheduler’s security implications matter, but you also need to think about scalability, performance, and compatibility.

Security Implications of the Core Scheduler

This one change instantly nullifies several exploits that could cross virtual machines, most notably in the Spectre category. Do not expect it to serve as a magic bullet, however. In particular, remember that an exploit running inside a virtual machine can still try to break other processes in the same virtual machine. By extension, the core scheduler cannot protect against threats running in the management operating system. It effectively guarantees that these exploits cannot cross partition boundaries.

For the highest level of virtual machine security, use the core scheduler in conjunction with other hardening techniques, particularly Shielded VMs.

Scalability Impact of the Core Scheduler

I have spoken with one person who was left with the impression that the core scheduler does not allow for oversubscription. They called into Microsoft support, and the engineer agreed with that assessment. I reviewed Microsoft’s public documentation as it was at the time, and I understand how they reached that conclusion. Rest assured that you can continue to oversubscribe CPU in Hyper-V. The core scheduler prevents threads owned by separate virtual machines from running simultaneously on the same core. When it starts a thread from a different virtual machine on a core, the scheduler performs a complete context switch.

You will have some reduced scalability due to the performance impact, however.

Performance Impact of the Core Scheduler

On paper, the core scheduler presents severe deleterious effects on performance. It reduces the number of possible run locations for any given thread. Synthetic benchmarks also show a noticeable performance reduction when compared to the classic scheduler. A few points:

  • Generic synthetic CPU benchmarks drive hosts to abnormal levels using atypical loads. In simpler terms, they do not predict real-world outcomes.
  • Physical hosts with low CPU utilization will experience no detectable performance hits.
  • Running the core scheduler on a system with SMT enabled will provide better performance than the classic scheduler on the same system with SMT disabled

Your mileage will vary. No one can accurately predict how a general-purpose system will perform after switching to the core scheduler. Even a heavily-laden processor might not lose anything. Remember that, even in the best case, an SMT-enabled core will not provide more than about a 25% improvement over the same core with SMT disabled. In practice, expect no more than a 10% boost. In the simplest terms: switching from the classic scheduler to the core scheduler might reduce how often you enjoy a 10% boost from SMT’s second logical processor. I expect few systems to lose much by switching to the core scheduler.

Some software vendors provide tools that can simulate a real-world load. Where possible, leverage those. However, unless you dedicate an entire host to guests that only operate that software, you still do not have a clear predictor.

Compatibility Concerns with the Core Scheduler

As you saw throughout the implementation section, a virtual machine’s ability to fully utilize the core scheduler depends on its configuration version. That impacts Hyper-V Replica, Live Migration, Quick Migration, virtual machine import, backup, disaster recovery, and anything else that potentially involves hosts with mismatched versions.

Microsoft drew a line with virtual machine version 5.0, which debuted with Windows Server 2012 R2 (and Windows 8.1). Any newer Hyper-V host can operate virtual machines of its version all the way down to version 5.0. On any system, run  Get-VMHostSupportedVersion to see what it can handle. From a 2019 host:

So, you can freely move version 5.0 VMs between a 2012 R2 host and a 2016 host and a 2019 host. But, a VM must be at least version 8.0 to use the core scheduler at all. So, when a v5.0 VM lands on a host running the core scheduler, it cannot use SMT. I did not uncover any problems when testing an SMT-disabled guest on an SMT-enabled host or vice versa. I even set up two nodes in a cluster, one with Hyper-Threading on and the other with Hyper-Threading off, and moved SMT-enabled and SMT-disabled guests between them without trouble.

The final compatibility verdict: running old virtual machine versions on core-scheduled systems means that you lose a bit of density, but they will operate.

Summary of the Core Scheduler

This is a lot of information to digest, so let’s break it down to its simplest components. The core scheduler provides a strong inter-virtual machine barrier against cache side-channel attacks, such as the Spectre variants. Its implementation requires an overall reduction in the ability to use simultaneous multi-threaded (SMT) cores. Most systems will not suffer a meaningful performance penalty. Virtual machines have their own ability to enable or disable SMT when running on a core-scheduled system. All virtual machine versions prior to 8.0 (WS2016/W10 Anniversary) will only use one logical processor per core when running on a core-scheduled host.

Go to Original Article
Author: Eric Siron

Zoom security issues leave vendor scrambling

Zoom was caught flatfooted this week by the reaction to a security researcher’s report on the vulnerabilities of a web server it had quietly installed on Apple computers. The debacle raised broader questions on whether unified communications vendors were too quick to sacrifice privacy and security for ease of use.

The Zoom security issue stemmed from the use of the web server as a workaround for a privacy feature on version 12 of the Safari web browser, which Apple released for the Mac last fall. The feature forced users to consent to open Zoom’s video app every time they tried to join a meeting. In contrast, browsers like Chrome and Firefox let users check a box telling them to automatically trust Zoom’s app in the future.

Zoom felt the extra click in Safari would undermine its frictionless experience for joining meetings, so it installed the web server on Mac computers to launch a meeting immediately.

That left Mac users vulnerable to being instantly joined to a Zoom meeting by clicking on a spam link or loading a malicious website or pop-up advertisement. A similar risk still exists for all Mac and PC users who choose to have their web browsers automatically launch Zoom.

Another issue with the Mac web server was that it would remain in place even after users deleted the Zoom app, and would automatically reinstall Zoom upon receiving a request to join a meeting, according to the security researcher. It also created an avenue for denial-of-service attacks, a risk that Zoom released an optional patch for in May.

In a broader sense, the permanent installation of a web server on local devices troubled independent researcher Jonathan Leitschuh, who sparked this week’s events with a blog post Monday.

“First off, let me start off by saying having an installed app that is running a web server on my local machine with a totally undocumented API feels incredibly sketchy to me,” Leitschuh wrote in his public disclosure. “Secondly, the fact that any website that I visit can interact with this web server running on my machine is a huge red flag for me as a security researcher.”

Leitschuh’s disclosure forced Zoom to issue multiple statements as user outrage grew. The security threat received widespread international news coverage, with many headlines containing the chilling combination of “hacker” and “webcam.” In an interview Wednesday, Zoom’s chief information security officer, Richard Farley, said the news coverage caused “maybe some panic that was unnecessary.”

“Part of the challenge for us, of course, is controlling that message out there that this was not as big a deal as it’s been made out to be,” Farley said. “There’s a lot of misinformation that went out there. … People just didn’t understand it.”

Zoom initially tried to assuage fears about the Mac web server without removing it. The company pointed out that it would be obvious to users they had just joined a meeting because a window would open in the foreground and their webcam’s indicator light would flash on. Also, a hacker couldn’t gain access to a webcam in secret or retain access to that video feed after users exited a meeting.  

Ultimately, Zoom reversed its original position and released a software update Tuesday that removed the web server from its Mac architecture. The next day, Apple pushed out a software patch that wiped the web server from all Mac devices, even for users who had previously deleted Zoom.

“We misjudged the situation and did not respond quickly enough — and that’s on us,” Zoom CEO Eric Yuan wrote in a blog post. “We take full ownership, and we’ve learned a great deal.”

Zoom’s default preferences added fuel to the fire. Unless users go out of their way to alter Zoom’s out-of-the-box settings, their webcams will be on by default when joining meetings. Also, Zoom does not by default have a pre-meeting lobby in which users confirm their audio and video settings before connecting.

Zoom said it would release an update over the July 13 weekend to make it easier for new users to control video settings. The first time a user joins a meeting, they will be able to instruct the app to join them to all future sessions with their webcams turned off.

Zoom has also taken heat for allowing embedded IFrame codes to launch Zoom meetings. In a statement, the company said IFrames — a method for adding HTML content to webpages — was necessary to support its integrations.

Leitschuh first raised the security issues with Zoom in March. The company invited him to its private bug bounty program, offering money in exchange for Leitschuh agreeing not to disclose his research publicly. Leitschuh, who said the proposed bounty was less than $1,000, declined because of the demand for secrecy.

Despite clashing over whether to remove the web server, Leitschuh and Zoom were able to agree on the severity of the risk it posed. They gave it a Common Vulnerability Scoring System rating of 5.4 out of 10. That score is in the “medium” range — riskier than “low” but not as severe as “high” or “critical.”

Zoom’s response to Leitschuh’s concerns was an indicator that companies have to verify the security architectures of UC vendors, analysts said.

“This event should be a clear reminder to both vendors and customers using UC and collaboration tools that there are very real threats to their platforms,” said Michael Brandenburg, analyst at Frost & Sullivan. “We are long past the days of only having to worry about toll fraud, and businesses have to be as mindful of the security risks on their UC platforms as they are with any other business application.”

Go to Original Article
Author: