Prepping for Pwn2Own 2022

The Ledger Donjon tried to participate in the Pwn2Own Toronto 2022 edition. This blogpost details how we conducted vulnerability research in order to participate in the contest and highlights a few vulnerabilities found on selected targets. Spoiler: we did not participate eventually because the vulnerabilities found were either patched by the vendors a few days before the event, or not exploitable in the context scenarios proposed by the organisers.

Media outlets often narrate that some device was hacked in a few seconds, which does not highlight that vulnerability research and exploit development often take weeks or even months to achieve this impressive hacking feat during the context. As this was our first attempt to participate in this event, we found it particularly interesting even if we did not eventually make it.

Targets Selection

Pwn2Own contests happen 2 to 3 times a year in Miami, Vancouver, Tokyo, Austin and Toronto. This year, a new category was added: Small Office / Home Office (SOHO) Smash-up:

The attempt must begin by exploiting the WAN side of the selected router from the Router Category and pivot to the LAN side to launch the next stage of the attempt. After successfully compromising the router, the attempt must pivot from the LAN side of the router and compromise a selected device from the Home Automation Hub, Smart Speaker, Printer, or Network Attached Storage Categories within the contest network. The contestant is free to select any combination of router and home automation hub, smart speaker, printer, or network attached storage device during the registration process.

We first analysed the result of previous editions in order to buy devices on which vulnerability research would be conducted. Intuitively, we assumed that devices that were compromised in previous editions tend to be more encline to have security issues than other devices.

As TP-Link targets were successfully compromised for the past 3 years we chose the TP-Link AX1800 WiFi 6 Router. For the LAN device, we already owned a Synology DiskStation and chose to go for this one, even if it was only compromised once, in 2021.

Remote Work on a Pwn2Own Target

Our office is based in Paris but some people in the team are working from a remote location. Interacting dynamically with the target to search for vulnerabilities and stabilizing exploits is an essential part of the process. However, working on network equipments while being remote can sometimes be tricky.

In order to mock the fact that we are physically present near the network equipments, we used a combination of Virtual Private Networks (VPN) and a Next Unit of Computing (NUC).

Our setup is described in the following schema:

The WAN of the target is set to be reachable through a corporate VPN, to which every researcher has access. The LAN interface of the target is connected to the NUC. Additionally, the NUC WAN interface is connected to the corporate VPN. For a researcher to send packets in the target’s LAN, they should first be connected to a dedicated VPN for which the NUC WAN interface is an endpoint (thus, the dedicated VPN traffic is actually tunneled through the corporate VPN). Finally, every packet having the target’s LAN address for destination is routed to the target’s LAN interface by the NUC using Network Address Translation.

Targets Analysis

TP-Link AX1800 WiFi 6 Router (Archer AX21)

We analysed the product in this version:

Hardware Version: Archer AX21 v30
Firmware Version: 1.1.1 Build 20220603 rel.3137(5553)

Extracting the firmware can be done with usual tools such as binwalk and ubi_reader.

Factory Settings Reset

The tddp daemon is launched during the boot by /etc/rc.local. It listens on UDP/1040. Note that the daemon exits after 10 minutes if there is no connection (select() is called with a timeout of 600 seconds).

The TDDP packet format is:

This daemon accepts 2 sets of commands; commands which read the router configuration are not authenticated, while commands which modify the router configuration are authenticated.

An optional payload can be appended after the header, encrypted with DES with a key being MD5(username + password)[:8]. The MD5 digest is computed over the whole decrypted payload. If the MD5 digest does not match, the packet is rejected. If the payload is not empty, the DES key must be known, otherwise one cannot compute a valid MD5.

All this encryption mechanism is used to authenticate commands writing the router configuration but can be bypassed by passing a 0 PktLength and a cleartext payload.

Once the authentication is bypassed, 2 commands are of interest: one of them allows to reset the router to its factory settings, and the other one to reboot the router. It allows an attacker to connect to the web interface and proceeds to the router initialization and sets an arbitrary administrator password.

Arbitrary Command Execution

There is a command injection vulnerability in the web interface. In System > System Log, Mail Log, Frequency, Every Day, the parameter every_day_time is not sanitized and can be used to inject arbitrary values into crontab. The following payload can be used to get a reverse shell (the cron job is executed every minute):

From LAN to WAN

These 2 vulnerabilities should not be available to a WAN attacker because of the firewall rules if they were correct. However, the following firewall rule allows the connection to any UDP service from the WAN if the target IP address is 224.0.0.1 (All Hosts multicast address):

This vulnerability can be exploited from the WAN by sending the UDP packet with a destination IP address set to 224.0.0.1. The tddp vulnerability can thus be reached from the Internet but the web interface access is still filtered, because it is not an UDP service. However, we noticed that the firewall rules are loaded after daemons have been launched. This results in some services (eg. the web interface) being accessible from the WAN for a short period of time after a reboot.

Thus, TCP connections can be established (to the port 443) during the boot of the router, before the firewall initialization. These TCP connections can be used to send HTTPS requests to the web admin interface.

