Circle with Disney Apid Strstr Authentication Bypass Vulnerability(CVE-2017-2914)

### 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/ ### 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 applist file is the haystack [2] and the token that we provide is the needle [3]. If we take a look at the applist 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 applist 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 applist 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