Threat actors continue to evolve the malicious botnet, which has also added a list of new vulnerabilities it can use to target devices.

A recently discovered botnet that attacks organizations through Internet of things (IoT) vulnerabilities has added brute-forcing and distributed denial-of-service (DDoS) attack vectors, as well as the ability to exploit new flaws to its growing arsenal, Microsoft security analysts have found. 

The updates to Zerobot, a malware first observed earlier this month by Fortinet researchers, pave the way for more advanced attacks as the threat continues to evolve, according to the Microsoft Security Threat Intelligence Center (MSTIC).

MSTIC revealed in a blog post on Dec. 21 that the threat actors have updated Zerobot to version 1.1, which can now target resources through DDoS and make them inaccessible, widening the possibilities for attack and further compromise.

"Successful DDoS attacks may be used by threat actors to extort ransom payments, distract from other malicious activities, or disrupt operations," the researchers wrote in the post. "In almost every attack, the destination port is customizable, and threat actors who purchase the malware can modify the attack according to their target."

**Brute-Forcing and Other Tactics**

Fortinet researchers already had tracked two previous versions of Zerobot — one that was quite basic and another that was more advanced. The botnet's principal mode of attack originally was to target various IoT devices — including products from D-Link, Huawei, RealTek, TOTOLink, Zyxel, and more — through flaws found in those devices, and then spread to other assets connected on the network that way to propagate the malware and grow the botnet.

Microsoft researchers now have observed the botnet getting more aggressive in its attacks on devices, using a new brute-force vector to compromise weakly secured IoT devices rather than just trying to leverage a known vulnerability, the researchers revealed.

"IoT devices are often internet-exposed, leaving unpatched and improperly secured devices vulnerable to exploitation by threat actors," they wrote in the post. "Zerobot is capable of propagating through brute-force attacks on vulnerable devices with insecure configurations that use default or weak credentials."

The malware attempts to to gain device access by using a combination of eight common usernames and 130 passwords for IoT devices over SSH and telnet on ports 23 and 2323 to spread to devices, the researchers wrote. In their observations alone, the MSTIC team identified numerous SSH and telnet connection attempts on default ports 22 and 23, as well as attempts to open ports and connect to them by port-knocking on ports 80, 8080, 8888, and 2323.

**An Expanded Security Vulnerability Exploit List**

Zerobot hasn't abandoned its original way to access devices, however, and has even expanded this practice. Prior to its new version, Zerobot already could exploit more than 20 flaws in assorted devices, including routers, webcams, network-attached storage, firewalls, and other products from a host of well-known manufacturers.

The botnet has now added seven new exploits for flaws to its quiver, found in Apache, Roxy-WI, Grandstream, and other platforms, the researchers found.

MSTIC also found new evidence that Zerobot propagates by compromising devices with known vulnerabilities that are not included in the malware binary, such as CVE-2022-30023, a command injection vulnerability in Tenda GPON AC1200 routers, they added.

**Zerobot's Post-Compromise Behavior**

Researchers also observed more about Zerobot's behavior once it gains device access. For one, it immediately injects a malicious payload — which may be a generic script called "zero.sh" that downloads and attempts to execute the bot, or a script that downloads the Zerobot binary of a specific architecture, they said.

"The bash script that attempts to download different Zerobot binaries tries to identify the architecture by brute-force, attempting to download and execute binaries of various architectures until it succeeds," the researchers wrote.

Once Zerobot achieves persistence, it scans for other devices exposed to the Internet that it can infect, by randomly generating a number between 0 and 255 and scanning all IPs starting with this value.

"Using a function called _new\_botnet\_selfRepo\_isHoneypot_, the malware tries to identify honeypot IP addresses, which are used by network decoys to attract cyberattacks and collect information on threats and attempts to access resources," the Microsoft researchers wrote. "This function includes 61 IP subnets, preventing scanning of these IPs."

Zerobot 1.1 uses scripts targeting various architectures, including ARM64, MIPS, and x86\_64. The researchers also have observed samples of the botnet on Windows and Linux devices, exhibiting different persistence methods based on the OS.

**Protecting the Enterprise**

Fortinet researchers already had stressed the importance of organizations immediately updating to the latest versions of any devices affected by Zerobot. Given that businesses are losing up to $250 million a year on unwanted botnet attacks, according to a report published last year from Netacea, the danger is real.

To help identify if an organization is vulnerable, Microsoft researchers included an updated list of CVEs that Zerobot can exploit in their post. The MSTIC team also recommended that organizations use security solutions with cross-domain visibility and detection capabilities to detect Zerobot malware variants and malicious behavior related to the threat.

Enterprises should also adopt a comprehensive IoT security solution that allows for visibility and monitoring of all IoT and operational technology (OT) devices, threat detection and response, and integration with SIEM/SOAR and extended detection and response (XDR) platforms, according to Microsoft.

As part of this strategy, they should ensure secure configurations for devices by changing default passwords to strong ones and blocking SSH from external access, as well as use least-privileges access including VPN service for remote access, the researchers said.

Another way to avoid compromise by Zerobot is to harden endpoints with a comprehensive security solution that manages the apps that employees can use and provides application control for unmanaged solutions, they said. This solution also should perform timely cleanup of unused and stale executables sitting on an organization's devices.

Zerobot Adds Brute Force, DDoS to Its IoT Attack Arsenal

Debian Linux Security Advisory 5305-1 - An integer overflow flaw was discovered in the CRL signature parser in libksba, an X.509 and CMS support library, which could result in denial of service or the execution of arbitrary code.

    -----BEGIN PGP SIGNED MESSAGE-----Hash: SHA512- -------------------------------------------------------------------------Debian Security Advisory DSA-5305-1                   security@debian.orghttps://www.debian.org/security/                     Salvatore BonaccorsoDecember 21, 2022                     https://www.debian.org/security/faq- -------------------------------------------------------------------------Package        : libksbaCVE ID         : CVE-2022-47629An integer overflow flaw was discovered in the CRL signature parser inlibksba, an X.509 and CMS support library, which could result in denialof service or the execution of arbitrary code.For the stable distribution (bullseye), this problem has been fixed inversion 1.5.0-3+deb11u2.We recommend that you upgrade your libksba packages.For the detailed security status of libksba please refer to its securitytracker page at:https://security-tracker.debian.org/tracker/libksbaFurther information about Debian Security Advisories, how to applythese updates to your system and frequently asked questions can befound at: https://www.debian.org/security/Mailing list: debian-security-announce@lists.debian.org-----BEGIN PGP SIGNATURE-----iQKTBAEBCgB9FiEERkRAmAjBceBVMd3uBUy48xNDz0QFAmOjfbNfFIAAAAAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDQ2NDQ0MDk4MDhDMTcxRTA1NTMxRERFRTA1NENCOEYzMTM0M0NGNDQACgkQBUy48xNDz0TZeA/+NmgALkjZhrkd2BixzJp2eAe5ocLW5B0g9lB93NIyUORM2A3CgX0MsF+UbYrehbBdQosJOMko5E4St7ETC6H4eVknHj+snuP0j0MY/KQspoTTZfE/28y28734oXiBTuaOmEItHWlpuvreTPOzeNaWck/osiSLaBIWCKooGDnpUrTYAV+AQ7l8pyBU7iaZfOV1hR+ndTYdp/JK1Rl0FgPazCe4UQP1EAhMOE8XqVNKZ/MSh2U5JaSPUzTt+sgJWunB9ysBHbSuKFJ1cli7nqFf8urDmKYYU4gZtKFl4AJV0Oe39UTxjOwQkVhz8buLUVwLtXfSxu8jBTQXGLuwQJrr9W1S5mny3wxMgOOqNozdyoFuYNoIFY4+84dTG4H+L0sWbFCWVHY8gCKwPSa6ZK0eP4UQ9dxgmUfK5K6Ldo8gi0iX1v1Ub3OYz7JzeIfkUKTx82yLmFcFisQNgeXe6lMN+Tzu7WTs3w8Y3OA7a65nKb79PDJFZ/Hiw+p06L+C7SkhfcItMbKwqU3IdfsVrGxTK4VbdYZEoMv0+43zBypLDUF+eVC4E3MJSB0k+qAiyLzr6qbaVZp4m04/B2puqnBACIIc3Vm9BUKQCWYx4R6C8rqfxtOfD2Xmz4xGcNZfr342Kig4QNbkc1zatx72maEX1KGt2x9BmqtSvebuw/EwkBQ=9jlL-----END PGP SIGNATURE-----

