Vulnerabilities > CVE-2017-2914 - Improper Authentication vulnerability in Meetcircle Circle With Disney Firmware 2.0.1

047910
CVSS 6.8 - MEDIUM
Attack vector
NETWORK
Attack complexity
MEDIUM
Privileges required
NONE
Confidentiality impact
PARTIAL
Integrity impact
PARTIAL
Availability impact
PARTIAL

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.

Vulnerable Configurations

Part Description Count
OS
Meetcircle
1
Hardware
Meetcircle
1

Common Weakness Enumeration (CWE)

Common Attack Pattern Enumeration and Classification (CAPEC)

  • Authentication Abuse
    An attacker obtains unauthorized access to an application, service or device either through knowledge of the inherent weaknesses of an authentication mechanism, or by exploiting a flaw in the authentication scheme's implementation. In such an attack an authentication mechanism is functioning but a carefully controlled sequence of events causes the mechanism to grant access to the attacker. This attack may exploit assumptions made by the target's authentication procedures, such as assumptions regarding trust relationships or assumptions regarding the generation of secret values. This attack differs from Authentication Bypass attacks in that Authentication Abuse allows the attacker to be certified as a valid user through illegitimate means, while Authentication Bypass allows the user to access protected material without ever being certified as an authenticated user. This attack does not rely on prior sessions established by successfully authenticating users, as relied upon for the "Exploitation of Session Variables, Resource IDs and other Trusted Credentials" attack patterns.
  • Exploiting Trust in Client (aka Make the Client Invisible)
    An attack of this type exploits a programs' vulnerabilities in client/server communication channel authentication and data integrity. It leverages the implicit trust a server places in the client, or more importantly, that which the server believes is the client. An attacker executes this type of attack by placing themselves in the communication channel between client and server such that communication directly to the server is possible where the server believes it is communicating only with a valid client. There are numerous variations of this type of attack.
  • Utilizing REST's Trust in the System Resource to Register Man in the Middle
    This attack utilizes a REST(REpresentational State Transfer)-style applications' trust in the system resources and environment to place man in the middle once SSL is terminated. Rest applications premise is that they leverage existing infrastructure to deliver web services functionality. An example of this is a Rest application that uses HTTP Get methods and receives a HTTP response with an XML document. These Rest style web services are deployed on existing infrastructure such as Apache and IIS web servers with no SOAP stack required. Unfortunately from a security standpoint, there frequently is no interoperable identity security mechanism deployed, so Rest developers often fall back to SSL to deliver security. In large data centers, SSL is typically terminated at the edge of the network - at the firewall, load balancer, or router. Once the SSL is terminated the HTTP request is in the clear (unless developers have hashed or encrypted the values, but this is rare). The attacker can utilize a sniffer such as Wireshark to snapshot the credentials, such as username and password that are passed in the clear once SSL is terminated. Once the attacker gathers these credentials, they can submit requests to the web service provider just as authorized user do. There is not typically an authentication on the client side, beyond what is passed in the request itself so once this is compromised, then this is generally sufficient to compromise the service's authentication scheme.
  • Man in the Middle Attack
    This type of attack targets the communication between two components (typically client and server). The attacker places himself in the communication channel between the two components. Whenever one component attempts to communicate with the other (data flow, authentication challenges, etc.), the data first goes to the attacker, who has the opportunity to observe or alter it, and it is then passed on to the other component as if it was never intercepted. This interposition is transparent leaving the two compromised components unaware of the potential corruption or leakage of their communications. The potential for Man-in-the-Middle attacks yields an implicit lack of trust in communication or identify between two components.

Seebug

bulletinFamilyexploit
description### 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
idSSV:96824
last seen2017-11-19
modified2017-11-09
published2017-11-09
reporterRoot
titleCircle with Disney Apid Strstr Authentication Bypass Vulnerability(CVE-2017-2914)

Talos

idTALOS-2017-0421
last seen2019-05-29
published2017-10-31
reporterTalos Intelligence
sourcehttp://www.talosintelligence.com/vulnerability_reports/TALOS-2017-0421
titleCircle with Disney Apid Strstr Authentication Bypass Vulnerability