From WAN towards None

To sum it up, a chain of 4 vulnerabilities allows arbitrary command execution from the WAN:

A firewall misconfiguration allows to connect to the tddp service from the WAN.
An authentication bypass in the tddp network daemon allows a remote attacker to reset the router to its factory settings and reboot it.
The firewall rules are loaded after the web server, which allows access to the web interface during a short period of time.
During the setup of the router, an attacker can choose an arbitrary admin password. Once logged in to the web interface, a vulnerability allows to execute arbitrary commands.

The ZDI team kindly reminded us that every contest entry must be a separate and unique exploit chain, so we only registered for the WAN scenario. Anyway, the tddp service was silently disabled in the 1.1.3 Build 20221125 rel.83530(5553) version, published on 2022-12-02, that is, 4 days before the contest. According to the release:

New Features/Enhancement:

Upgrade the version of the dnsmasq;

Enhance device security;

Fixed the bug that the TimeMachine does not work under Macos13.1

Indeed, tddp is now disabled by default and only launched in factory mode.

We withdrew our participation to the contest at that time.

Synology DiskStation DS920+

We spent a lot of time on this device, hoping to find a vulnerability for the SOHO category with the goal of compromising the Synology DiskStation DS920+ in the final stage.

While we did find security issues, we did not manage to write an exploit for them.

Synology RT6600ax

The Synology software runs on a standard Linux system. The firmware does not need to be extracted since a root shell is available by-design for admins. The layout is similar to the DiskStation with a different architecture though, AARCH64 instead of x86-64.

First SSRF

The synowolagentd daemon binds to the LAN interface and listens on TCP/11022. It expects JSON packets encrypted using a custom encryption mechanism involving an AES key embedded in the packet. Four commands (wait_command, wakeup, rt_register and update_bootstate) are implemented. The update_bootstate is vulnerable to SSRF attacks and a packet such as the following one makes synowolagentd do a POST request to https://evil.blah/:

No other field than the host and the port of HTTPS request are controlled by the attacker.

Second SSRF

synowolagentd expects a JSON answer from this POST request. The processing of this answer results in a second SSRF. The following malicious answer makes synowolagentd do an HTTP request on http://evil.blah:1337/pwn:

This time, every part of the URL is controlled by the attacker. The request is made by libcurl, built with the following protocol and features:

From SSRF to Arbitrary Command Execution

We looked for vulnerabilities in daemons that are not reachable without this SSRF vulnerability. mcsd listens on TCP/10000 on the loopback interface (127.0.0.1) and provides a custom prompt expecting specific commands, mostly to get statistics on network interfaces. The command dbg redirect looks interesting from an attacker point-of-view since it allows writing data to files in the /tmp/ folder:

The resulting log entries have the following format and are not entirely controlled:

These log entries can be generated from the SSRF vulnerability thanks to the gopher protocol, with URLs such as:

We first used inotify to learn which files are accessed in the /tmp/ folder, however it does not work for non-existing files. strace eventually comes to our rescue with the following arguments:

A few services regularly use files in the /tmp/ folder. We tried to gain command execution for each of these services, most interesting (but unsuccessful) tries being:

/tmp/.syno_dbus_session_address is regularly accessed by avahi-browse. According to the dbus specification, arbitrary commands can be executed with unixexec addresses, however unixexec addresses are not listenable, which does not work in this scenario.
/tmp/ssdp/pwn.cgi can be accessed by Apache, however httpd refuses to execute it since it does not have the +x bit.
/tmp/ssdp/.htaccess is also parsed by Apache, but unrecognised directives lead to fatal errors.

We eventually chose to overwrite /tmp/synoschedtask which is executed by cron using the following configuration line:

While it works, it means that our payload is executed… every Monday at 3am. The exploit is thus not practical for the Pwn2own contest. We managed to use NTP spoofing to make the payload executed at arbitrary time, however it requires a Man-in-the-Middle attack on the WAN interface. Since the rest of the exploit must be run on the LAN interface and because it is not allowed to attack both WAN and LAN in the context of Pwn2Own, this chain of exploit is not valid for the contest.

Conclusion

The outcome of the research made for Pwn2own 2022 might look a bit harsh because it did not allow us to participate to the contest:

The exploit chain of 4 vulnerabilities that we found against the TP-Link router (exploitable from the WAN interface) was killed 4 days before the contest by the vendor.
The vulnerability against the Synology router is exploitable every Monday around 3am, which does not make it practical for the contest.
We do not have an exploit against the Synology NAS.

However, it was a great opportunity to discover Pwn2own and have a solid ground for next years. This blogpost does not detail the amount of time spent to find the vulnerabilities described here, nor the one we did not mention. But overall it allowed us to develop tools and gain knowledge on targets that have chances to appear again in the upcoming contests. And maybe most importantly, to familiarize ourselves with the Pwn2Own rules.

A question remains open: how do vendors find and patch vulnerabilities before the event? Do they monitor logs sent to them? As an advice to other researchers, we would like to underline the importance of making research in environments disconnected from the Internet.