Debian Security Advisory 5305-1

Isode M-Vault 16.0v0 through 17.x before 17.0v24 can crash upon an LDAP v1 bind request.

Summary

Denial of Service due to application crash

Release Date

21st December 2022

Product

M-Vault

Version(s)

16.0v0 to 17.0v23

CVE ID

CVE-2022-47581

  
**Summary of vulnerability**

This advisory discloses a critical vulnerability introduced in version R16.0v0 of M-Vault. The following versions are affected by this vulnerability:

*   M-Vault R16.0v0 to R17.0v23.

This is a bug where an LDAPv1 bind request leads to a server crash, thereby leading to denial of service.

**Severity**

Isode rates the severity level of this vulnerability as **high**, according to the CVSS system (details can be found at www.first.org).

**Mitigation**

This vulnerability has been fixed in M-Vault R17.0v24 and affected services are advised to immediately upgrade to this version. Current later versions (such as the subsequent major release R18.0) are **not** affected by this vulnerability.

**Acknowledgements**

This vulnerability was discovered, with thanks from Isode, by Jerome Nokin of the NATO Cyber Security Centre (NCSC).

CVE-2022-47581: Advisory Report for M-Link Incorrect Access Control Vulnerability

The open source container tool is quite popular among developers — and threat actors. Here are a few ways DevOps teams can take control.

_Editor's note: For more about the kinds of vulnerabilities Kubernetes presents and how to address them, read our_ _companion article_ _in The Edge._

Since its initial release in 2014, Kubernetes (aka K8s) has become the standard open source container tool for managing software applications. Kubernetes is cost-effective, offers autoscaling, and can run on any infrastructure. Its benefits are why 85% of IT leaders consider Kubernetes "extremely important" to cloud-native strategies. On top of this, 61% of people use Kubernetes to manage their computer application deployment.

Funso Richard, information security officer at Ensemble, tells Dark Reading that "forward-thinking organizations understand the importance of leveraging containerized microservices to develop scalable and reliable applications as an essential digital transformation strategy" — and Kubernetes has become the leading tool used to achieve this strategy, he adds.

However, Kubernetes also comes with security challenges: It's susceptible to data theft, computational power theft, and denial-of-service (DoS) attacks. Kubernetes' public components (such as kubelets and API authentication) are widely exploited. And threat actors target infrastructure misconfiguration, unpatched software programs, and poor login credentials to gain unauthorized entry to Kubernetes. The vulnerabilities are also widespread. According to Red Hat's "2022 State of Kubernetes" security report, 93% of Kubernetes users experienced at least one security incident in the past 12 months.

As DevOps teams continue to grapple with rising Kubernetes security mishaps, here are a few ways to stay ahead of attackers and keep cloud-native environments secure.

**Securing Kubernetes With Tools**

Kubernetes' security vulnerability affects its efficiency. For instance, concerns over Kubernetes security caused developers to delay application rollouts in 2022, according to Red Hat. Although Kubernetes provides several benefits in application development and container orchestration, says Richard, inadequate security controls expose the open source tool to serious security concerns like misconfiguration, privilege abuse, data exfiltration, credential compromise, exploited public-facing components, and API vulnerabilities. To address these, several Kubernetes security tools have sprung up, including Kubescape, Kube-bench, Kubeaudit, Kube-hunter, and Kyverno.

Kubescape is an open source security platform from ARMO to protect Kubernetes clusters with capabilities such as risk analysis, security compliance, misconfiguration scanning, CI/CD security, RBAC visualizer, and vulnerabilities scanning. One thing that sets Kubescape apart is its library of robust capabilities that aligns with MITRE ATT&CK and NSA-CISA frameworks, says Richard.

"As I track Kubernetes security offerings — both commercial and non-commercial offerings — I haven't come across another offering with the same exact components as Kubescape," agrees Fernando Montenegro, senior principal analyst of cybersecurity infrastructure at Omdia.

Kubescape scans clusters, YAML files, and Helm charts for vulnerabilities either directly or via CI/CD integrations. The idea of scanning infrastructure-as-code (IaC) templates is well-popularized across the industry, says Montenegro. Most IaC scanning is done for cloud resources like Amazon's CloudFormation, HashiCorp's Terraform, and others, with Kubernetes scanning being a more specialized use case, he adds.

There are other offerings in the market — like Red Hat's StackRox (acquired in 2021), Tenable's Terrascan, and Palo Alto Networks' Checkov — offering similar capabilities as Kubernetes.

**Implementing Best Security Practices in Kubernetes**

Richard notes that adherence to cybersecurity fundamentals remains the bedrock of any security effort. While Kubescape is undoubtedly a powerful Kubernetes security tool, he believes developers can effectively secure their Kubernetes clusters by following the basics: implementing proper cluster configuration, pod security standards and policy enforcement, network segmentation, vulnerability scanning, periodic policy reviews, and security audits. "Containers should run with the least privileges and only necessary services, while role-based access controls should be in place to manage user access," Richard says.

While Montenegro says there are several Kubernetes best practices for DevOps and DevSecOps teams to follow, he notes that the following practices must be top on their priority list:

*   **Think about security early on:** Collaborate with your developers/architects to work through a proper threat modeling.
*   **Work with embedding security throughout the application lifecycle:** Security is an end-to-end process, from providing on-the-spot security advice and functionality for a developer working through the code in their development environment, through making sure security tests are part and parcel of the integration stages, then adding the necessary runtime protections to monitor workloads in production.
*   **Safely store Kubernetes secrets:** Implement features like proper namespace separation, use of role-based access control (RBAC).

As Kubernetes grows in adoption, IT teams can avoid security pitfalls by using tools like Kubescape and StackRox, as well as following the best security practices for securing their critical Kubernetes assets.

How to Run Kubernetes More Securely

IBM Spectrum Control 5.4 uses weaker than expected cryptographic algorithms that could allow an attacker to decrypt highly sensitive information. IBM X-Force ID: 233982.

