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
- 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;
- 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.
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
<ID> is the
uuid parameter obtained earlier. The payload must be in JSON format and must include the
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.
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
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 (
uid). After gaining access to the credentials, they can access the camera’s stored recordings.
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
Downloading and playing a recording for
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
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.
A Red Team Perspective on the Device42 Asset Management Appliance
August 10, 2022
Vulnerabilities Identified in Wyze Cam IoT Device
March 29, 2022
New FluBot and TeaBot Global Malware Campaigns Discovered
January 26, 2022
Bitdefender Honeypots Signal Active Log4Shell 0-Day Attacks Underway; Patch Immediately
December 10, 2021
Bitdefender, Law Enforcement Partnership Saves REvil Victims Half a Billion in Ransom Demand
November 08, 2021
Bitdefender Offers Free Universal Decryptor for REvil/Sodinokibi Ransomware
September 16, 2021