Netatmo Welcome is a smart camera, which is capable of recognizing faces, streaming recordings into the cloud or alerting the owner in case of a burglary. As part of ongoing research into the Internet of Things security, we performed static and dynamic analysis of the Android and Linux app as well as of the camera itself.While cloud communication was found to be reasonably secure for an IoT device (there even is an IPsec mode for firmware updates!), we discovered a vulnerability, which enables an attacker to link his account to a camera that he were previously able to access. After this he can spy on the owner or even remove the owner from accessing his own camera. Netatmo fixed this vulnerability on February 2019.
Contents
- Security Analysis Summary
- Device Setup
- Android App
- Linux Setup Tool
- API
- Face detection
- Miscellaneous (FTP, hardware attacks, ...)
- Responsible disclosure
- Conclusion
- Update 4th February 2019
1. Security Analysis Summary
The Good:
- Cloud communication uses HTTPS and CA pinning
- IPSec for Critical traffic (firmware updates)
- Communication to Netatmo exclusively through the camera itself, not the App
The Bad:
- Some API Commands require (unchangeable) camera credentials
- Probably bad defaults (microphone on by default)
- No notification if new user is linked to an account
- Bad face detection
- Debug ports
2. Device Setup
The Netatmo Welcome comes in a sleek cylindrical button-less design.The device consists of one USB Port (which is used to power the device and for first setup), a microSD card slot (where the camera can store recordings), a multi color LED (green during power up, blue if in Bluetooth mode and red while it records (only when user activated this)). For connectivity, there is an Ethernet port, WiFi, and Bluetooth, while the later is only used/activated for communication between the App and the device in setup mode.
When plugged in, an unconfigured or freshly reset Netatmo Welcome will try to access the Internet. If it succeeds, it checks for firmware updates, then downloads and installs the update without asking.
To set up the camera the owner can either use a Smartphone App and connect to the camera via Bluetooth, by flipping it upside down. Or he can download a Windows/Linux/macOS binary to connect the camera via USB cable.
The camera itself can connect to the Internet via Ethernet or WiFi (the later one has to be configured during setup).
3. Android App
We examined the Android App for Netatmo Welcome, Netatmo Security in our MitM ready Android VM. To record network traffic mitmproxy was used. Bluetooth traffic can be intercepted within Android by enabling HCI Snooping under the developer options section. We intercepted a packet with our proxy which contained a device username as well as a device password. The interesting part of this is, that the password and username are actually static. Username is the MAC address of the camera and password is a device-specific hardcoded password.
4. Linux Setup Tool
We analyzed the Linux Setup tool with radare2 and strace but found nothing interesting (hardcoded passwords, hidden URLs etc.). The program must be run as root, though. Which is bad design, but not a vulnerability by itself. During the setup process the camera has to be connected via USB. Wireshark is able to sniff the USB traffic. After analyzing the packets we observed, that the camera sent the same device username and device password as the Android App before.
5. API
After obtaining the device username and password with one of the methods above, the attacker can then use those to create the following API request:
Request
POST /oauth2device/token HTTP/1.1
Host: app.netatmo.net
Connection: close
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded
Content-Length: 257
client\_id=na\_client\_linux&client\_secret=\*\*53c237...acce55\*\*&grant\_type=password&password=\*\*bada55h0tbabe...h0tc0ffee\*\*&username=70:ee:50:2e:13:37
Response
"access\_token":"70:ee:50:2e:13:37|OurAwesomeDeviceToken",
"expires\_in":10800,
"refresh\_token":"tGzv3JOkF0XG5Qx2TlKWIA"
Due to the fact that username and password are static, an attacker can repeat that API call, even if he does not own the camera anymore. The client_secret is not import for this call to get access.
The attacker could for example request a refund on the device, send it back where he bought it and wait for a victim to pick up this exact camera. Eventually, the camera will be sold again to our victim. The victim installs the camera and runs the setup, successfully binding the camera to his cloud account.
At this time the adversary reruns the request above, which will still return a valid token. The attacker then saves the returned token as access_token_device. He also creates his own Netatmo Cloud account using the Netatmo website. Afterwards, he asks for a user token using the following request:
POST /oauth2/token HTTP/1.1
Host: app.netatmo.net
Connection: close
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded
Content-Length: 156
client\_id=na\_client\_linux&client\_secret=\*\*53c237...acce55\*\*&grant\_type=password&password=supersecret&username=attacker%40softscheck.com
This request returns json data containing the user token "OurAwesomeUserToken".
Now the attacker can combine this two tokens to craft and send the following packet and get control over the camera:
POST /api/associatedevice HTTP/1.1
Host: app.netatmo.net
Connection: close
Accept-Encoding: gzip, deflate
Content-Type: application/x-www-form-urlencoded
Content-Length: 141
access\_token\_device=70:ee:50:2e:13:37|OurAwesomeDeviceToken&access\_token=OurAwesomeUserToken
This binds the camera to the attackers user account, allowing him to access the camera anytime he wants from the Netatmo cloud. The victim can still use the camera and the cloud interface, which increases the chance that the attack remains unnoticed. Meanwhile the victim does not receive a notification about the newly added account.
Here is a video of the attack in action:
It does not end here though, the attacker can now remove the owner from accessing the camera. The owner doesn't even receive a notification about being removed from accessing his own camera. So unless he opens the Netatmo App or webpage, he has no clue that he just got blocked out. A thief could go on like this:
- Bind the camera and spy on the habitants
- If everybody is away, remove their access to the camera
- Break in
6. Face detection
"Welcome does home security better thanks to revolutionary face recognition technology." -- https://www.netatmo.com/en-us/security/cam-indoor
In fact, the technology is pretty good at detecting faces, even if a person is crossing the camera angle in the next room some meters away. However, the camera is prone to false positives. The Cantina Band aliens from the video above are in fact detected as a face by the camera after a certain amount of time. The camera also isn't that good at matching faces to already known persons (but gets better after a learning period). A feature of the camera is the "thief" detection, which works like this: The inhabitants scan their faces with the camera. Then they log into the cloud website and name those recognized faces. When all of them set their status to away, the camera starts to send alerts to their smartphones if an unknown face gets detected. If an attacker is able to somehow trick Netatmo Welcome into believing that not a unknown person but one of the habitants came back home, he is able to break in without a notification being sent to the owners of the camera. If the privacy feature of the camera is enabled, it won't even record the thief.
We started by printing out our faces on a DIN A4 paper. This alone was enough for the camera to detect a new face. However, our goal was that we could trick the camera into believing that the printout was in fact us.
So we filmed one of our colleagues the whole day and identified the face the camera detected as him. This is important because the face recognition of the camera gets better the more samples you provide (learning phase). Then we made a hardcopy of the picture of our colleagues face, cutted it at the border of his face and showed it to the camera. The Netatmo welcome recognized the printout as his face, so our attack was successful.
This is bad, because the owner might have set the camera to "don't record me and don't send any notifications when seeing me", so the attacker can pass by undetected.
7. Miscellaneous
- Can upload to an FTP server - does not provide FTP code on its own
- Can store files on encrypted memory card
- Mainboard contains testports. Hardware based attacks might be possible.
- No open ports
- Power down when away, user WON'T get notified
8. Responsible disclosure
When contacting Netatmo about the security vulnerability, they told us that in fact the owner of the camera should receive an email when someone links the owners camera to their own account and therefore this is just a bug. In our opinion, even if the email notification would work, this is still a weak mitigation. A better solution would be to ask the owner to approve the linkage of the camera. Netatmo said they will consider it. This was four months ago. But at the release of this article, an attacker can still exploit the presented vulnerabilities. We will update this post if Netatmo fixes the vulnerability.
9. Conclusion
Getting the device username and password requires physical access to the camera at some point or a another vulnerability which allows the attacker to somehow read the username and password while they are in transit. In other words a man in the middle attack. If the attack somehow gains these information, though, this vulnerability is critical, as the attacker can completely control the camera. The next big problem is, even if the victim knows about this vulnerability and knows that someone has access to his camera, he can NOT stop the attacker from exploiting it. He can only send the camera back and buy a new device! The easy to trick face detection and the power cut attack make it easy to break in undetected, if the attacker knows the victim. However a person who bought a camera to protect himself from thieves is likely to also invest in security locks and glass. A thief might go for a low hanging fruit instead, instead of facing the risk.
10. Update 4th February 2019
Netatmo wrote back, stating that they have fixed the issue. If the camera is already bound to a account, calling /api/associatedevice now returns {"error":{"code":13,"message":"This device is in a home"}} On top of that the user, to which the camera belongs also gets an email, telling him who tried to get access to the camera, allowing him to invite this person. In our opinion this is a pretty good method of solving the issue, without taking away functionality.
In part 2 of our analysis, we looked at the hardware of the camera and found debug pins, which we used to gain root access. Part 2 can be found here
Read about other interesting topics on our blog.