**Security Bulletin**

  

**Summary**

Vulnerabilities in IBM WebSphere Application Server Liberty and FasterXML jackson-databind such as HTTP header injection, identity spoofing, denial of service may affect IBM Spectrum Control.

**Vulnerability Details**

**CVEID:**   CVE-2022-34165  
**DESCRIPTION:**   IBM WebSphere Application Server 7.0, 8.0, 8.5, and 9.0 and IBM WebSphere Application Server Liberty 17.0.0.3 through 22.0.0.9 are vulnerable to HTTP header injection, caused by improper validation. This could allow an attacker to conduct various attacks against the vulnerable system, including cache poisoning and cross-site scripting. IBM X-Force ID: 229429.  
CVSS Base score: 5.4  
CVSS Temporal Score: See: https://exchange.xforce.ibmcloud.com/vulnerabilities/229429 for the current score.  
CVSS Vector: (CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N)

**CVEID:**   CVE-2022-42004  
**DESCRIPTION:**   FasterXML jackson-databind is vulnerable to a denial of service, caused by a lack of a check in in the BeanDeserializer.\_deserializeFromArray function. By sending a specially-crafted request using deeply nested arrays, a local attacker could exploit this vulnerability to exhaust all available resources.  
CVSS Base score: 6.2  
CVSS Temporal Score: See: https://exchange.xforce.ibmcloud.com/vulnerabilities/237660 for the current score.  
CVSS Vector: (CVSS:3.0/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H)

**CVEID:**   CVE-2022-22476  
**DESCRIPTION:**   IBM WebSphere Application Server Liberty 17.0.0.3 through 22.0.0.7 and Open Liberty are vulnerable to identity spoofing by an authenticated user using a specially crafted request. IBM X-Force ID: 225604.  
CVSS Base score: 5  
CVSS Temporal Score: See: https://exchange.xforce.ibmcloud.com/vulnerabilities/225604 for the current score.  
CVSS Vector: (CVSS:3.0/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:L)

**CVEID:**   CVE-2022-38391  
**DESCRIPTION:**   IBM Spectrum Control uses weaker than expected cryptographic algorithms that could allow an attacker to decrypt highly sensitive information.  
CVSS Base score: 5.1  
CVSS Temporal Score: See: https://exchange.xforce.ibmcloud.com/vulnerabilities/233982 for the current score.  
CVSS Vector: (CVSS:3.0/AV:L/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N)

**CVEID:**   CVE-2022-42003  
**DESCRIPTION:**   FasterXML jackson-databind is vulnerable to a denial of service, caused by a lack of a check in the primitive value deserializers when the UNWRAP\_SINGLE\_VALUE\_ARRAYS feature is enabled. By sending a specially-crafted request using deep wrapper array nesting, a local attacker could exploit this vulnerability to exhaust all available resources.  
CVSS Base score: 6.2  
CVSS Temporal Score: See: https://exchange.xforce.ibmcloud.com/vulnerabilities/237662 for the current score.  
CVSS Vector: (CVSS:3.0/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H)

**Affected Products and Versions**

**Affected Product(s)**

**Version(s)**

IBM Spectrum Control

5.4

**Remediation/Fixes**

**Workarounds and Mitigations**

None

**References**

Off

**Acknowledgement**

The vulnerability was reported to IBM by Mikhail Zakharov - zmey20000@yahoo.com - https://www.linkedin.com/in/mikhailzakharov

**Change History**

15 Dec 2022: Initial Publication

\*The CVSS Environment Score is customer environment specific and will ultimately impact the Overall CVSS Score. Customers can evaluate the impact of this vulnerability in their environments by accessing the links in the Reference section of this Security Bulletin.

**Disclaimer**

According to the Forum of Incident Response and Security Teams (FIRST), the Common Vulnerability Scoring System (CVSS) is an "industry open standard designed to convey vulnerability severity and help to determine urgency and priority of response." IBM PROVIDES THE CVSS SCORES ""AS IS"" WITHOUT WARRANTY OF ANY KIND, INCLUDING THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. CUSTOMERS ARE RESPONSIBLE FOR ASSESSING THE IMPACT OF ANY ACTUAL OR POTENTIAL SECURITY VULNERABILITY. In addition to other efforts to address potential vulnerabilities, IBM periodically updates the record of components contained in our product offerings. As part of that effort, if IBM identifies previously unidentified packages in a product/service inventory, we address relevant vulnerabilities regardless of CVE date. Inclusion of an older CVEID does not demonstrate that the referenced product has been used by IBM since that date, nor that IBM was aware of a vulnerability as of that date. We are making clients aware of relevant vulnerabilities as we become aware of them. "Affected Products and Versions" referenced in IBM Security Bulletins are intended to be only products and versions that are supported by IBM and have not passed their end-of-support or warranty date. Thus, failure to reference unsupported or extended-support products and versions in this Security Bulletin does not constitute a determination by IBM that they are unaffected by the vulnerability. Reference to one or more unsupported versions in this Security Bulletin shall not create an obligation for IBM to provide fixes for any unsupported or extended-support products or versions.

**Document Location**

Worldwide

\[{"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\\/TPS"},"Product":{"code":"SSWFB4","label":"IBM Spectrum Control Standard Edition"},"Component":"N\\/A","Platform":\[{"code":"PF002","label":"AIX"},{"code":"PF016","label":"Linux"},{"code":"PF033","label":"Windows"}\],"Version":"5.4","Edition":"ALL","Line of Business":{"code":"LOB26","label":"Storage"}}\]

CVE-2022-38391: Security Bulletin: IBM Spectrum Control is vulnerable to multiple weaknesses related IBM WebSphere Application Server Liberty and FasterXML jackson-databind

IBM Security Guardium 11.4 could allow a privileged user to obtain sensitive information inside of an HTTP response. IBM X-Force ID: 235405.

  

**Summary**

IBM Security Guardium has addressed these vulnerabilities \[CVE-2022-39166, CVE-2022-34917, CVE-2022-42889\]

**Vulnerability Details**

**CVEID:**   CVE-2022-39166  
**DESCRIPTION:**   IBM Security Guardium could allow a privileged user to obtain sensitive information inside of an HTTP response.  
CVSS Base score: 4.4  
CVSS Temporal Score: See: https://exchange.xforce.ibmcloud.com/vulnerabilities/235405 for the current score.  
CVSS Vector: (CVSS:3.0/AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:N/A:N)

**CVEID:**   CVE-2022-34917  
**DESCRIPTION:**   Apache Kafka is vulnerable to a denial of service, caused by improper input validation. By sending a specially-crafted request, a remote attacker could exploit this vulnerability to allocate large amounts of memory on brokers, and results in a denial of service condition.  
CVSS Base score: 7.5  
CVSS Temporal Score: See: https://exchange.xforce.ibmcloud.com/vulnerabilities/236498 for the current score.  
CVSS Vector: (CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H)

