CVE-2017-2912: TALOS-2017-0419 || Cisco Talos Intelligence Group

Summary

An exploitable vulnerability exists in remote control functionality of Circle with Disney running firmware 2.0.1. SSL certificates for specific domain names can cause the goclient daemon to accept a different certificate than intended. An attacker can host an HTTPS server with this certificate to trigger this vulnerability

Tested Versions

Circle with Disney 2.0.1

Product URLs

https://meetcircle.com/

CVSSv3 Score

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

CWE

CWE-300: Channel Accessible by Non-Endpoint (‘Man-in-the-Middle’)

Details

Circle with Disney is a network device used to monitor and restrict internet use of children on a given network. When connected to a given network and configured, it immediately begins arp poisoning all filtered devices on the network, such that it can validate and restrict all traffic as is seen fit by the parent/administrator of the device.

The goclient binary provides an interface to subscribe users to the “Circle Go” functionality of the product. If a parent subscribes to the “Circle Go” service, and then registers their child’s device, they can filter and monitor the child’s phone even when they are not on the same subnet as the Circle device, providing a “cloud” functionality. This functionality relies on an app, ‘MyCircle’, being installed on the child’s phone that will act as the filtering and limiting agent, enforcing restrictions based on decisions made by the Circle device itself.

In order to allow remote functionality, goclient talks with the vpncc.meetcircle.co domain, which in turn talks with the administrator’s phone. In order to provide this persistent and remote administrative capability, the goclient binary will consistently send a ‘ping’ message via udp:8988 to vpncc.meetcircle.co, to which the server will reply with ‘pong’. This allows the server to reach the Circle device whenever necessary, since firewalls will typically allow return UDP traffic of this nature. When the admin needs to perfrom any task remotely, the server will send a ‘connect’ message over this UDP ‘tunnel’, to which the goclient will initiate an SSL connection on port 8988 to the vpncc.meetcircle.co domain. Through this SSL connection, the actual management occurs, there is no messages of import that occur over the UDP communications (only ping and connect).

Unfortunately, there is an issue that lies within the SSL certificate checking of the goclient binary, the disassembly of which is listed below:

.text:004029F4                 lw      $a0, 0x38+arg_0($fp)
.text:004029F8                 jal     SSL_get_peer_certificate #[1]
...
.text:00402A34                 lw      $a0, 0x38+var_20($fp)
.text:00402A38                 jal     X509_get_subject_name #[2]
.text:00402A3C                 nop
.text:00402A40                 move    $a0, $v0
.text:00402A44                 move    $a1, $zero
.text:00402A48                 move    $a2, $zero
.text:00402A4C                 jal     X509_NAME_oneline   #[3]
.text:00402A54                 sw      $v0, 0x38+oneline_buff_malloced($fp)  #[4]

As shown at [1], the goclient grabs the remote server’s SSL certificate, and then at [2], the server gets the X509 subject name, which is typical behavior for SSL verification. X509_NAME_oneline [3] then grabs a lot of the information from the certificate attributes, joins it all into one line, and then stores it into a buffer on the heap [4]. An example return string might be:

`/C=US/ST=Sad/L=boop/O=<(^_^)>/CN=boopdoop.net`

While the interesting behavior of the X509_NAME_oneline can lead to some other vulnerabilites, like including the string ‘CN=*.meetcircle.com” inside of another attribute ( For a great writeup of this: [https://langui.sh/2016/01/29/x509-name-oneline/])(https://langui.sh/2016/01/29/x509-name-oneline/) ) , however, due to reasons mentioned a little further down, the binary was not vulnerable to this, as we could not get a certificate signed by the specific CA to be formed as such.

Interestingly due to how they actually check the Common Name attribute of the SSL cert, the binary was left vulnerable to another attack vector:

.text:00402A54                 sw      $v0, 0x38+oneline_buff_malloced($fp) [1]
.text:00402A58                 lw      $a0, 0x38+oneline_buff_malloced($fp)
.text:00402A5C                 lui     $v0, 0x41
.text:00402A60                 addiu   $a1, $v0, (aCn_meetcircle_ - 0x410000)  #                            "CN=*.meetcircle.com" [2]
.text:00402A64                 jal     strstr [3]
.text:00402A68                 nop
.text:00402A6C                 bnez    $v0, loc_402A94
.text:00402A70                 nop
.text:00402A74                 li      $a0, 3
.text:00402A78                 lui     $v0, 0x41
.text:00402A7C                 addiu   $a1, $v0, (aInvalidCertifi - 0x410000)  # "Invalid certificate\n"

As shown above, we continue from immediately after the X509_NAME_oneline() function call [1]. The return value of this function is compared is compared against “CN=*.meetcircle.com” [2], with the strstr() function [3], which returns a pointer to the first match of register $a1 in $a0 (and NULL otherwise).

Since this is the only check upon the Common Name attribute, it becomes possible to bypass this check by buying the following domains (as per Wikipedia):

meetcircle.community
meetcircle.company
meetcircle.computer

The return value from X509_oneline_name will look as such:

Breakpoint 4, 0x00402650 in _ftext ()
(gdb) x/1s $a0
0x44e9d8:       "/C=AU/ST=Some-State/O=Internet Widgits Pty Ltd/CN=*.meetcircle.computer"

And then the resulting call to strstr will look like such:

 0x402654 <_ftext+1956>:      jal     0x401810 <strstr@plt>
(gdb) x/1s $a1
0x40eb08:       "CN=*.meetcircle.com"
(gdb) ni
0x0040265c in _ftext ()
(gdb) x/1s $v0
0x44ea07:       "CN=*.meetcircle.computer" [1]

With the return value being our malicious domain name [1].

It should be cautioned that certificate presented by the MITM server needs to have its trust chain signed by the Comodo CA. The binary has a barely obfuscated CA cert located inside that is extracted to /tmp/ca.goclient.pem and then utilized to validate the outbound SSL connection. This secondary validation tends to be trivial as the Comodo CA currently offers a free SSL Certificate trial, the hard part is getting the domain name.

Timeline

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

Discovered by Lilith Wyatt and Claudio Bozzato of Cisco Talos.