Circle with Disney Apid Strstr Authentication Bypass Vulnerability

Summary

An exploitable authentication bypass vulnerability exists in the API daemon of Circle with Disney running firmware 2.0.1. A specially crafted token can bypass the authentication routine of the Apid binary, causing the device to grant unintended administrative access. An attacker needs network connectivity to the device to trigger this vulnerability.

Tested Versions

Circle with Disney 2.0.1

Product URLs

<https://meetcircle.com/&gt;

CVSSv3 Score

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

CWE

CWE-287: Improper Authentication

Details

The apid binary is a web server listening on the Disney Circle, that serves as the main API for user functionality. Through the apid server, all configurations and queries are made from the ‘Circle Home’ application from the administrator’s phone. A subset of the possible API calls require authentication in the form of a token passed usually in the URL string like such:

 /api/QUERY/overall api=1.0&token=8CE211123413-yB7THJFyZ9uKInbm-20170721.092412

The token is always 0x2d characters long and consists of three subsections (%s-%s-%s), with the first part being the mac address of the administrator’s phone, the second part a randomized hash based off properties within the admin’s phone, and the third part is the date and time that the token was generated. Needless to say, it should be rather difficult to guess such a token.

When the APID server goes to check a provided token, it makes sure that the token is of length 0x2d. If not, we get an error, but otherwise it goes through the following code:

 addiu   $a0, (aMntSharesUsr_2 - 0x430000)  # "/mnt/shares/usr/bin/app_list" [1] 
 jal     fopen
 la      $a1, (aClear_0+4)  # mode - 'r'
 bnez    $v0, loc_407EE4 
 move    $s1, $v0 [2]
[…]

Opening the “/mnt/shares/usr/bin/app_list” file [1] and then storing the file descriptor in $s1. After this it starts reading, line-by-line.

loc_407EE4:                              # CODE XREF: authorizor+54#j
addiu   $a0, $sp, 0xA8+var_90  # s
li      $a1, 0x80        # n
jal     fgets
move    $a2, $s1         # stream

And then tries to match each line against the provided token:

addiu   $a0, $sp, 0xA8+var_90  # haystack [2]
bnez    $v0, loc_407ED4
move    $a1, $s0         # needle [3]
move    $s0, $zero
[...]
loc_407ED4:
jal     strstr
nop
nez    $v0, loc_407F24

Where by the given line of our app_list file is the haystack [2] and the token that we provide is the needle [3]. If we take a look at the app_list file, we can quickly see a potential issue:

root@circle:~# head -n 1 /mnt/shares/usr/bin/app_list 
80:cd:11:36:22:ab 6ab4f12345678902224abcdabcdabcde12341234 8CE211123413-yB7THJFyZ9uKInbm-20170721.092412

The app_list file actually contains a lot more than just a list of token entries, so, due to how strstr works, as long as we can match any length 0x2d substring within a given line, the bypass occurs. Thus we should probably examine the app_list file’s components. The base format will always be the same, “%s %s %s”, where the last component is the token used for authentication and the first component is the mac address of the administrator’s phone that has synced with the Circle. This leaves the second component, which is the “appid”.

The appid is a SHA-1 hash generated by the admin’s phone, and is saved upon initial syncing of the phone, when the admin needs to use the token api call (/api/TOKEN). Unfortunately, it’s not quite length 0x2d, but it’s almost there, being short by 5 bytes. If we take the spaces before and after, we’re still 3 chars short, which could then probably be brute forced rather easily, but there’s a simpler method. Since the next 3 bytes are the OUI portion of the Circle’s Mac address, they’re probably never going to change for the foreseeable future, so the authencation mechanism can be bypassed with the following string:

#“ [appid] 8CE”
token=6ab4f12345678902224abcdabcdabcde12341234 8CE

This naturally leads to the question of where to get the appid, but there’s actually a very interesting case in which this information is leaked. When the administrator’s phone connects to the remote circle device, it’s over a connection to remote.meetcircle.co over SSL. The client cert used by the phone contains the following SSL certificate attributes:

# OU=[circleMAC]-[appid]_CIRCLEHOME
OU=8CE211123413-6ab4f12345678902224abcdabcdabcde_CIRCLEHOME

Since this information is included in the client SSL certificate attributes, whenever an administrator connects to their Circle device, the appid is sent in plain text over the network, and can be used to gain administrative access to the Circle.

Timeline

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