**CVEID:**   CVE-2022-42889  
**DESCRIPTION:**   Apache Commons Text could allow a remote attacker to execute arbitrary code on the system, caused by an insecure interpolation defaults flaw. By sending a specially-crafted input, an attacker could exploit this vulnerability to execute arbitrary code on the system.  
CVSS Base score: 9.8  
CVSS Temporal Score: See: https://exchange.xforce.ibmcloud.com/vulnerabilities/238560 for the current score.  
CVSS Vector: (CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H)

**Affected Products and Versions**

**Affected Product(s)**

**Version(s)**

IBM Security Guardium

11.4

  

**Remediation/Fixes**

IBM strongly encourages customers to update their systems promptly.

**Workarounds and Mitigations**

None

**References**

Off

**Acknowledgement**

Desjardins

**Change History**

30 Nov 2022: Initial Publication

\*The CVSS Environment Score is customer environment specific and will ultimately impact the Overall CVSS Score. Customers can evaluate the impact of this vulnerability in their environments by accessing the links in the Reference section of this Security Bulletin.

**Disclaimer**

According to the Forum of Incident Response and Security Teams (FIRST), the Common Vulnerability Scoring System (CVSS) is an "industry open standard designed to convey vulnerability severity and help to determine urgency and priority of response." IBM PROVIDES THE CVSS SCORES ""AS IS"" WITHOUT WARRANTY OF ANY KIND, INCLUDING THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. CUSTOMERS ARE RESPONSIBLE FOR ASSESSING THE IMPACT OF ANY ACTUAL OR POTENTIAL SECURITY VULNERABILITY. In addition to other efforts to address potential vulnerabilities, IBM periodically updates the record of components contained in our product offerings. As part of that effort, if IBM identifies previously unidentified packages in a product/service inventory, we address relevant vulnerabilities regardless of CVE date. Inclusion of an older CVEID does not demonstrate that the referenced product has been used by IBM since that date, nor that IBM was aware of a vulnerability as of that date. We are making clients aware of relevant vulnerabilities as we become aware of them. "Affected Products and Versions" referenced in IBM Security Bulletins are intended to be only products and versions that are supported by IBM and have not passed their end-of-support or warranty date. Thus, failure to reference unsupported or extended-support products and versions in this Security Bulletin does not constitute a determination by IBM that they are unaffected by the vulnerability. Reference to one or more unsupported versions in this Security Bulletin shall not create an obligation for IBM to provide fixes for any unsupported or extended-support products or versions.

**Document Location**

Worldwide

\[{"Business Unit":{"code":"BU059","label":"IBM Software w\\/o TPS"},"Product":{"code":"SSMPHH","label":"IBM Security Guardium"},"Component":"","Platform":\[{"code":"PF016","label":"Linux"}\],"Version":"11.4","Edition":"","Line of Business":{"code":"LOB24","label":"Security Software"}}\]

CVE-2022-39166: IBM Security Guardium is affected by the following vulnerabilities [CVE-2022-39166, CVE-2022-34917, CVE-2022-42889]

IBM AIX 7.1, 7.2, 7.3, and VIOS 3.1could allow a local user with elevated privileges to exploit a vulnerability in the lpd daemon to cause a denial of service. IBM X-Force ID: 238641.

  

**Summary**

A vulnerability in the AIX lpd printer daemon could allow a local user with elevated privileges to cause a denial of service (CVE-2022-43382). The lpd daemon is the remote print server on AIX.

**Vulnerability Details**

**CVEID:**   CVE-2022-43382  
**DESCRIPTION:**   IBM AIX could allow a local user with elevated privileges to exploit a vulnerability in the lpd daemon to cause a denial of service.  
CVSS Base score: 6.2  
CVSS Temporal Score: See: https://exchange.xforce.ibmcloud.com/vulnerabilities/238641 for the current score.  
CVSS Vector: (CVSS:3.0/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H)

**Affected Products and Versions**

Affected Product(s)

Version(s)

AIX

7.1

AIX

7.2

AIX

7.3

VIOS

3.1

The following fileset levels are vulnerable:

Fileset

Lower Level

Upper Level

bos.rte.printers

7.1.5.0

7.1.5.33

printers.rte

7.1.5.0

7.1.5.31

bos.rte.printers

7.2.5.0

7.2.5.1

bos.rte.printers

7.2.5.100

7.2.5.100

printers.rte

7.2.4.0

7.2.4.0

printers.rte

7.2.5.200

7.2.5.200

bos.rte.printers

7.3.0.0

7.3.0.0

printers.rte

7.3.0.0

7.3.0.0

printers.rte

7.3.1.0

7.3.1.0

To find out whether the affected filesets are installed on your systems, refer to the lslpp command found in the AIX user's guide.

Example: lslpp -L | grep -i bos.rte.printers

  

**Remediation/Fixes**

**A. APARS**

IBM has assigned the following APARs to this problem:

AIX Level

APAR

SP

7.1.5

IJ44552

SP11

7.2.5

IJ44559

SP06

7.3.0

IJ42800

SP03

7.3.1

IJ44564

SP02

VIOS Level

APAR

SP

3.1.2

IJ44615

3.1.2.50

3.1.3

IJ42162

3.1.3.30

3.1.4

IJ44559

3.1.4.20

Subscribe to the APARs here:

https://www.ibm.com/support/pages/apar/IJ42162

https://www.ibm.com/support/pages/apar/IJ42800

https://www.ibm.com/support/pages/apar/IJ44552

https://www.ibm.com/support/pages/apar/IJ44559

https://www.ibm.com/support/pages/apar/IJ44564

https://www.ibm.com/support/pages/apar/IJ44615

By subscribing, you will receive periodic email alerting you to the status of the APAR, and a link to download the fix once it becomes available.

**B. FIXES**

IBM strongly recommends addressing the vulnerability now.

The fixes can be downloaded via ftp or http from:

ftp://aix.software.ibm.com/aix/efixes/security/lpd\_fix3.tar

http://aix.software.ibm.com/aix/efixes/security/lpd\_fix3.tar

https://aix.software.ibm.com/aix/efixes/security/lpd\_fix3.tar

The links above are to a tar file containing this signed advisory, fix packages, and OpenSSL signatures for each package. The fixes below include prerequisite checking. This will enforce the correct mapping between the fixes and AIX Technology Levels.

AIX Level

Interim Fix

7.1.5.8

IJ44552mAa.221208.epkg.Z

7.1.5.9

IJ44552mAa.221208.epkg.Z

7.1.5.10

IJ44552mAa.221208.epkg.Z

7.2.5.3

IJ44559m4a.221214.epkg.Z

7.2.5.4

IJ44559m4a.221214.epkg.Z

7.2.5.5

IJ44559m5a.221208.epkg.Z

7.3.0.1

IJ42800m2a.221208.epkg.Z

7.3.0.2

IJ42800m2a.221208.epkg.Z

7.3.1.1

IJ44564m1a.221208.epkg.Z

Please note that the above table refers to AIX TL/SP level as opposed to fileset level, i.e., 7.2.5.4 is AIX 7200-05-04.

Please reference the Affected Products and Version section above for help with checking installed fileset levels.

VIOS Level

Interim Fix

3.1.2.21

IJ44615m2a.221213.epkg.Z

3.1.2.30

IJ44615m2a.221213.epkg.Z

3.1.2.40

IJ44615m2a.221213.epkg.Z

3.1.3.10

