Updated host packages that fix several bugs and add various enhancements are now available.
Red Hat Product Security has rated this update as having a security impact of Low. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) in the References section.This content is licensed under the Creative Commons Attribution 4.0 International License (https://creativecommons.org/licenses/by/4.0/). If you distribute this content, or a modified version of it, you must provide attribution to Red Hat Inc. and provide a link to the original.

Related CVEs:
* CVE-2022-0207: vdsm: disclosure of sensitive values in log files


Issued:

2022-05-26

Updated:

2022-05-26

**RHSA-2022:4764 - Security Advisory**

*   Overview
*   Updated Packages

**Synopsis**

Low: RHV RHEL Host (ovirt-host) \[ovirt-4.5.0\] security update

**Type/Severity**

Security Advisory: Low

**Red Hat Insights patch analysis**

Identify and remediate systems affected by this advisory.

View affected systems

**Topic**

Updated host packages that fix several bugs and add various enhancements are now available.  

Red Hat Product Security has rated this update as having a security impact of Low. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) in the References section.

**Description**

The ovirt-host package consolidates host package requirements into a single meta package.  

Security Fix(es) from Bugzilla:  

*   vdsm: disclosure of sensitive values in log files (CVE-2022-0207)

For more details about the security issue(s), including the impact, a CVSS score, and other related information, refer to the CVE page(s) listed in the References section.  

Bug Fix(es) from Bugzilla:  

