CVE-2018-3928: TALOS-2018-0595 || Cisco Talos Intelligence Group

Summary

An exploitable code execution vulnerability exists in the firmware update functionality of Yi Home Camera 27US 1.8.7.0D. A specially crafted set of UDP packets can cause a settings change, resulting in denial of service. An attacker can send a set of packets to trigger this vulnerability.

Tested Versions

Yi Technology Home Camera 27US 1.8.7.0D

Product URLs

https://www.yitechnology.com

CVSSv3 Score

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

CWE

CWE-328: Reversible One-Way Hash

Details

Yi Home Camera is an internet-of-things home camera sold globally. The 27US version is one of the newer models sold in the U.S., and is the most basic model out of the Yi Technology camera lineup. It still, however, includes all the functionality that one would expect from an IoT device, such as the ability to view video from anywhere, offline and subscription-based cloud storage, and ease of setup.

When the Yi camera communicates with the Yi Home phone app, in order to provide video feeds and status updates, the network daemon in charge is the p2p_tnp binary. This daemon provides network discovery, authorization, and settings manipulation functionality, all over UDP. The custom protocol handling this is rather simple to start, and a basic overview is given below:

| Magic Byte |  Opcode Byte |  MsgLen Short |  Message (max 0x500)
|       \xF1      |    \x00-\xFF    |   <len of msg> |   <msg>

If the camera and the phone running the ‘Yi Home’ app are on the same subnet, a handshake occurs with the custom TNP protocol before any other operations can happen. The phone sends a MSG_LAN_SEARCH (\x30) packet to UDP port 31208, to which the phone will respond with a MSG_LAN_NOTIFY (\x31) packet from a new source port. It should be noted that this MSG_LAN_SEARCH can be sent to a broadcast address or a single IP address, and also that the MSG_LAN_SEARCH response contains the device ID (DID) of the camera, which is needed to pass certain checks. A sample DID consists of a prefix, serial, and suffix, for example: TNPUSAC-112233-NMEDP.

After the initial packet exchange, the thread controlling this socket enters the PPPP_thread_\recv_Proto_device function, which contains a jumptable for dealing with a subset of the possible TNP opcodes. Of interest for this bug is the MSG_NOTICE_TO (\x3C) opcode, which will copy up to 0x400 bytes of the message into a stack buffer, and start to parse the contents, first looking for a valid DID string. If the DID provided does not match the DID of the camera, the validation routine will error out, but since the camera’s DID is provided in the MSG_LAN_NOTIFY response, this is a non-issue.

After DID validation, the big buffer is then passed as an argument to the tnp::gNoticeToCallback function pointer, which is only written once, appropriately to the notice_callback function. Interestingly, the only things the notice_callback function does is look at [buffer+0x20] and strcmp it against “TurnOff” and “TurnOn”. If either of these strings is found, it calls p2p_set_power, which switches the camera feed to that state, allowing one to render the camera feed unavailable to the owner of the camera. While the camera itself is still on, and can be switched back on from the owner’s Yi Home application, it is trivial for an attacker to send these MSG_NOTICE_TO packets in a loop, causing the camera’s feed to stay permanently off, rendering it completely useless.

It should be noted that there are other available code flows to call p2p_set_power that also require some sort of authentication, so it is theorized that the MSG_NOTICE_TO opcode is an artifact piece of code that should probably be removed.

Timeline

2018-06-13 - Vendor disclosure
2018-09-03 - Vendor patched
2018-10-31 - Public release

Discovered by Lilith (>_>) of Cisco Talos.