IJ42162m4a.221208.epkg.Z

3.1.3.14

IJ42162m4a.221208.epkg.Z

3.1.3.21

IJ42162m4a.221208.epkg.Z

3.1.4.10

IJ44559m5a.221208.epkg.Z

The fixes are cumulative and address the previously issued AIX/VIOS lpd security bulletin with respect to SP and TL:

https://aix.software.ibm.com/aix/efixes/security/lpd\_advisory2.asc

https://www.ibm.com/support/pages/node/6594859

To extract the fixes from the tar file:

tar xvf lpd\_fix3.tar

cd lpd\_fix3

Verify you have retrieved the fixes intact:

The checksums below were generated using the "openssl dgst -sha256 \[file\]" command as the following:

openssl dgst -sha256

filename

9dbee1f9ad2158e491a36186236a776086ae4a3e6ec65052c84688c2412bec3c

IJ42162m4a.221208.epkg.Z

6c3b3f0c7521e46d6071fa62517173de68768487b34260b8b3641391ee194886

IJ42800m2a.221208.epkg.Z

29594f99310e866eaca906730d347b1a9e976212d708a3d95f6c70b517d96b23

IJ44552mAa.221208.epkg.Z

328df5737201ed540a0b011da0cca28a51b182286a12280a21537cff4b5638ce

IJ44559m4a.221214.epkg.Z

b7ab294f33bddb6679157b9e55d0fd3e822c8d7259e119ccc00b027a7f934642

IJ44559m5a.221208.epkg.Z

371bec45e77ec860b79ee3759feedf5b00ea22098c6a79ea9f51d3e0852b6888

IJ44564m1a.221208.epkg.Z

bb941b81852b4a46944ac793173998a714d6facd8af36e0ca63f300bd3c091ef

IJ44615m2a.221213.epkg.Z

These sums should match exactly. The OpenSSL signatures in the tar file and on this advisory can also be used to verify the integrity of the fixes. If the sums or signatures cannot be confirmed, contact IBM AIX Support at https://ibm.com/support/ and describe the discrepancy.

openssl dgst -sha256 -verify \[pubkey\_file\] -signature \[advisory\_file\].sig \[advisory\_file\]

openssl dgst -sha256 -verify \[pubkey\_file\] -signature \[ifix\_file\].sig \[ifix\_file\]

Published advisory OpenSSL signature file location:

http://aix.software.ibm.com/aix/efixes/security/lpd\_advisory3.asc.sig

https://aix.software.ibm.com/aix/efixes/security/lpd\_advisory3.asc.sig

ftp://aix.software.ibm.com/aix/efixes/security/lpd\_advisory3.asc.sig

**C. FIX AND INTERIM FIX INSTALLATION**

Interim fixes have had limited functional and regression testing but not the full regression testing that takes place for Service Packs; however, IBM does fully support them.

Interim fix management documentation can be found at:

http://www14.software.ibm.com/webapp/set2/sas/f/aix.efixmgmt/home.html

To preview an interim fix installation:

emgr -e ipkg\_name -p # where ipkg\_name is the name of the

\# interim fix package being previewed.

To install an interim fix package:

emgr -e ipkg\_name -X # where ipkg\_name is the name of the

\# interim fix package being installed.

**Workarounds and Mitigations**

None

**References**

Off

**Change History**

14 Dec 2022: Initial Publication

\*The CVSS Environment Score is customer environment specific and will ultimately impact the Overall CVSS Score. Customers can evaluate the impact of this vulnerability in their environments by accessing the links in the Reference section of this Security Bulletin.

**Disclaimer**

According to the Forum of Incident Response and Security Teams (FIRST), the Common Vulnerability Scoring System (CVSS) is an "industry open standard designed to convey vulnerability severity and help to determine urgency and priority of response." IBM PROVIDES THE CVSS SCORES ""AS IS"" WITHOUT WARRANTY OF ANY KIND, INCLUDING THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. CUSTOMERS ARE RESPONSIBLE FOR ASSESSING THE IMPACT OF ANY ACTUAL OR POTENTIAL SECURITY VULNERABILITY. In addition to other efforts to address potential vulnerabilities, IBM periodically updates the record of components contained in our product offerings. As part of that effort, if IBM identifies previously unidentified packages in a product/service inventory, we address relevant vulnerabilities regardless of CVE date. Inclusion of an older CVEID does not demonstrate that the referenced product has been used by IBM since that date, nor that IBM was aware of a vulnerability as of that date. We are making clients aware of relevant vulnerabilities as we become aware of them. "Affected Products and Versions" referenced in IBM Security Bulletins are intended to be only products and versions that are supported by IBM and have not passed their end-of-support or warranty date. Thus, failure to reference unsupported or extended-support products and versions in this Security Bulletin does not constitute a determination by IBM that they are unaffected by the vulnerability. Reference to one or more unsupported versions in this Security Bulletin shall not create an obligation for IBM to provide fixes for any unsupported or extended-support products or versions.

**Document Location**

Worldwide

\[{"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\\/TPS"},"Product":{"code":"SWG10","label":"AIX"},"Component":"","Platform":\[{"code":"PF002","label":"AIX"}\],"Version":"7.1,7.2,7.3","Edition":"","Line of Business":{"code":"LOB08","label":"Cognitive Systems"}},{"Business Unit":{"code":"BU058","label":"IBM Infrastructure w\\/TPS"},"Product":{"code":"SSPHKW","label":"PowerVM Virtual I\\/O Server"},"Component":"","Platform":\[{"code":"PF002","label":"AIX"}\],"Version":"3.1","Edition":"","Line of Business":{"code":"LOB57","label":"Power"}}\]

CVE-2022-43382: Security Bulletin: AIX is vulnerable to a denial of service due to lpd (CVE-2022-43382)

An issue in the firmware update process of TP-Link TL-WA901ND V1 up to v3.11.2 and TL-WA901N V2 up to v3.12.16 allows attackers to execute arbitrary code or cause a Denial of Service (DoS) via uploading a crafted firmware image.

