CVSS2
Attack Vector
NETWORK
Attack Complexity
MEDIUM
Authentication
NONE
Confidentiality Impact
PARTIAL
Integrity Impact
PARTIAL
Availability Impact
PARTIAL
AV:N/AC:M/Au:N/C:P/I:P/A:P
CVSS3
Attack Vector
NETWORK
Attack Complexity
HIGH
Privileges Required
NONE
User Interaction
NONE
Scope
UNCHANGED
Confidentiality Impact
HIGH
Integrity Impact
HIGH
Availability Impact
HIGH
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
EPSS
Percentile
71.8%
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.
Circle with Disney 2.0.1
9.0 - CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:H
CWE-287: Improper Authentication
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.
2017-08-29 - Vendor Disclosure
2017-10-31 - Public Release
CVSS2
Attack Vector
NETWORK
Attack Complexity
MEDIUM
Authentication
NONE
Confidentiality Impact
PARTIAL
Integrity Impact
PARTIAL
Availability Impact
PARTIAL
AV:N/AC:M/Au:N/C:P/I:P/A:P
CVSS3
Attack Vector
NETWORK
Attack Complexity
HIGH
Privileges Required
NONE
User Interaction
NONE
Scope
UNCHANGED
Confidentiality Impact
HIGH
Integrity Impact
HIGH
Availability Impact
HIGH
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H
EPSS
Percentile
71.8%