Vulnerabilities Identified in Nooie Baby Monitor

At Bitdefender, we care deeply about security, so we’ve been working with media partners and IoT devices manufacturers to identify vulnerabilities in the world’s best-selling connected devices. As one of the leading vendors of cybersecurity protection across endpoint and IoT devices, we have been assessing the security of smart-home equipment for more than half a decade. Our goal is to help vendors and customers stay on top of security and privacy blind spots and make the IoT ecosystem safer for everybody.

While looking into the Nooie Baby Monitor, we identified several vulnerabilities that could let an outside attacker access the camera feed or execute malicious code to further compromise the device.

Update (Apr 6, 2022): Nooie reached out to Bitdefender to confirm that a security fix for this issue has been released for the affected users.

Vulnerabilities at a glance

• Unauthenticated MQTT information leak
• Unauthorized access to the RTSPS stream
• Stack-based buffer overflow leading to remote code execution (CVE-2020-15744)
• AWS bucket access control missing

Vulnerability impact

• The Nooie Cam has 50,000-100,000 installs on the Google Play Store; installs on Apple Store are not public;
• Bitdefender researchers demonstrated remote code execution capabilities on two models; other models in the family may be vulnerable as well;

Disclosure Timeline

• Nov 02, 2020: Bitdefender makes first contact with vendor and asks for PGP
• Nov 20, 2020:  Bitdefender tries a second time to get in touch with the vendor
• Nov 23, 2020: Vendor acknowledges receipt and requests additional information
• Nov 27, 2020: Advisory and proof of concept are shared with the vendor
• Oct 25, 2021: Bitdefender follows up on patch progress
• Feb 3, 2022: Vulnerability information becomes public

Leaking device and user IDs from unauthenticated MQTT server

The camera uses the MQTT protocol to announce its status and receive a URL location to send the RTSPS stream to. The MQTT server is located at eu.nooie.com and listens on port 1883. The server does not require authentication. By subscribing to the /device/init topic, an attacker can obtain IDs for the devices that come online.

The uuid parameter is the camera ID, and the uid parameter is the user ID, the account that the camera is associated to.

Accessing the RTSPS feed of arbitrary cameras

During normal use, when the user requests access to the camera’s audio-video feed, the device will receive a destination where the feed would be uploaded. This destination is in fact the relay server that will resend the feed to the client - the user’s smartphone app. The destination URL is usually received through a HTTPS request, but the same functionality is also implemented through the MQTT service.

An attacker can connect to the MQTT server without authentication and send this command to arbitrary cameras, specifying a malicious server. The devices will then begin to upload their feed to an attacker-controlled server, allowing the attacker to view the live feed. This is achieved by publishing a message to the camera’s topic /device/<ID>/cmd, where <ID> is the uuid parameter obtained earlier. The payload must be in JSON format and must include the cmd and url parameters.

Note: the camera will begin sending the stream after a few minutes.

Stack-based buffer overflow leading to remote code execution

The function that processes the URL command received through the MQTT server is also vulnerable to a stack-based buffer overflow. It will copy the URL parameter in a 32-byte length variable on the stack without checking the length, leading to code execution.

By exploiting this overflow, we can replace the return address with the address of a gadget that calls system. The parameter for the system call is taken from the r11 register and placed in the r0 register. As r11 is controlled by the attacker, it will contain an address of a shell command string. The received url parameter is copied in a global variable with a known address that can be used to store the payload.

The second memcpy call requires a readable address as its source buffer. Fortunately, the stack has small variations of its start address and a significant size, which makes it a prime candidate for finding a valid address for the second argument of memcpy.

0xb29e6170 – guessed stack address

0x00167a74 – the payload address (note that the ‘c’ in the payload address will be replaced with a null byte)

0x0002584c – the address of the system gadget

- the command to be executed (max. 40 character with no ‘/’)

Final payload for Nooie Cam Indoor 1080P:

Obtaining AWS credentials for a specific camera

The camera uses the /rest/v2/device/get_awstoken endpoint on eu.nooie.com to obtain the AWS credentials used to store recordings on the cloud. These credentials are unique for each device. However, an attacker can easily spoof the camera and forge a request on its behalf and gain illicit access to the credentials. The only prerequisites are the IDs leaked on the MQTT server (uuid and uid). After gaining access to the credentials, they can access the camera’s stored recordings.

The uuid and uid parameters are those from above, appid is hardcoded, and the sign parameter is computed used the following algorithm:  hmacsha256(uuid + id + timestamp, base64(md5(uuid)).

Accessing the entire AWS bucket

The credentials received in the previous step allow access not only to the camera’s uploads, but to the entire bucket. This means an attacker can forge a request, get the credentials for a specific camera, then use them to access recordings from all the cameras.

Listing available recordings for uuid cfbfd219878ada6a81657e1c83412639:

Downloading and playing a recording for uuid cfbfd219878ada6a81657e1c83412639:

Appendix: Tested models and firmware versions

The vulnerabilities were found on the following firmware versions (other models might be affected):

• PC100A (Nooie Cam 360) – v1.3.88
• IPC007A-1080P (Nooie Cam Indoor 1080p) – 2.1.94

Mitigation

Home users should keep a close eye on IoT devices and isolate them as much as possible from the local or guest network. This can be done by setting up a dedicated SSID exclusively for IoT devices.

Additionally, IoT users can use the free Bitdefender Smart Home Scanner app to scan for connected devices, identify and highlight vulnerable ones. IoT device owners should also make sure that they check for newer firmware and update devices as soon as the vendor releases new versions.

To minimize risks of compromise, smart home users should consider the adoption of a network cybersecurity solution integrated into the router, such as the NETGEAR Orbi or Nighthawk routers powered by Bitdefender Armor.