\# A Firmware Modification Vulnerability During Firmware Update in TP-Link TL-WA901N / TL-WA901ND Wireless Access Point ## Affected Products: We have tested on the following devices: - TP-LINK TL-WA901N / TL-WA901ND V1 (firmware version: 3.11.2 and earlier) - TP-LINK TL-WA901N / TL-WA901ND V2 (firmware version: 3.12.16 and earlier) Also, we suspect it may also work on other models of TL-WA901N / TL-WA901ND series devices. ## Overview: An exploitable firmware modification vulnerability was discovered on the TP-Link TL-WA901N / TL-WA901ND wireless access points. A specially crafted firmware update image can allow an attacker to bypass the firmware verification in the firmware update process and install a malicious firmware image, thus resulting in either denial-of-service (DoS) or malware or backdoor planting. This vulnerability could be triggered during a user performing a firmware update with a self-uploaded firmware image. During the firmware delivery, the attacker can replace the user-uploaded firmware image with the malicious firmware image.  ## Details: When performing a firmware update, users can download a new firmware image from the vendor server and upload it via the web interface of the device. The structure of the uploaded firmware image is \[header, bootloader, header, kernel, rootfs\]. It is worth noting that each header contains an \*\*MD5 checksum\*\*, which is used to verify the data integrity of the firmware. When a firmware image is uploaded, the web server will calculate the image checksums and compare them with the checksum values in the headers. The decompiled function that is used to verify the firmware image is shown below. \`\`\` undefined4 upgradeFirmware(int param\_1,int param\_2) { ... if (param\_2 - 0x30000U < 0x7d0001) { iVar8 = check\_filesize(param\_2); if (iVar8 != 0) { iVar8 = isSysUpgradeNeedChecksum(); if (iVar8 != 0) { local\_30 = \*(undefined4 \*)(param\_1 + 0x4c); local\_2c = \*(undefined4 \*)(param\_1 + 0x50); local\_28 = \*(undefined4 \*)(param\_1 + 0x54); local\_24 = \*(undefined4 \*)(param\_1 + 0x58); pcVar11 = getMd5Key; if (\*(int \*)(param\_1 + 0x94) != 0) { pcVar11 = getMd5Key\_bootloader; } ... iVar8 = md5\_verify\_digest(&local\_30,param\_1,param\_2); if (iVar8 == 0) { printf("image md5 checksum is not correct!\\n\\r"); \*(undefined4 \*)(param\_1 + 0x58) = local\_24; \*(undefined4 \*)(param\_1 + 0x4c) = local\_30; \*(undefined4 \*)(param\_1 + 0x50) = local\_2c; \*(undefined4 \*)(param\_1 + 0x54) = local\_28; return 0x4655; } \*(undefined4 \*)(param\_1 + 0x50) = local\_2c; \*(undefined4 \*)(param\_1 + 0x4c) = local\_30; \*(undefined4 \*)(param\_1 + 0x54) = local\_28; \*(undefined4 \*)(param\_1 + 0x58) = local\_24; } if (((DAT\_10002810 != 0) && (iVar8 = isFreeUpdate(), iVar8 == 0)) && ((iVar8 = getProductId(), \*(int \*)(param\_1 + 0x40) != iVar8 || (iVar8 = getProductVer(), \*(int \*)(param\_1 + 0x44) != iVar8)))) { printf("Firmware version check failed"); return 0x4655; } ... } \`\`\` However, the communication during firmware delivery uses the plain HTTP protocol, which does not provide any cryptographic protection of the uploaded contents. Also, there is no signature verification for the update firmware image. Therefore, an attacker with a privileged network position (which could be obtained via ARP spoofing, DNS spoofing, or other approaches) can exploit this issue in order to provide customized malicious firmware updates. Specifically, the attack could replace several bytes in the kernel with arbitrary bytes and replace the checksums in the header after calculating the checksums of the modified firmware image. In this way, a customized malicious firmware image is crafted. During the firmware update process, the attacker can replace the user-uploaded firmware with the crafted firmware, which then causes the device to no longer work or planted with backdoors or malware. The vulnerability has been successfully exploited by creating a proof-of-concept. Take TL-WA901ND V1 (firmware version: 3.11.2) as an example. In this our case, we modified the 4 bytes (address range: 0x20800 to 0x20803) with value 0x9A1B21FF to 0x00000000. Then we modified the checksum fields in the firmware header, the firmware headers before and after modification are listed below. !\[\](https://i.imgur.com/oMUSf9K.png) \*Fig. 2. The original MD5 checksum field in the firmware header.\* \*The original firmware header information:\* \`\`\` Filename : wa901nv1\_en\_3\_11\_2\_up\_boot(100429).bin Filesize : 0x003e0200 / 4063744 Image Vendor : TP-LINK Technologies Image Version : ver. 1.0 Image Size : 0x003e0200 / 4063744 Image Checksum : 08 f5 c5 a5 58 39 1e 73 e4 55 38 a0 b3 4a 14 15 (Valid) Product Id : 0x09010001 (TL-WA901NDv1) Product Version : 0x00000001 Firmware Version : 0.0.0 Bootldr Offset : 0x00000000 / 0 Bootldr Length : 0x0001e0dc / 123100 Image2 Size : 0x003c0000 / 3932160 Image2 Checksum : 4c 70 4a cf 43 c0 51 7d 0d db 8f 01 ba c5 b7 56 (Valid) Kernel Offset : 0x00000200 / 512 Kernel Length : 0x000c70b7 / 815287 Kernel Load Address: 0x80002000 Kernel Entry Point : 0x801a2000 Kernel Checksum : 08 d7 52 57 5c 67 6c 1c 4e 24 0a 0e e5 f2 c7 20 (Not Verified) Rootfs Offset : 0x00100000 / 1048576 Rootfs Length : 0x002c0000 / 2883584 \`\`\` --- !\[\](https://i.imgur.com/Xfp936v.png) \*Fig. 3. The modified MD5 checksum field in the firmware header.\* \*The modified firmware header information:\* \`\`\` Filename : wa901nv1\_en\_3\_11\_2\_up\_boot(100429).bin-new Filesize : 0x003e0200 / 4063744 Image Vendor : TP-LINK Technologies Image Version : ver. 1.0 Image Size : 0x003e0200 / 4063744 Image Checksum : e8 56 f8 c4 98 d9 36 09 b3 14 a1 50 4a 8d 08 fa (Valid) Product Id : 0x09010001 (TL-WA901NDv1) Product Version : 0x00000001 Firmware Version : 0.0.0 Bootldr Offset : 0x00000000 / 0 Bootldr Length : 0x0001e0dc / 123100 Image2 Size : 0x003c0000 / 3932160 Image2 Checksum : 79 e6 c6 c4 60 a8 18 db 43 4a dd 4f b1 7b 81 ba (Valid) Kernel Offset : 0x00000200 / 512 Kernel Length : 0x000c70b7 / 815287 Kernel Load Address: 0x80002000 Kernel Entry Point : 0x801a2000 Kernel Checksum : 08 d7 52 57 5c 67 6c 1c 4e 24 0a 0e e5 f2 c7 20 (Not Verified) Rootfs Offset : 0x00100000 / 1048576 Rootfs Length : 0x002c0000 / 2883584 \`\`\` After replacing the original firmware image with the crafted firmware image during the firmware update procedure, the firmware verification is passed and then the malicious firmware is flashed into the device. Until now, the firmware modification attack is launched successfully.

CVE-2022-46910: A Firmware Modification Vulnerability During Firmware Update in TP-Link TL-WA901N / TL-WA901ND Wireless Access Point - HackMD

An exploitable firmware modification vulnerability was discovered on TP-Link TL-WR743ND V1. An attacker can conduct a MITM (Man-in-the-Middle) attack to modify the user-uploaded firmware image and bypass the CRC check, allowing attackers to execute arbitrary code or cause a Denial of Service (DoS). This affects v3.12.20 and earlier.

