In the developing OpenWrt project, critical vulnerabilities (CVE-2024-54143) have been identified in the ASU (Attended SysUpgrade) toolkit, allowing the compromise of build artifacts distributed via the sysupgrade.openwrt.org service or third-party ASU servers, enabling attackers to install modified firmware images on users' systems that utilize the "attended upgrade" mode through the web interface selector.openwrt.org or the command-line toolkit attended.sysupgrade.
To successfully carry out an attack, the attacker only needs to send a build request to the ASU server (such requests can be sent by any user without authentication). Through manipulation with a specially crafted package list, the attacker can organize the sending of previously generated malicious images in response to legitimate build requests from other users.
The ASU service is used in OpenWrt to create and install firmware updates without losing existing settings and user-installed packages. Through the web interface or command-line toolkit, a user sends a request to generate an updated firmware image, specifying the packages installed on their system. After some time, the ASU server constructs an image corresponding to the requested content, after which the user downloads it and flashes it onto their device. An additional option is provided to retain existing settings in the updated firmware.
The ASU Server is responsible for processing requests from users, launching an automatic firmware image build using the ImageBuilder toolkit, and maintaining a cache of previously prepared builds. If the user requests an image that has been built previously and is still valid, the system immediately delivers the cached image without starting a build process. server and maintains its relevance, the system immediately delivers the existing image from the cache without initiating the build process.
The behavior of the attack became possible due to two vulnerabilities:
- A vulnerability in the build_reques.py request handler from the Imagebuilder toolkit allows an attacker to inject their own commands into the build process by supplying specially crafted package names. This vulnerability arose from insufficient validation of special characters in package names before they are used as arguments to the make utility. By exploiting this vulnerability, an attacker could create malicious firmware images on the server, signed with a valid build key.
- A vulnerability in the util.py library was found where the SHA-256 hashes used to check for already created firmware images in the cache were truncated to 12 characters, significantly reducing entropy and allowing an attacker to form a malicious image with a hash that matches a legitimate one through collision generation. Combined with the vulnerability in Imagebuilder, the hash issue could be exploited by an attacker to 'pollute' the ASU Server cache and place malicious images that are returned to regular users' requests.
The change that allowed the attack was implemented on July 8. The issue was resolved on December 4. For the operation of the ASU service, separate systems were used, servers, which do not overlap with the main build systems of the project, isolated from OpenWrt Buildbot and without access to sensitive resources such as SSH keys and certificates for creating digital signatures.
It is claimed that the OpenWrt developers found no signs of compromise in the project infrastructure, but as a precaution, they completely reinstalled the systems on which vulnerable components were running. The issue did not affect the official images distributed through downloads.openwrt.org, and analysis of the build logs found no evidence of malicious requests being sent. Meanwhile, as the ASU servers perform automatic cleanup of builds older than 7 days, it was impossible to audit older builds.
The likelihood of the identified vulnerabilities being used in practice to spread malicious images through the OpenWrt infrastructure is assessed by OpenWrt representatives as close to zero; however, ASU users are advised to replace OpenWrt firmware on their devices with the same version.
Source: opennet.ru