*   With this release, RHV 4.4 SP1 has been upgraded to use ansible-core in cockpit-ovirt. (BZ#2066042)
*   Rebase package(s) to version: 0.16.0

Highlights and notable enhancements: https://github.com/oVirt/cockpit-ovirt/releases/tag/cockpit-ovirt-0.16.0 (BZ#2067078)  

*   Rebase package(s) to version: 0.6.2 (BZ#2060889)
*   Rebase package(s) to version: 4.5.0

Highlights, important fixes, or notable enhancements: (BZ#2054733)  

*   Feature: Include the package nvme-cli on virtualization hosts

Reason: The package is requested in RHEL 8 Managing Storage devices, Chapter 15. NVMe over fabrics using FC for accessing that hardware  

Result: the needed package is available on the host. (BZ#2058177)  

*   Previously, the ovirt-ha-broker service failed to start on a host with a DISA STIG profile.

In this release, the ovirt-ha-broker binaries were moved to /usr/libexec. As a result, the ovirt-ha-broker service succeeds to start on a host with a DISA STIG profile. (BZ#2050108)  

*   Previously, during self-hosted engine deployment, the tpgt value was not used in the iSCSI login, creating duplicate iSCSI sessions.

IN this release, the tpgt value is used in the iSCSI login, and no duplicate iSCSI sessions are created. (BZ#1768969)  

*   With this release, the self-hosted engine installation supports selecting either DISA STIG or PCI-DSS security profiles for the self-hosted engine VM. (BZ#2029830)
*   Red Hat Virtualization 4.4 SP1 now requires ansible-core >= 2.12.0 to execute Ansible playbooks/roles internally from RHV components. (BZ#2052686)
*   Rebase package(s) to version: 2.6.1

Highlights, important fixes, or notable enhancements: (BZ#2050512)  

*   RHV Hypervisor 4.4 SP1, with exception to RHV-H, is able to run on a host with RHEL 8.6 DISA STIG openscap profile applied. (BZ#2015802)
*   Previously, SCSI reservation was not set for disks that are hot-plugged.

In this release, the SCSI reservation works for disks that are being hot-plugged. (BZ#2028481)  

*   The Red Hat Virtualization Host is now capable of running on a machine with the PCI-DSS security profile. (BZ#2030226)
*   Previously, if storage problems occurred and disappeared during a VM migration attempt, it sometimes led to the VM being paused and not resuming even if the VM had an auto-resume policy set.

In this release, the VM is handled according to its resume behavior policy when the storage state changes during a VM migration attempt. (BZ#2010478)  

*   Previously, the VDSM used UDEV links to create the LVM filter. As a result, the LVM sometimes grabbed SCSI devices during the boot process by mistake.

In this release, the LVM does not not try to grab SCSI devices during the boot process, only using the multipath device specified in the LVM filter. (BZ#2016173)

**Affected Products**

*   Red Hat Virtualization 4 for RHEL 8 x86\_64
*   Red Hat Virtualization Host 4 for RHEL 8 x86\_64
*   Red Hat Virtualization for IBM Power LE 4 for RHEL 8 ppc64le

**Fixes**

*   BZ - 1768969 - Duplicate iSCSI sessions in the hosted-engine deployment host when the tpgt is not 1
*   BZ - 1787192 - Host fails to activate in RHV and goes to non-operational status when some of the iSCSI targets are down
*   BZ - 1878724 - vdsm-tool configure is failing with error "dependency job for libvirtd.service failed"
*   BZ - 1986732 - ovirt-ha services cannot set the LocalMaintenance mode in the storage metadata and are in a restart loop
*   BZ - 2010478 - After storage error HA VMs failed to auto resume.
*   BZ - 2015802 - \[RFE\] RHV hypervisors should support running on host with DISA STIG security profile applied
*   BZ - 2028481 - SCSI reservation is not working for hot plugged VM disks
*   BZ - 2029830 - \[RFE\] Hosted engine should accept OpenSCAP profile name instead of bool
*   BZ - 2030226 - \[RFE\] RHV hypervisors should support running on hosts with the PCI-DSS security profile applied
*   BZ - 2039248 - CVE-2022-0207 vdsm: disclosure of sensitive values in log files
*   BZ - 2050108 - hosted-engine-setup fails to start ovirt-ha-broker service on RHEL-H with DISA STIG
*   BZ - 2050512 - Upgrade ovirt-hosted-engine-setup to 2.6.1
*   BZ - 2052686 - \[RFE\] Upgrade to ansible-core-2.12 in hosted-engine-setup
*   BZ - 2054733 - Upgrade ovirt-host to 4.5.0
*   BZ - 2058177 - \[RFE\] Include the package nvme-cli on virtualization hosts
*   BZ - 2060889 - Upgrade mom to 0.6.2
*   BZ - 2066042 - Require ansible-core instead of ansible in cockpit-ovirt
*   BZ - 2067078 - Upgrade cockpit-ovirt to 0.16.0

**Red Hat Virtualization 4 for RHEL 8**

SRPM

cockpit-ovirt-0.16.0-1.el8ev.src.rpm

SHA-256: b23e8685b8d7faf23e980c925e0280916fc870b0fa1ecc237dbe809de1aa9bda

mom-0.6.2-1.el8ev.src.rpm

SHA-256: 82ba3b262493181643a8dfab13f9aa5e70017f54154fe32e905ea90b7069bfff

ovirt-host-4.5.0-3.el8ev.src.rpm

SHA-256: d1166d76602ea7f03034e33f3946394e1226c0162f7df1f941a906c99b07a21c

ovirt-hosted-engine-ha-2.5.0-1.el8ev.src.rpm

SHA-256: f3b7640b263137872c9e8620b0119ad494f0a34ed30b67bfab5afd5a9403e830

ovirt-hosted-engine-setup-2.6.3-1.el8ev.src.rpm

SHA-256: 9f2ac28fc950a0169a82f7c4a0ad0244c825577e7cc02afc5cb699ae5f854905

vdsm-4.50.0.13-1.el8ev.src.rpm

SHA-256: 8ff30e07005d8043faef41cdd8fa3017c0a1c0106a613c3056f83ec6201a6b03

x86\_64

cockpit-ovirt-dashboard-0.16.0-1.el8ev.noarch.rpm

SHA-256: b77bf2a335ed6583c10b43e2dd2a8a099bf7dcfb312aeb1e6570a231b1e54b72

mom-0.6.2-1.el8ev.noarch.rpm

SHA-256: 19fcefc67240eef84dff59b10b50830a308ff29b27e55e78c8c12adc945b1462

ovirt-host-4.5.0-3.el8ev.x86\_64.rpm

SHA-256: 43ab7bc3f778af133df5474fd59fc385e6df19ce21287b44433a5f39e7a95588

ovirt-host-dependencies-4.5.0-3.el8ev.x86\_64.rpm

SHA-256: c3f5a254acb35e907ba1a07bd262a56229997f94c0e4fd33ec7eb6aa78e51035

ovirt-hosted-engine-ha-2.5.0-1.el8ev.noarch.rpm

SHA-256: 1041de2d78b70282c8b29ff65c83c4888304ee653468df5686ed5b9f357f2016

ovirt-hosted-engine-setup-2.6.3-1.el8ev.noarch.rpm

SHA-256: 103dfeac88be836bd956c91a395bdb776b976e3b3dfbb3bd4e847ed41f1fe920

vdsm-4.50.0.13-1.el8ev.x86\_64.rpm

SHA-256: a798d7b8e3d85dbb28e6d85edcb1e24befedf7ceacfb4f185a8d8b95bb18dae9

vdsm-api-4.50.0.13-1.el8ev.noarch.rpm

SHA-256: e667e3200807e876ac7c00faa6f25d5a7bcf0259537332a263650fd61347ec41

vdsm-client-4.50.0.13-1.el8ev.noarch.rpm

SHA-256: fc71eb7b363ab958516d5773f8699d1eec80d99d48ecd328eaafd922afc8d090

vdsm-common-4.50.0.13-1.el8ev.noarch.rpm

SHA-256: 7ee7d224365829004598fbe485b0bdf2151bac3eb9705685312fb0e62db36370

vdsm-gluster-4.50.0.13-1.el8ev.x86\_64.rpm

SHA-256: 39f7d4837436ef1ccee57460c909b1de7892d7578db22fea934a7a3b9dc25112

vdsm-hook-checkips-4.50.0.13-1.el8ev.x86\_64.rpm

SHA-256: d238ae9cd1021557630afba6478b5e7fa27edeac1339eef19e9af16b46a1a4de

vdsm-hook-cpuflags-4.50.0.13-1.el8ev.noarch.rpm

SHA-256: 6ec052ca4f0fcc98366dfb4b0521e0c9d9b1088c33a98e9c681541900091e0cb

vdsm-hook-ethtool-options-4.50.0.13-1.el8ev.noarch.rpm

SHA-256: 99fabcee39c1dc83e6cac894b82d82f36cd38cb2061c99172d157fb9e63f2932

vdsm-hook-extra-ipv4-addrs-4.50.0.13-1.el8ev.x86\_64.rpm

SHA-256: 89614050ba8359110b53825f2bb01e8bcc269eb785dbb9c0344ff0c1ad45c7c9

vdsm-hook-fcoe-4.50.0.13-1.el8ev.noarch.rpm

SHA-256: dfc2c9d0b29075efa99dbe05cf4eda59786b7b1f1fe2a69db842a935b8a21c39

vdsm-hook-localdisk-4.50.0.13-1.el8ev.noarch.rpm

SHA-256: 8abd1856ba594f8a6c980fdd4088cd721db631bad127365bd33d89a4c478a255

vdsm-hook-nestedvt-4.50.0.13-1.el8ev.noarch.rpm

SHA-256: 0e4fa0b75ec917c7e3a7cb388f38cef16793403e6ac2334c0e8e050845fbc4f7

vdsm-hook-openstacknet-4.50.0.13-1.el8ev.noarch.rpm

SHA-256: 4ae6af3ec3ae8bac1e82b02c06db4eb54ea53be2d140bd57fc8d91efc5e9b64b

vdsm-hook-vhostmd-4.50.0.13-1.el8ev.noarch.rpm

SHA-256: 173c1a2d9d20cbd7188786bd95d86de9149990480b1445b9e08f84bcf78c4913

vdsm-http-4.50.0.13-1.el8ev.noarch.rpm

SHA-256: f0bbc789f386dd1de23fff43c560f7be38c628da11b6d7595b0a7e314dff4e1a

vdsm-jsonrpc-4.50.0.13-1.el8ev.noarch.rpm

SHA-256: 4c6c249fc713e685a80fdd580ba92791e749caf47d1eb26e769b28ae7c76cf26

vdsm-network-4.50.0.13-1.el8ev.x86\_64.rpm

SHA-256: 5b3e765488bda88909183d0ddd6a59906a43445fe5685ee3693ad0800af9805f

vdsm-python-4.50.0.13-1.el8ev.noarch.rpm

SHA-256: 9fd659051bbbaea19a2ada0749312a78d6ff2ab5ffec2b761e85af037eb10d03

vdsm-yajsonrpc-4.50.0.13-1.el8ev.noarch.rpm

SHA-256: 72dfd63af79369366450a09d2a2779ddda6b06b295619fa02de718e3a9a2520a

**Red Hat Virtualization Host 4 for RHEL 8**

SRPM

vdsm-4.50.0.13-1.el8ev.src.rpm

SHA-256: 8ff30e07005d8043faef41cdd8fa3017c0a1c0106a613c3056f83ec6201a6b03

x86\_64

vdsm-hook-checkips-4.50.0.13-1.el8ev.x86\_64.rpm

SHA-256: d238ae9cd1021557630afba6478b5e7fa27edeac1339eef19e9af16b46a1a4de

vdsm-hook-cpuflags-4.50.0.13-1.el8ev.noarch.rpm

SHA-256: 6ec052ca4f0fcc98366dfb4b0521e0c9d9b1088c33a98e9c681541900091e0cb

vdsm-hook-ethtool-options-4.50.0.13-1.el8ev.noarch.rpm

SHA-256: 99fabcee39c1dc83e6cac894b82d82f36cd38cb2061c99172d157fb9e63f2932

vdsm-hook-extra-ipv4-addrs-4.50.0.13-1.el8ev.x86\_64.rpm

SHA-256: 89614050ba8359110b53825f2bb01e8bcc269eb785dbb9c0344ff0c1ad45c7c9

vdsm-hook-fcoe-4.50.0.13-1.el8ev.noarch.rpm

SHA-256: dfc2c9d0b29075efa99dbe05cf4eda59786b7b1f1fe2a69db842a935b8a21c39

vdsm-hook-localdisk-4.50.0.13-1.el8ev.noarch.rpm

SHA-256: 8abd1856ba594f8a6c980fdd4088cd721db631bad127365bd33d89a4c478a255

vdsm-hook-nestedvt-4.50.0.13-1.el8ev.noarch.rpm

SHA-256: 0e4fa0b75ec917c7e3a7cb388f38cef16793403e6ac2334c0e8e050845fbc4f7

vdsm-hook-openstacknet-4.50.0.13-1.el8ev.noarch.rpm

SHA-256: 4ae6af3ec3ae8bac1e82b02c06db4eb54ea53be2d140bd57fc8d91efc5e9b64b

vdsm-hook-vhostmd-4.50.0.13-1.el8ev.noarch.rpm

SHA-256: 173c1a2d9d20cbd7188786bd95d86de9149990480b1445b9e08f84bcf78c4913

**Red Hat Virtualization for IBM Power LE 4 for RHEL 8**

SRPM

mom-0.6.2-1.el8ev.src.rpm

SHA-256: 82ba3b262493181643a8dfab13f9aa5e70017f54154fe32e905ea90b7069bfff

ovirt-host-4.5.0-3.el8ev.src.rpm

SHA-256: d1166d76602ea7f03034e33f3946394e1226c0162f7df1f941a906c99b07a21c

ovirt-hosted-engine-ha-2.5.0-1.el8ev.src.rpm

SHA-256: f3b7640b263137872c9e8620b0119ad494f0a34ed30b67bfab5afd5a9403e830

vdsm-4.50.0.13-1.el8ev.src.rpm

SHA-256: 8ff30e07005d8043faef41cdd8fa3017c0a1c0106a613c3056f83ec6201a6b03

ppc64le

mom-0.6.2-1.el8ev.noarch.rpm

SHA-256: 19fcefc67240eef84dff59b10b50830a308ff29b27e55e78c8c12adc945b1462

ovirt-host-4.5.0-3.el8ev.ppc64le.rpm

SHA-256: 870088ef9d5b9716c4c40539d6c6c9f4a50bbd1d9c369473f51651599e2a9ef1

ovirt-host-dependencies-4.5.0-3.el8ev.ppc64le.rpm

SHA-256: c2f49bae4396f240ab319668e16e18453a80b2de98aee2226e332d0442d3ced3

vdsm-4.50.0.13-1.el8ev.ppc64le.rpm

SHA-256: 914117641badbe81593a460711211049c13cba379d789f5b186343835609a4d1

vdsm-api-4.50.0.13-1.el8ev.noarch.rpm

SHA-256: e667e3200807e876ac7c00faa6f25d5a7bcf0259537332a263650fd61347ec41

vdsm-client-4.50.0.13-1.el8ev.noarch.rpm

SHA-256: fc71eb7b363ab958516d5773f8699d1eec80d99d48ecd328eaafd922afc8d090

vdsm-common-4.50.0.13-1.el8ev.noarch.rpm

SHA-256: 7ee7d224365829004598fbe485b0bdf2151bac3eb9705685312fb0e62db36370

vdsm-hook-checkips-4.50.0.13-1.el8ev.ppc64le.rpm

SHA-256: 00a92ef1e9b38a93db57d9a85e9e4f3453ce140c6117e3f44cdfe216228211a5

vdsm-hook-cpuflags-4.50.0.13-1.el8ev.noarch.rpm

SHA-256: 6ec052ca4f0fcc98366dfb4b0521e0c9d9b1088c33a98e9c681541900091e0cb

vdsm-hook-ethtool-options-4.50.0.13-1.el8ev.noarch.rpm

SHA-256: 99fabcee39c1dc83e6cac894b82d82f36cd38cb2061c99172d157fb9e63f2932

vdsm-hook-extra-ipv4-addrs-4.50.0.13-1.el8ev.ppc64le.rpm

SHA-256: 30ed18a29ab73266a218e9a06f14b967ebbe752d728f00aaddcdd5ea464dcb8b

vdsm-hook-fcoe-4.50.0.13-1.el8ev.noarch.rpm

SHA-256: dfc2c9d0b29075efa99dbe05cf4eda59786b7b1f1fe2a69db842a935b8a21c39

vdsm-hook-localdisk-4.50.0.13-1.el8ev.noarch.rpm

SHA-256: 8abd1856ba594f8a6c980fdd4088cd721db631bad127365bd33d89a4c478a255

vdsm-hook-nestedvt-4.50.0.13-1.el8ev.noarch.rpm

SHA-256: 0e4fa0b75ec917c7e3a7cb388f38cef16793403e6ac2334c0e8e050845fbc4f7

vdsm-hook-openstacknet-4.50.0.13-1.el8ev.noarch.rpm

SHA-256: 4ae6af3ec3ae8bac1e82b02c06db4eb54ea53be2d140bd57fc8d91efc5e9b64b

vdsm-hook-vhostmd-4.50.0.13-1.el8ev.noarch.rpm

SHA-256: 173c1a2d9d20cbd7188786bd95d86de9149990480b1445b9e08f84bcf78c4913

vdsm-http-4.50.0.13-1.el8ev.noarch.rpm

SHA-256: f0bbc789f386dd1de23fff43c560f7be38c628da11b6d7595b0a7e314dff4e1a

vdsm-jsonrpc-4.50.0.13-1.el8ev.noarch.rpm

SHA-256: 4c6c249fc713e685a80fdd580ba92791e749caf47d1eb26e769b28ae7c76cf26

vdsm-network-4.50.0.13-1.el8ev.ppc64le.rpm

SHA-256: 5f08b15f6e689572f04b01b8b062b5cc109c4b95d16ad788e1d0bc9ddb570de1

vdsm-python-4.50.0.13-1.el8ev.noarch.rpm

SHA-256: 9fd659051bbbaea19a2ada0749312a78d6ff2ab5ffec2b761e85af037eb10d03

vdsm-yajsonrpc-4.50.0.13-1.el8ev.noarch.rpm

SHA-256: 72dfd63af79369366450a09d2a2779ddda6b06b295619fa02de718e3a9a2520a

The Red Hat security contact is secalert@redhat.com. More contact details at https://access.redhat.com/security/team/contact/.

RHSA-2022:4764: Red Hat Security Advisory: RHV RHEL Host (ovirt-host) [ovirt-4.5.0] security update

An improper privilege vulnerability has been discovered in Citrix Gateway Plug-in for Windows (Citrix Secure Access for Windows) <21.9.1.2 what could allow an attacker who has gained local access to a computer with Citrix Gateway Plug-in installed, to corrupt or delete files as SYSTEM.

CTX341455

{{tooltipText}}

Security Bulletin | Medium | {{likeCount}} found this helpful | Created: {{articleFormattedCreatedDate}} | Modified: {{articleFormattedModifiedDate}}

**Description of Problem**

A vulnerability has been discovered in Citrix Gateway Plug-in for Windows (Citrix Secure Access for Windows). If exploited, this issue would allow an adversary, who has gained local access to a computer with Citrix Gateway Plug-in installed, to corrupt or delete files as SYSTEM. This issue has the following identifier: 

CVE-ID  

Description  

CWE  

Pre-conditions 

CVE-2022-21827 

Arbitrary corruption or deletion of files as SYSTEM 

CWE-284: Improper Access Control 

Local access to a machine that has the vulnerable plug-in installed 

The following supported versions of Citrix Gateway Plug-in for Windows (Citrix Secure Access for Windows) are affected by this vulnerability: 

*   Citrix Gateway Plug-in for Windows versions before 21.9.1.2 
    

**What Customers Should Do**

This issue has been addressed in the following versions of Citrix Gateway Plug-in for Windows (Citrix Secure Access for Windows): 

*   Citrix Gateway Plug-in for Windows version 21.9.1.2 and later releases 
    

Citrix recommends that affected customers upgrade the Citrix Gateway Plug-in installed on their endpoints by taking the following actions as their patching schedule allows:   

1.  If Citrix Gateway Plug-in is distributed via the SSL VPN upgrade control feature of Citrix ADC or Citrix Gateway:  
    

Check the version of Citrix Gateway Plug-in for Windows that is being distributed by each Citrix ADC or Citrix Gateway instance. This can be done using either GUI or by viewing the file located at /var/netscaler/gui/vpn/pluginlist.xml. If it is a vulnerable version, customers must either: 

*   upgrade the Citrix ADC or Gateway firmware to a version that includes a fixed version of the Plug-in. 

A fixed version of Citrix Gateway Plug-in for Windows is included in the following versions of Citrix ADC and Citrix Gateway:  

*   Citrix ADC and Citrix Gateway 13.1-4.44 and later releases   
    
*   Citrix ADC and Citrix Gateway 13.0-83.29 and later releases  
    
*   Citrix ADC and Citrix Gateway 12.1-63.22 and later releases  
    
*   Citrix ADC and Citrix Gateway 12.1-FIPS 12.1-55.277 and later releases   
    
*   Citrix ADC and Citrix Gateway 12.1-NDcPP 12.1-55.276 and later releases  
    

*   directly replace the vulnerable plug-in on the Citrix ADC or Gateway firmware without upgrading the firmware by following the instructions at: https://www.citrix.com/downloads/citrix-gateway/plug-ins/citrix-secure-access-client-for-windows.html. 
    
    Note that this option is only currently available on Citrix ADC and Citrix Gateway 13.1 or 13.0-76.31 and above. 
    

Information about the upgrade control feature is detailed at: https://docs.citrix.com/en-us/citrix-gateway/13/vpn-user-config/how-users-connect-with-gateway-plugin.html#control-upgrade-of-citrix-gateway-plug-ins  

2.  If Citrix Gateway Plug-in is distributed/upgraded directly onto users' devices:    
    

Customers must install a fixed Plug-in on their users' devices by downloading it from https://www.citrix.com/downloads/citrix-gateway/plug-ins/citrix-secure-access-client-for-windows.html  

**Acknowledgements**

Citrix thanks Brecht Snijders for working with us to protect Citrix customers.

**What Citrix is Doing**

Citrix is notifying customers and channel partners about this potential security issue through the publication of this security bulletin on the Citrix Knowledge Center at https://support.citrix.com/securitybulletins.

**Obtaining Support on This Issue**

If you require technical assistance with this issue, please contact Citrix Technical Support. Contact details for Citrix Technical Support are available at https://www.citrix.com/support/open-a-support-case.

**Subscribe to Receive Alerts**

Citrix strongly recommends that all customers subscribe to receive alerts when a Citrix security bulletin is created or modified at https://support.citrix.com/user/alerts.

**Reporting Security Vulnerabilities to Citrix**

Citrix welcomes input regarding the security of its products and considers any and all potential vulnerabilities seriously. For details on our vulnerability response process and guidance on how to report security-related issues to Citrix, please see the following webpage: https://www.citrix.com/about/trust-center/vulnerability-process.html.

**Disclaimer**

This document is provided on an "as is" basis and does not imply any kind of guarantee or warranty, including the warranties of merchantability or fitness for a particular use. Your use of the information on the document is at your own risk. Citrix reserves the right to change or update this document at any time. Customers are therefore recommended to always view the latest version of this document directly from the Citrix Knowledge Center.

**Changelog**

Date

Change

2022-04-12

Initial Publication

CVE-2022-21827: Citrix Gateway Plug-in for Windows Security Bulletin for CVE-2022-21827

The new draft guidance on premarket submissions incorporates quality system regulations and doubles down on a life-cycle approach to product security.

It's hard to believe, but medical device manufacturers who are subject to Food and Drug Administration premarket approval — the FDA process of review to evaluate the safety and effectiveness of Class III medical devices — are still operating under the FDA's original medical device cybersecurity guidance from 2014 and a subsequent update in 2018. But that is about to change in a major way.

Instead of finalizing the 2018 premarket cybersecurity draft guidance, the FDA has decided to issue a new 2022 version to reflect the rapid evolution of cybersecurity, incorporating a new set of quality system regulations (QSRs) with significant changes to its 2018 predecessor.

**New FDA Draft Guidance  
**The new draft guidance, titled "Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions," deals with myriad design, labeling, and documentation issues that will have to be addressed by medical device manufacturers before their new devices can gain FDA premarket approval.

The FDA's original guidance on cybersecurity was just nine pages while the 2022 version swells to 50 pages, reflecting advancements in the cybersecurity ecosystem and best practices. It appears that, when approving connected medical devices for market, the FDA will be taking a long look at how cybersecurity is implemented, especially regarding levels of risk to patient safety.

**Updated Regulations: Why Now?  
**Requiring greater cybersecurity measures to protect medical devices and their operational and patient data is vital since the healthcare industry has become a massive target of cyberattacks. Data breaches hit an all-time high in 2021, exposing a record volume of protected health information. Besides pilfering data, a growing number of breaches attempt to disrupt the smooth operation of medical devices like computed tomography and magnetic resonance imaging machines, potentially causing incorrect diagnoses, unnecessary medical procedures, or direct harm to patients.

The American Hospital Association's senior adviser for cybersecurity and risk has stated that medical devices used in hospital rooms suffer from an average of 6.2 vulnerabilities. As devices become more complex and interconnected, opportunities for cyberattackers to exploit vulnerabilities are becoming greater, hence the need for updated regulations.

**Incorporating Cybersecurity into Quality System Regulations to Boost Safety  
**With the new guidance, the FDA seeks to ensure that the next generation of medical devices will be far safer and secure throughout the entire device life cycle, from premarket and throughout the entire useful life, beginning from the earliest stages of design (shift-left) to post-production (shift-right).

With the proposed guidance, the FDA is doubling down on its efforts to incorporate cybersecurity into quality regulations to address the complexity of modern devices and today's evolving threat landscape.

**From CBOM to SBOM: What's the Difference?  
**Surprisingly, one of the major changes that the new guidance brings is a leniency in the requirement for manufacturers to provide a complete software bill of materials (SBOM) instead of a more tedious cybersecurity bill of materials (CBOM), as was required in the 2018 draft. Medical device manufacturers were balking at the 2018 guidelines because of this stringency.

An SBOM is more in line with cybersecurity standards across most industries and aligns with the Biden administration's recently issued Executive Order 14028, "Improving the Nation's Cybersecurity." It contains all of the required software packages (commercial and open source) and their versions.

The much more complicated CBOM, according to the 2018 guidance, demands "a list of commercial, open source, and off-the-shelf software and hardware components to enable device users (including patients, care providers, and healthcare delivery organizations) to effectively manage their assets, understand the potential impact of identified vulnerabilities to the device — and the connected system — and to deploy countermeasures to maintain the device's essential performance."

**A Secure Product Development Framework for Every Device  
**The latest guidance asks medical device manufacturers to consider using a secure product development framework (SPDF) to achieve the goals of the QSR: "An SPDF encompasses all aspects of a product's lifecycle, including development, release, support, and decommission."

Besides compliance with the draft guidance, the call for using an SPDF can add significant value to medical devices. As the draft guideline states: "Using SPDF processes during device design may prevent the need to re-engineer the device when connectivity-based features are added after marketing and distribution, or when vulnerabilities resulting in uncontrolled risks are discovered."

**Is the New FDA Draft Guidance Binding?  
**Until July 7, the FDA is inviting medical device manufacturers and the public to comment on the new draft, which is expected to be finalized later this year when it will become the new FDA cybersecurity guidance for medical devices. While FDA guidance is nonbinding, the approved version will provide a road map for how medical device manufacturers should address cybersecurity in their products to ensure compliance and patient safety.

The FDA is not the only federal agency looking to strengthen cybersecurity regs. Legislation called the Protecting and Transforming Cyber Health Care (PATCH) Act was recently introduced in the US Congress. The act, the EO, and other proposed bills contain provisions that will strengthen the FDA's ability to require medical device manufacturers to meet certain cybersecurity objectives.

In order to future-proof for impending legislation, medical device manufacturers should start investigating solutions that can generate detailed SBOMs and continuously detect vulnerabilities and mitigate risks in order to stay compliant with the FDA's 2022 guidance and beyond.

The FDA's New Cybersecurity Guidance for Medical Devices Reminds Us That Safety & Security Go Hand in Hand

Global ransomware incidents target everything from enterprise servers to grounding an airline, with one India-based group even taking a Robin Hood approach to extortion with the "GoodWill" strain.

Ransomware incidents are on the rise and this week proved no exception, with the discovery of a Linux-based ransomware family called Cheerscrypt targeting VMware ESXi servers and an attack on SpiceJet, India’s second largest airline.  

Meanwhile, an oddball "GoodWill" variant purports to help the needy.

The Cheerscrypt ransomware variant was uncovered by Trend Micro and relies on the double-extortion scheme to coerce victims to pay the ransom – i.e., stealing data as well and threatening to leak it if victims don’t pay up.

Because of the popularity of ESXi servers for creating and running multiple virtual machines (VMs) in enterprise settings, the Cheerscrypt ransomware could be appealing to malicious actors looking to rapidly distribute ransomware across many devices.

Meanwhile, low-cost carrier SpiceJet faced a ransomware attack this week, causing flight delays of between two and five hours as well as rendering unavailable online booking systems and customer service portals.

While the company’s IT team announced on Twitter that it had successfully prevented the attempted attack before it was able to fully breach all internal systems and take them over, customers and employees are still experiencing the ramifications.

**GoodWill: The Altruistic Ransomware  
**Then there's this: Researchers with CloudSEK announced this week they had discovered a Robin Hood-esque ransomware group called GoodWill, which demands that its victims perform three acts of charity in exchange for a decryption key.

GoodWill was discovered in March and uses a ransomware worm that encrypts documents and databases — among other important files — and renders them inaccessible without the decryption key.

The charitable actions that are accepted include taking poor children to fast-food restaurants, donating clothes to the homeless, and providing financial assistance to those in need of medical care. These actions must be backed up by photos posted to social media, the gang demands.

**Businesses Struggle to Keep Pace With Evolving Attacks  
**This week’s spate of ransomware attacks indicated no clear pattern but are rather more akin to the efforts of a marketing and sales department, says Stan Black, CISO at Delinea, a provider of privileged access-management solutions.

“Think about it: They harvest your information, alter their method delivery, they keep coming back until you bite, and when they get you on the hook, they demand a ransom,” he tells Dark Reading. “They are unregulated, don’t answer to legal, a board, or auditors, and don’t care whose business or lives they ruin.”

Black points out that there needs to be a recognition that malicious actors know more about IT operations than organizations think they do.

“For 24 hours a day, they are crawling every facet of our digital footprint and exhaust trail,” he says. “Through automation, they distill our telemetry and create the perfect go-to-market strategy: a cyberattack. These days, ransomware is targeting our identity and access-control security technology — the very tech we thought would protect us.”

Matthew Warner, CTO and co-founder at Blumira, a provider of automated threat detection and response technology, says it’s extremely important that organizations focus on detecting the first three steps of a ransomware attack: discovery, gaining a foothold, and escalating privileges.

"Detection, in addition to being aware as to what data you hold, will allow you to quickly respond to attacks and worst case be sure of post-exploitation handling of a ransomware event," he tells Dark Reading.

He adds that going forward, it also becomes clearer that time to respond and patch has been reduced, down to hours at the most.

“Evaluating your exposed attack surface should be the first item on your list, to ensure that your infrastructure is protected,” Warner says.

**DBIR Report Finds Ransomware Attacks Ballooning  
**Verizon also published its 15th annual "Data Breach Investigations Report" (DBIR), this week, which highlighted the emergence of ransomware-as-a-service (RaaS) as one of the factors behind the ballooning number of ransomware incidents.

The report, which analyzed 23,896 security incidents — of which 5,212 were confirmed breaches — found email phishing and desktop-sharing software were the most common ransomware attack points.

Overall, ransomware accounts for 25% of the total breaches, and was present in 70% of the malware breaches this year.

From Warner’s perspective, ransomware techniques have not necessarily evolved but, rather, have expanded over the last five years. For instance, previously, only certain groups would have the capability to perform advanced attacks that leverage zero-days within days of release. Now, it's no longer required to find your own.

“Now we see ransomware operators either buying or identifying their zero-days and leveraging zero-days as soon as possible within their campaigns,” he notes.

Warner also points out that ransomware operators are leveraging tooling improvements such as Cobalt Strike, enabling their evolution into a virtuous cycle: More funds allow for better tooling, processes, and execution across the environment, which leads to more funds.

That also paves the way for the gangs to expand their teams, as well.

“The ability to perform passive phishing attacks while also actively attacking vulnerable infrastructure with a team of paid hackers creates a unique and powerful environment for ransomware operators,” he explains.

VMware, Airline Targeted as Ransomware Chaos Reigns

ChromeOS uses usbguard when the screen is locked but appears to suffer from bypass issues.

    ChromeOS' usage of usbguard is bypassableVULNERABILITY DETAILSChromeOS uses https://usbguard.github.io/ when the screen is locked (but noton the login screen, perhaps because it is expected that code execution is muchless helpful when the disk is still encrypted?).When the screen is locked, a policy is applied that might look like this(example from my Pixelbook):```allow id 0bda:564b serial \"\\x07LOE65001063010A78M015CFAI06BF12000\" name \"WebCamera\" hash \"KsByWtMB5JtGNDimauArXMiZOThFwagdTWeQsMAZ48c=\" with-interface { 0e:01:00 0e:02:00 0e:02:00 0e:02:00 0e:02:00 0e:02:00 0e:02:00 0e:02:00 0e:02:00 } with-connect-type \"hardwired\"allow id 1d6b:0002 serial \"0000:00:14.0\" name \"xHCI Host Controller\" hash \"jEP/6WzviqdJ5VSeTUY8PatCNBKeaREvo2OqdplND/o=\" with-interface 09:00:00 with-connect-type \"\"allow id 1d6b:0003 serial \"0000:00:14.0\" name \"xHCI Host Controller\" hash \"3Wo3XWDgen1hD5xM3PSNl3P98kLp1RUTgGQ5HSxtf8k=\" with-interface 09:00:00 with-connect-type \"\"allow id 8087:0a2a serial \"\" name \"\" hash \"AyPZWy2XK0931kB9A/owYfk5xHEqnpDsJfdeLSGIyuk=\" with-interface { e0:01:01 e0:01:01 e0:01:01 e0:01:01 e0:01:01 e0:01:01 e0:01:01 } with-connect-type \"hardwired\"##################################################################################################### Footer.####################################################################################################block with-interface one-of { 05:*:* 06:*:* 07:*:* 08:*:* } # physical, image, printer, storageallow```As you can see, it mostly just allowlists specific devices with full hashes ofthe expected USB configuration descriptors, and internal USB devices are markedsuch that they won't be accepted on external USB ports.(Which, by the way, might not actually be necessary, since the USB subsystem's`authorized_default` flag is set to 2 when the screen is locked, not 0, meaninginternal USB devices are automatically allowed anyway?)But then at the bottom is this footer that blocks USB devices with interfacedescriptors that contain the following `bInterfaceClass` values: - USB_CLASS_PHYSICAL (5) - USB_CLASS_STILL_IMAGE (6) - USB_CLASS_PRINTER (7) - USB_CLASS_MASS_STORAGE (8)Afterwards, anything else is permitted.This configuration footer comes from<https://source.chromium.org/chromiumos/chromiumos/codesearch/+/main:src/third_party/chromiumos-overlay/sys-apps/usbguard/files/99-rules.conf>.The interface-based classification of devices was introduced in<https://chromium-review.googlesource.com/c/chromiumos/overlays/chromiumos-overlay/+/1217622/>.Apart from the problem that there is a large amount of attack surface in driversfor devices that don't belong into those USB interface classes, there is anotherissue with this approach:The kernel often doesn't care what USB class a device claims to be. The way USBdrivers tend to work, even for standardized protocols, is that the driverspecifies with low priority that it would like to bind to standards-compliantdevices using the proper USB interface class, but also specifies with highpriority that it would like to bind to specific USB devices based on Vendor IDand Product ID, without caring about their USB interface class.As an example, USB_CLASS_MASS_STORAGE is blocklisted, so a USB stick insertedwhile the screen is locked doesn't get past the authorization check:[ 6411.611320] usb 1-1: new high-speed USB device number 31 using xhci_hcd[ 6411.738900] usb 1-1: New USB device found, idVendor=0781, idProduct=5580, bcdDevice= 0.10[ 6411.738910] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3[ 6411.738916] usb 1-1: Product: [...][ 6411.738921] usb 1-1: Manufacturer: SanDisk[ 6411.738926] usb 1-1: SerialNumber: [...][ 6411.740583] usb 1-1: Device is not authorized for usage[ 6414.875133] cros-ec-sensorhub [...][ 6418.603609] usb 1-1: USB disconnect, device number 31But if we use a Linux machine with appropriate hardware (I'm using a NET2380 devboard, but you could probably also do it with an unlocked Pixel phone or aRaspberry Pi Zero W or something like that) to emulate a USB Mass Storagedevice, using <https://docs.kernel.org/usb/mass-storage.html>, and patch oneline in the attacker kernel so that it claims to be a billboard, not a storagedevice:diff --git a/drivers/usb/gadget/function/storage_common.c b/drivers/usb/gadget/function/storage_common.cindex b859a158a414..d7452c8458a9 100644--- a/drivers/usb/gadget/function/storage_common.c+++ b/drivers/usb/gadget/function/storage_common.c@@ -34,7 +34,7 @@ struct usb_interface_descriptor fsg_intf_desc = {   .bDescriptorType =  USB_DT_INTERFACE,    .bNumEndpoints =  2,    /* Adjusted during fsg_bind() */-  .bInterfaceClass =  USB_CLASS_MASS_STORAGE,+  .bInterfaceClass =  USB_CLASS_BILLBOARD,   .bInterfaceSubClass =  USB_SC_SCSI,  /* Adjusted during fsg_bind() */   .bInterfaceProtocol =  USB_PR_BULK,  /* Adjusted during fsg_bind() */   .iInterface =    FSG_STRING_INTERFACE,Then we can connect just fine even while the screen is locked - first we get a\"Device is not authorized\" message on the initial connection, then usbguardunblocks us and the kernel probes the device as a mass storage device and scansthe partition table:[ 6432.752906] usb 1-1: new high-speed USB device number 32 using xhci_hcd[ 6432.885635] usb 1-1: New USB device found, idVendor=0525, idProduct=a4a5, bcdDevice= 5.17[ 6432.885647] usb 1-1: New USB device strings: Mfr=3, Product=4, SerialNumber=0[ 6432.885653] usb 1-1: Product: Mass Storage Gadget[ 6432.885658] usb 1-1: Manufacturer: Linux 5.17.0-rc4+ with net2280[ 6432.886121] usb 1-1: Device is not authorized for usage[ 6432.891672] usb-storage 1-1:1.0: USB Mass Storage device detected[ 6432.891985] usb-storage 1-1:1.0: Quirks match for vid 0525 pid a4a5: 10000[ 6432.892090] scsi host0: usb-storage 1-1:1.0[ 6432.892567] usb 1-1: authorized to connect[ 6433.920354] scsi 0:0:0:0: Direct-Access     Linux    File-Stor Gadget 0517 PQ: 0 ANSI: 2[ 6433.922585] sd 0:0:0:0: Power-on or device reset occurred[ 6433.923533] sd 0:0:0:0: [sda] 204800 512-byte logical blocks: (105 MB/100 MiB)[ 6434.030869] sd 0:0:0:0: [sda] Write Protect is off[ 6434.030876] sd 0:0:0:0: [sda] Mode Sense: 0f 00 00 00[ 6434.136540] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA[ 6434.363462]  sda: sda1 sda2[ 6434.585367] cros-ec-sensorhub [...][ 6434.588541] sd 0:0:0:0: [sda] Attached SCSI diskI haven't looked at how this issue applies to other USB subsystems in detail,but from a quick glance: - USB_CLASS_PHYSICAL doesn't really show up in the Linux kernel outside of some   number-to-string translation table, so I don't think it matters to the kernel. - Same thing with USB_CLASS_STILL_IMAGE. - The usblp subsystem does have an explicit check for USB_CLASS_PRINTER - but   that check is intentionally bypassed for known devices that are marked in   the kernel as USBLP_QUIRK_BAD_CLASS, and that flag is set for the   \"Seiko Epson Receipt Printer M129C\" (vendor 0x04b8, device 0x0202), so you   can probably also bypass the blocking of the printer interface class that way.I think the best way forward would be to look into whether it is feasible torely exclusively on a trust-on-first-use approach. If that is infeasible, youmay have to talk to upstream about how userspace can reliably determine whichdriver(s) a given USB device might be bound to, since I'm not aware of anyinterface that would let you do that.VERSIONGoogle Chrome  98.0.4758.107 (Official Build) (64-bit) Revision  a2ef32d533baed737df9fc2ed8d505405ecf0c66-refs/branch-heads/4758@{#1167}Platform  14388.61.0 (Official Build) stable-channel eveFirmware Version  Google_Eve.9584.230.0Customization ID  GOOGLE-EVEARC  8165997CREDIT INFORMATIONReporter credit: Jann Horn of Google Project ZeroThis bug is subject to a 90-day disclosure deadline. If a fix for thisissue is made available to users before the end of the 90-day deadline,this bug report will become public 30 days after the fix was madeavailable. Otherwise, this bug report will become public at the deadline.The scheduled deadline is 2022-05-25.Found by: jannh@google.com

ChromeOS usbguard Bypass

A crafted NTFS image can cause a heap-based buffer overflow in ntfs_check_log_client_array in NTFS-3G through 2021.8.22.

Security vulnerabilities were identified in the open source NTFS-3G and  
NTFSPROGS software. These vulnerabilities were confirmed and resolved.  
To our knowledge, these vulnerabilities have not been exploited.

These vulnerabilities may allow an attacker using a maliciously crafted  
NTFS-formatted image file or external storage to potentially execute  
arbitrary privileged code, if the attacker has either local access and  
the ntfs-3g binary is setuid root, or if the attacker has physical  
access to an external port to a computer which is configured to run the  
ntfs-3g binary or one of the ntfsprogs tools when the external storage  
is plugged into the computer. These vulnerabilities result from  
incorrect validation of some of the NTFS metadata that could potentially  
cause buffer overflows, which could be exploited by an attacker. Common  
ways for attackers to gain physical access to a machine is through  
social engineering or an evil maid attack on an unattended computer.

We recommend installing and applying the update with the security fixes,  
and advise to follow security guidance and frameworks such as NIST for  
assessing and improving an organization’s abilities to prevent, detect,  
and respond to security threats and cyber attacks.

AFFECTED PRODUCTS: All previous versions of open source NTFS-3G and  
NTFSPROGS.

WORKAROUND: None

SOLUTION: Upgrade to 2022.5.17

PROJECT URL: https://github.com/tuxera/ntfs-3g

ADVISORY ID: NTFS3G-SA-2022-0001

ISSUE DATE: 2022-05-26

SEVERITY: Moderate

CVEs: CVE-2021-46790, CVE-2022-30784, CVE-2022-30786, CVE-2022-30788, CVE-2022-30789

CVSS SCORE: 5.0-6.7

CVE-2022-30789

Credential-stuffing attacks against online accounts are still popular, and they work thanks to continuing password reuse.

It has been a week of data breach news, with General Motors, Chicago Public Schools, and wedding-planner startup Zola all reeling from the exposure of customers' personal information. In the latter's case, customers were also riffed for stored funds and suffered fraudulent payment-card charges.

Credential stuffing was to blame in two of the incidents. In credential stuffing, attackers use automated scripts to try high volumes of stolen username and password combinations against online accounts in an effort to take them over. The stolen credentials are usually taken from data breaches of other sites — cybercriminals bank on password reuse and the use of common or easy-to-guess passwords, like “123456.”

Once in, cybercriminals can use the compromised accounts for various purposes: as a pivot point to penetrate deeper into a victim's machine and network; to drain accounts of sensitive information (or monetary value); and, if it's an email account, to impersonate the victim in attacks on others.

And such attacks are costly: The Ponemon Institute's Cost of Credential Stuffing report found that businesses lose an average of $6 million per year to credential stuffing in the form of application downtime, lost customers, and increased IT costs.

They're also wildly common. According to recent PerimeterX data, malicious login attempts out of total logins trended upward during 2021, reaching a staggering 93.8% of all login attempts in August, which was an 8% increase on the 2020 peak.

Verizon's 2022 Data Breach Investigations Report (DBIR), released this week, noted that the use of stolen credentials for kicking off data breaches is the top attack vector, accounting for around 42% of all of the breaches analyzed by the carrier.

**General Motors Drives into Trouble**  

GM has alerted customers that a successful credential-stuffing attack last month on its customers resulted in a raft of account compromises. The incident exposed personal information for customers and allowed hackers to fraudulently redeem rewards points for gift cards.

The customer data involved lends itself to a veritable cornucopia of follow-on attacks, including convincing social-engineering efforts, spoofing attacks, and, alarmingly, potential physical threats at the extreme end of the spectrum. The info included first and last name, personal email address, personal address, username and phone number for registered family members tied to an account, last known and saved favorite location information, your currently subscribed OnStar package (if applicable), family members' avatars and photos (if uploaded), profile picture, search and destination information, and reward-card activity.

"Some may suggest that breaches that don't involve payment-card numbers or SSNs are not as serious, but other information (family member names, phone numbers, and addresses) is just as damaging as it will be used in future social engineering attacks and will forever place these people in danger," noted John Gunn, CEO at Token, via email. "How easy is it to change family member names, phone numbers, and addresses? This type of attack is eminently preventable simply with better multi-factor authentication."

GM is reinstating any lost loyalty points and forced a password reset for customers.

**Chicago Public Schools Face Student Exposure**

Also this week, news emerged of a wide-ranging data breach that involved the personal information of nearly 500,000 students in Chicago Public Schools (CPS), and more than 56,000 employees.

The information was stolen as part of a ransomware attack on one of the district's third-party technology suppliers, Battelle for Kids, which maintains a server used to store the CPS student and staff information. The data was for the 2015-2019 school years.

CPS issued a data-breach notification flagging the exposed information, which included name, date of birth, gender, grade level, school, and district and state student ID numbers, as well as information about the courses students took.

The exposed staff records included name, school employee ID number, CPS email address, and scores on tasks used to evaluate teachers during the time period, the district said.

Perhaps most notably, the breach occurred months ago, on Dec. 1, but Battelle for Kids didn't notify CPS until April 26. It took that long for the vendor to verify the authenticity of the breach and commission an independent forensic analysis, and for law enforcement authorities to investigate, CPS noted.

The data was old and there's no evidence that the ransomware gang has made a move to exploit the data, but students and staff should still be on the lookout for phishing efforts, the district warned. It's offering everyone involved a year of free credit monitoring in response to the incident.

"Ransomware attacks have become a growing threat to education centers across the United States," says Erfan Shadabi, cybersecurity expert with data security specialists Comforte AG. "Schools are becoming more dependent on a computing infrastructure to support their daily functions, and they also hold a vast amount of sensitive information. School districts and universities need to understand that they are high-profile targets, and they need to assume that a cyberattack is imminent."

**Zola Customer Accounts Hijacked**

Wedding-planning site Zola has discovered that 3,000 customer accounts were compromised in an apparent brute-force or credential-stuffing attack on its customers.

The site allows couples to create wedding destination websites, build gift registries, and access a variety of financial tools. Over the weekend, customers began reporting on Reddit that their accounts had been hijacked, with the cyberattackers making off with stolen funds or racking up fraudulent credit-card charges. Zola didn't reveal how high the losses have mounted.

TechCrunch, which first reported the breach, said that it saw posts on a Dark Web Telegram channel from hackers, who swapped tips, posted screenshots of pwned accounts, and discussed ordering gift cards using the credit card on file with Zola.

"Credential stuffing attacks continue to fuel the web-attack lifecycle, potentially using these stolen user credentials on other e-commerce sites," said Uriel Maimon, vice president of emerging products at PerimeterX, via email. "We can expect that these credentials will soon be tested on other apps that we use daily to power our lives. The responsibility lies on app providers and website owners to make it difficult and expensive for cybercriminals to use the information in order to disrupt the cycle of attacks. This means stopping the theft, validation, and fraudulent use of account and identity information everywhere along a consumer's digital journey."

He added that that one way to do that is by tracking behavioral and forensics signals of users logging in, in order to differentiate between real users and attackers.

Big Cyber Hits on GM, Chicago Public Schools, & Zola Showcase the Password Problem

Piwigo 11.5.0 is affected by a SQL injection vulnerability via admin.php and the id parameter.

The following is the detail about this vulnerability I found in Piwigo 11.5.0:  
First, visit URL/admin.php and login, then click Album-Move. On this page, click ORDER on the right side.

  
Then we can see:

  
Select default, use Burpsuite during clicking APPLY.

  
Then in sqlmap:

python sqlmap.py -r post.txt -o --dbms=MySQL  

See admin\\cat\_move.php:

Here there seems to be no confirmation of the legitimacy of the parameter $\_POST\[id\]. And other parameters are legal so query is done.

Here is the manual injection test:

(Load successfully after sleeping 5 seconds)  

Thanks for reading!

CVE-2021-40317: [11.5.0]SQL Injection Vulnerability · Issue #1470 · Piwigo/Piwigo

ChromeLoader is working its way into Chrome browsers via ISO images claiming to offer cracked games. What are the dangers?
The post ChromeLoader targets Chrome Browser users with malicious ISO files appeared first on Malwarebytes Labs.

If you’re on the hunt for cracked software or games, be warned. Rogue ISO archive files are looking to infect your systems with ChromeLoader. If you think campaigns such as this only target Windows users, you’d sadly be very much mistaken. The attack sucks in several operating systems and even uses mobiles as bait to draw in additional victims.

**Of PowerShells and ISOs**

An optimal disc image (ISO) is a disk image containing everything written to an optical disc. If someone copied a DVD or CD-ROM, they may end up with an ISO. With the right software, these files can be mounted and read as if the device was reading from a physical disc.

If a malware author claims to be offering cracked or pirated versions of games or software, an ISO is frequently what’s on offer. They may be promoted on social media, video sites, game crack portals, or torrents. Sadly for would-be file downloaders, they’re frequently booby trapped with malware.

PowerShell is a way to automate tasks and comes complete with  a command line interface. It can be used by infection files to execute specific commands and get the infection ball rolling. This ChromeLoader attack combines both Powershell and ISOs to compromise systems.

**How does ChromeLoader infect a device?**

The flow is as follows:

1.  Bogus files are promoted on Twitter and other services. Some victims are simply grabbing the infection from rogue sites and/or torrents.
2.  Some social media posts promote supposedly cracked Android games via QR codes which direct would-be gamers to rogue websites.
3.  Double clicking the ISO file mounts it as a virtual CD-ROM. The executable in the ISO claims to be the content the victim was originally looking for.
4.  ChromeLoader makes use of a PowerShell command to load in a Chrome extension from a remote resource. PowerShell then removes the scheduled task and the victim is none the wiser that their browser has been compromised. At this point, search results cannot be trusted and bogus entries will be displayed to the user.
5.  As BleepingComputer notes, users of macOS are also at risk from this attack. Instead of ISO, attackers use DMG (Apple Disk Image) files, which is a more common format on that OS.

**Tips to avoid ChromeLoader**

1.  Searching for cracked games and software is a very risky business. Many sites promoting malware masquerading as “genuine” crack portals are hard to spot. If you’re downloading a torrent, you may well be rolling dice with regard to the digital health of your devices. Deep sales on games and products are fairly common. Unless it’s a brand new title, it may be worth waiting for a product-centric sale.
2.  In Chrome, Click the **More** icon, then **More Tools** -> **Extensions**. From there, you can see what’s installed, what is active or disabled, along with additional information about all extensions present. Google also has advice for resetting browser settings and additional clean-up methods.
3.  Keeping your security software up to date and running regular scans helps prevent this kind of attack. You should also always scan a downloaded file before making use of it.
4.  Keep in mind that rogue extensions don’t just come from bad websites or rogue downloads. The Chrome web store itself has been known to play host to bad files. Always check reviews, developer information, extension permissions and anything else of note before installing a new extension to your browser.

ChromeLoader targets Chrome Browser users with malicious ISO files

A malvertising threat is witnessing a new surge in activity since its emergence earlier this year.
Dubbed ChromeLoader, the malware is a "pervasive and persistent browser hijacker that modifies its victims' browser settings and redirects user traffic to advertisement websites," Aedan Russell of Red Canary said in a new report.
ChromeLoader is a rogue Chrome browser extension and is typically

A malvertising threat is witnessing a new surge in activity since its emergence earlier this year.

Dubbed **ChromeLoader**, the malware is a "pervasive and persistent browser hijacker that modifies its victims' browser settings and redirects user traffic to advertisement websites," Aedan Russell of Red Canary said in a new report.

ChromeLoader is a rogue Chrome browser extension and is typically distributed in the form of ISO files via pay-per-install sites and baited social media posts that advertise QR codes to cracked video games and pirated movies.

While it primarily functions by hijacking user search queries to Google, Yahoo, and Bing and redirecting traffic to an advertising site, it's also notable for its use of PowerShell to inject itself into the browser and get the extension added.

The malware, also known as Choziosi Loader, was first documented by G DATA earlier this February.

"For now the only purpose is getting revenue via unsolicited advertisements and search engine hijacking," G DATA's Karsten Hahn said. "But loaders often do not stick to one payload in the long run and malware authors improve their projects over time."

Another trick up ChromeLoader's sleeve is its ability to redirect victims from the Chrome extensions page ("chrome://extensions") should they attempt to remove the add-on.

Furthermore, researchers have detected a macOS version of the malware that works against both Chrome and Safari browsers, effectively turning ChromeLoader into a cross-platform threat.

"If applied to a higher-impact threat — such as a credential harvester or spyware — this PowerShell behavior could help malware gain an initial foothold and go undetected before performing more overtly malicious activity, like exfiltrating data from a user's browser sessions," Russell noted.

Found this article interesting? Follow THN on Facebook, Twitter __ and LinkedIn to read more exclusive content we post.

Tag

#mac