\# A Firmware Modification Vulnerability During Firmware Update in TP-Link TL-WR743ND Wireless Routers ## Affected Products: We have tested on the TP-Link TL-WR743ND V1 (Firmware Version: 3.12.20 and earlier) device. Also, we suspect it may also work on other models of TL-WR743ND series devices. ## Overview: An exploitable firmware modification vulnerability was discovered on the TP-Link TL-WR743ND wireless routers. A specially crafted firmware update image can allow an attacker to bypass the firmware verification in the firmware update process and install a malicious firmware image, thus resulting in either denial-of-service (DoS) or malware or backdoor planting. This vulnerability could be triggered during a user performing a firmware update with a self-uploaded firmware image. During the firmware delivery, the attacker can replace the user-uploaded firmware image with the malicious firmware image. ## Details: When performing a firmware update, users can download a new firmware image from the vendor server and upload it via the web interface of the device. The firmware update web interface is shown below. !\[\](https://i.imgur.com/tGSS0ec.png) \*Fig. 1. The web interface for firmware update.\* The structure of the firmware image is \[header, bootloader, header, kernel, rootfs\]. It is worth noting that each header contains an \*\*MD5 checksum\*\*, which is used to verify the data integrity of the firmware. When a firmware image is uploaded, the web server will calculate the image checksums and compare them with the checksum values in the headers. The decompiled function that is used to verify the firmware image is shown below. \`\`\` undefined4 upgradeFirmware(int param\_1,int param\_2) { ... if (param\_2 - 0x30000U < 0x7d0001) { iVar8 = check\_filesize(param\_2); if (iVar8 != 0) { iVar8 = isSysUpgradeNeedChecksum(); if (iVar8 != 0) { local\_30 = \*(undefined4 \*)(param\_1 + 0x4c); local\_2c = \*(undefined4 \*)(param\_1 + 0x50); local\_28 = \*(undefined4 \*)(param\_1 + 0x54); local\_24 = \*(undefined4 \*)(param\_1 + 0x58); pcVar11 = getMd5Key; if (\*(int \*)(param\_1 + 0x94) != 0) { pcVar11 = getMd5Key\_bootloader; } ... iVar8 = md5\_verify\_digest(&local\_30,param\_1,param\_2); if (iVar8 == 0) { printf("image md5 checksum is not correct!\\n\\r"); \*(undefined4 \*)(param\_1 + 0x58) = local\_24; \*(undefined4 \*)(param\_1 + 0x4c) = local\_30; \*(undefined4 \*)(param\_1 + 0x50) = local\_2c; \*(undefined4 \*)(param\_1 + 0x54) = local\_28; return 0x4655; } \*(undefined4 \*)(param\_1 + 0x50) = local\_2c; \*(undefined4 \*)(param\_1 + 0x4c) = local\_30; \*(undefined4 \*)(param\_1 + 0x54) = local\_28; \*(undefined4 \*)(param\_1 + 0x58) = local\_24; } if (((DAT\_100027f0 != 0) && (iVar8 = isFreeUpdate(), iVar8 == 0)) && ((iVar8 = getProductId(), \*(int \*)(param\_1 + 0x40) != iVar8 || (iVar8 = getProductVer(), \*(int \*)(param\_1 + 0x44) != iVar8)))) { printf("Firmware version check failed"); return 0x4655; } ... } \`\`\` However, the communication during firmware delivery uses the plain HTTP protocol, which does not provide any cryptographic protection of the uploaded contents. Also, there is no signature verification for the update firmware image. Therefore, an attacker with a privileged network position (which could be obtained via ARP spoofing, DNS spoofing, or other approaches) can exploit this issue in order to provide customized malicious firmware updates. Specifically, the attack could replace several bytes in the kernel with arbitrary bytes and replace the checksums in the header after calculating the checksums of the modified firmware image. In this way, a customized malicious firmware image is crafted. During the firmware update process, the attacker can replace the user-uploaded firmware with the crafted firmware, which then causes the device to no longer work or planted with backdoors or malware. The vulnerability has been successfully exploited by creating a proof-of-concept. In this our case, we modified the 4 bytes (offset range: 0x102C to 0x102F) with value 0x077C6EC0 to 0x00000000. Then we modified the checksum fields in the firmware header, the firmware headers before and after modification are listed below. !\[\](https://i.imgur.com/cvHig9Y.png) \*Fig. 2. The original MD5 checksum field in the firmware header.\* \*The original firmware header information:\* \`\`\` Filename : wr743ndv1\_en\_3\_12\_20\_up\_boot(130109).bin Filesize : 0x003e0200 / 4063744 Image Vendor : TP-LINK Technologies Image Version : ver. 1.0 Image Size : 0x003e0200 / 4063744 Image Checksum : 04 d5 e5 40 d0 9c 34 c4 3d a3 fd aa df b6 3f 40 (Valid) Product Id : 0x07430001 Product Version : 0x00000001 Firmware Version : 3.12.20 Bootldr Offset : 0x00000000 / 0 Bootldr Length : 0x0001e250 / 123472 Image2 Size : 0x003c0000 / 3932160 Image2 Checksum : 28 38 4b 7e 5f 69 a9 b6 45 4c e4 b3 37 7a a8 c9 (Valid) Kernel Offset : 0x00000200 / 512 Kernel Length : 0x000c6fb4 / 815028 Kernel Load Address: 0x80002000 Kernel Entry Point : 0x801a2000 Kernel Checksum : e4 fd 7d bd 42 c7 8e 4d 72 8a ae 7d 17 70 77 f5 (Not Verified) Rootfs Offset : 0x00100000 / 1048576 Rootfs Length : 0x002c0000 / 2883584 \`\`\` --- !\[\](https://i.imgur.com/qr86GaF.png) \*Fig. 3. The modified MD5 checksum field in the firmware header.\* \*The modified firmware header information:\* \`\`\` Filename : wr743ndv1\_en\_3\_12\_20\_up\_boot(130109).bin Filesize : 0x003e0200 / 4063744 Image Vendor : TP-LINK Technologies Image Version : ver. 1.0 Image Size : 0x003e0200 / 4063744 Image Checksum : 84 8c a9 67 87 80 93 a4 0d 8a bb 40 dc 71 13 26 (Valid) Product Id : 0x07430001 Product Version : 0x00000001 Firmware Version : 3.12.20 Bootldr Offset : 0x00000000 / 0 Bootldr Length : 0x0001e250 / 123472 Image2 Size : 0x003c0000 / 3932160 Image2 Checksum : e6 e6 e4 5d bf aa 31 1f 15 ba 1d ab 91 2e 2c 80 (Valid) Kernel Offset : 0x00000200 / 512 Kernel Length : 0x000c6fb4 / 815028 Kernel Load Address: 0x80002000 Kernel Entry Point : 0x801a2000 Kernel Checksum : e4 fd 7d bd 42 c7 8e 4d 72 8a ae 7d 17 70 77 f5 (Not Verified) Rootfs Offset : 0x00100000 / 1048576 Rootfs Length : 0x002c0000 / 2883584 \`\`\` After replacing the original firmware image with the crafted firmware image during the firmware update procedure, the firmware verification is passed and then the malicious firmware is flashed into the device. Until now, the firmware modification attack is launched successfully.

CVE-2022-46432: A Firmware Modification Vulnerability During Firmware Update in TP-Link TL-WR743ND Wireless Routers - HackMD

An issue in the firmware update process of TP-Link TL-WA7510N v1 v3.12.6 and earlier allows attackers to execute arbitrary code or cause a Denial of Service (DoS) via uploading a crafted firmware image.

