An exploitable vulnerability exists in the user photo update functionality of Circle with Disney running firmware 2.0.1. A repeated set of specially crafted API calls can cause the device to corrupt essential memory, resulting in a bricked device. An attacker needs network connectivity to the device to trigger this vulnerability.
Circle with Disney 2.0.1
7.5 - CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
CWE-400: Uncontrolled Resource Consumption ('Resource Exhaustion')
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 for the administrator's phone. Naturally, the unimportant API calls are run without authentication, whilst the critical API calls require a specific token, one that is unique to each phone that has synced to the Circle with the administrator app. However there is one API call that behaves slightly different.
The '/api/UPDATE/users/user/photo' API call requires authentication as expected, however there is an extra action taken by the server in preparation for the photo upload, which is passed via HTTP POST params. Since the server needs to parse the POST parameters regardless of the photo, it allocates a new buffer to deal with the rest of the POST parameters. An example follows:
POST /api/UPDATE/users/user/photo HTTP/1.1 Host: 192.168.1.1:4567 Connection: keep-alive Accept-Encoding: gzip, deflate Accept: */* User-Agent: python-requests/2.17.3 Content-Length: 92 Content-Type: application/x-www-form-urlencoded a=1%3C%28%5E_%5E%29%3E&photo%3Dboop%2612&test=12345678
For the above example, it finds the first occurrence of 'photo=' (photo%3D) and then the first occurrence of “&” after that. Every character outside of those boundaries count towards the new allocation.
.text:00415144 la $a1, aApiUpdateUsers # "/api/UPDATE/users/user/photo" .text:00415148 jal strcmp .text:0041514C sb $zero, byte_499B98 .text:00415150 bnez $v0, loc_4154A8 .text:00415154 lui $s6, 0x43 .text:00415158 lw $v1, 0x21B0+arg_10($sp) .text:0041515C nop .text:00415160 beqz $v1, loc_4154A8 .text:00415164 lui $a1, 0x43 .text:00415168 move $a0, $v1 # haystack .text:0041516C jal strstr .text:00415170 la $a1, aPhoto # "photo=" .text:00415174 beqz $v0, loc_4154A4 .text:00415178 move $s6, $v0 .text:0041517C move $a0, $v0 # s .text:00415180 jal strchr .text:00415184 li $a1, 0x26 # c .text:00415188 lw $v1, 0x21B0+arg_10($sp) .text:0041518C move $s7, $v0 .text:00415190 beqz $v0, loc_415AA4 .text:00415194 subu $fp, $s6, $v1 .text:00415198 sb $zero, 0($v0) .text:0041519C jal strlen .text:004151A0 addiu $a0, $v0, 1 # s .text:004151A4 sw $v0, 0x21B0+var_30($sp) .text:004151A8 .text:004151A8 loc_4151A8: # CODE XREF: api_parse:loc_415AA4#j .text:004151A8 lw $v1, 0x21B0+var_30($sp) .text:004151AC nop .text:004151B0 addu $a0, $fp, $v1 .text:004151B4 jal malloc .text:004151B8 addiu $a0, 1 # size
Thus, if an attacker sends POST parameters with an extremely large number of characters, the behavior of the Circle starts to get unreliable. As much as a descriptive and detailed explanation would be satisfying, it can only suffice to say that the device gets bricked, somewhat.
The LED will start blinking, and then device will reboot. The only ways back in are through ethernet (10.123.234.1 or IPV6), if you happen to have credentials, or through the console port.
Regardless the Circle will be missing its /dev/sda flash drive, effectively rendering the device into a bare bones MIPS board with around 40 MB of space.
2017-08-02- Vendor Disclosure
2017-10-31 - Public Release
Discovered by Lilith Wyatt <(^_^)> of Cisco Talos.