\# A Firmware Modification Vulnerability During Firmware Update in TP-Link TL-WA7510N V1 Wireless Access Point ## Affected Products: We have tested on the TP-Link TL-WA7510N V1 (firmware version: 3.12.6 and earlier) device. Also, we suspect it may also work on other models of TL-WA7510N series devices. ## Overview: An exploitable firmware modification vulnerability was discovered on the TP-Link TL-WA7510N wireless access points. A specially crafted firmware update image can allow an attacker to bypass the firmware verification in the firmware update process and install a malicious firmware image, thus resulting in either denial-of-service (DoS) or malware or backdoor planting. This vulnerability could be triggered during a user performing a firmware update with a self-uploaded firmware image. During the firmware delivery, the attacker can replace the user-uploaded firmware image with the malicious firmware image. ## Details: When performing a firmware update, users can download a new firmware image from the vendor server and upload it via the web interface of the device. The firmware update web interface is shown below. !\[\](https://i.imgur.com/SWc6ulB.png) \*Fig. 1. The web interface for firmware update.\* The structure of the firmware image is \[header, bootloader, header, kernel, rootfs\]. It is worth noting that each header contains an \*\*MD5 checksum\*\*, which is used to verify the data integrity of the firmware. When a firmware image is uploaded, the web server will calculate the image checksums and compare them with the checksum values in the headers. The decompiled function that is used to verify the firmware image is shown below. \`\`\` undefined4 upgradeFirmware(int param\_1,int param\_2) { ... if (param\_2 - 0x30000U < 0x7d0001) { iVar8 = check\_filesize(param\_2); if (iVar8 != 0) { iVar8 = isSysUpgradeNeedChecksum(); if (iVar8 != 0) { local\_30 = \*(undefined4 \*)(param\_1 + 0x4c); local\_2c = \*(undefined4 \*)(param\_1 + 0x50); local\_28 = \*(undefined4 \*)(param\_1 + 0x54); local\_24 = \*(undefined4 \*)(param\_1 + 0x58); pcVar11 = getMd5Key; if (\*(int \*)(param\_1 + 0x94) != 0) { pcVar11 = getMd5Key\_bootloader; } ... iVar8 = md5\_verify\_digest(&local\_30,param\_1,param\_2); if (iVar8 == 0) { printf("image md5 checksum is not correct!\\n\\r"); \*(undefined4 \*)(param\_1 + 0x58) = local\_24; \*(undefined4 \*)(param\_1 + 0x4c) = local\_30; \*(undefined4 \*)(param\_1 + 0x50) = local\_2c; \*(undefined4 \*)(param\_1 + 0x54) = local\_28; return 0x4655; } \*(undefined4 \*)(param\_1 + 0x50) = local\_2c; \*(undefined4 \*)(param\_1 + 0x4c) = local\_30; \*(undefined4 \*)(param\_1 + 0x54) = local\_28; \*(undefined4 \*)(param\_1 + 0x58) = local\_24; } if (((DAT\_10005820 != 0) && (iVar8 = isFreeUpdate(), iVar8 == 0)) && ((iVar8 = getProductId(), \*(int \*)(param\_1 + 0x40) != iVar8 || (iVar8 = getProductVer(), \*(int \*)(param\_1 + 0x44) != iVar8)))) { printf("Firmware version check failed"); return 0x4655; } ... } \`\`\` However, the communication during firmware delivery uses the plain HTTP protocol, which does not provide any cryptographic protection of the uploaded contents. Also, there is no signature verification for the update firmware image. Therefore, an attacker with a privileged network position (which could be obtained via ARP spoofing, DNS spoofing, or other approaches) can exploit this issue in order to provide customized malicious firmware updates. Specifically, the attack could replace several bytes in the kernel with arbitrary bytes and replace the checksums in the header after calculating the checksums of the modified firmware image. In this way, a customized malicious firmware image is crafted. During the firmware update process, the attacker can replace the user-uploaded firmware with the crafted firmware, which then causes the device to no longer work or planted with backdoors or malware. The vulnerability has been successfully exploited by creating a proof-of-concept. In this our case, we modified the 4 bytes (address range: 0x207A0 to 0x207A3) with value 0x17F64643 to 0x00000000. Then we modified the checksum fields in the firmware header, the firmware headers before and after modification are listed below. !\[\](https://i.imgur.com/T7b1bKW.png) \*Fig. 2. The original MD5 checksum field in the firmware header.\* \*The original firmware header information:\* \`\`\` Filename : wa7510nv1\_en\_3\_12\_6\_up\_boot(130427).bin Filesize : 0x003e0200 / 4063744 Image Vendor : TP-LINK Technologies Image Version : ver. 1.0 Image Size : 0x003e0200 / 4063744 Image Checksum : 6f 16 2d 3e 23 98 fc cf 81 67 61 ac 60 11 e9 8d (Valid) Product Id : 0x75100001 Product Version : 0x00000001 Firmware Version : 3.12.6 Bootldr Offset : 0x00000000 / 0 Bootldr Length : 0x0001e40c / 123916 Image2 Size : 0x003c0000 / 3932160 Image2 Checksum : 27 54 5e a7 f6 ae aa dc ee 2b ea d0 c8 e8 71 bc (Valid) Kernel Offset : 0x00000200 / 512 Kernel Length : 0x000c70d7 / 815319 Kernel Load Address: 0x80002000 Kernel Entry Point : 0x801a2000 Kernel Checksum : be e0 c9 2c dc 66 74 b4 5f 5e 0d 29 61 3f c3 14 (Not Verified) Rootfs Offset : 0x00100000 / 1048576 Rootfs Length : 0x002c0000 / 2883584 \`\`\` --- !\[\](https://i.imgur.com/YtmcPEP.png) \*Fig. 3. The modified MD5 checksum field in the firmware header.\* \*The modified firmware header information:\* \`\`\` Filename : wa7510nv1\_en\_3\_12\_6\_up\_boot(130427).bin Filesize : 0x003e0200 / 4063744 Image Vendor : TP-LINK Technologies Image Version : ver. 1.0 Image Size : 0x003e0200 / 4063744 Image Checksum : 03 0a 1a 0d 73 5b 5f bb 63 e3 40 5a ba ae cf 7d (Valid) Product Id : 0x75100001 Product Version : 0x00000001 Firmware Version : 3.12.6 Bootldr Offset : 0x00000000 / 0 Bootldr Length : 0x0001e40c / 123916 Image2 Size : 0x003c0000 / 3932160 Image2 Checksum : b6 83 a3 99 28 b4 e0 0a 51 d8 ab ce 9c 49 4e d3 (Valid) Kernel Offset : 0x00000200 / 512 Kernel Length : 0x000c70d7 / 815319 Kernel Load Address: 0x80002000 Kernel Entry Point : 0x801a2000 Kernel Checksum : be e0 c9 2c dc 66 74 b4 5f 5e 0d 29 61 3f c3 14 (Not Verified) Rootfs Offset : 0x00100000 / 1048576 Rootfs Length : 0x002c0000 / 2883584 \`\`\` After replacing the original firmware image with the crafted firmware image during the firmware update procedure, the firmware verification is passed and then the malicious firmware is flashed into the device. Until now, the firmware modification attack is launched successfully.

Tag

#dos