Did You Remove That Debug Code? Netatmo Weather Station Sending WPA Passphrase in the Clear

Published: 2015-02-12
Last Updated: 2015-02-13 11:59:27 UTC
by Johannes Ullrich (Version: 1)
7 comment(s)

(BTW: it looks like the firmware update released this week by netatmo after reporting this issue fixes the problem. Still trying to completely verify that this is the case)

I have the bad habit of playing with home automation and various data acquisition tools. I could quit any time if I wanted to, but so far, I decided not to. My latest toy to add to the collection was a "Netatmo" weather station. It fits in nicely with the aluminum design of my MacBook, so who cares if the manufacturer considered security in its design, as long as it looks cool and is easy to set up.

Setting up the device was pretty straight forward, and looked "secure". It requires connecting to the device via USB, and a custom application is used to configure the device with your username, password and WiFi settings including the WiFi password. After the initial setup, the station needs USB for power only, and communicates via WiFi to the "Cloud".

But after the simple setup, a nice "surprise" waited for me in my snort logs:

 [**] [1:1000284:0] WPA PSK Passphrase Leak [**] [Priority: 0] {TCP} a.b.c.d:21908 ->

I do have a custom rule in my snort rule set, alerting me of the passphrase being sent in the clear. Lets just say that it happened before. The rule is very simple:

alert ip any any -> any any ( sid: 1000284; msg: "WPA PSK Passphrase Leak"; content: "[Iamnotgoingtotellyou]"; )

So what happened? After looking at the full capture of the data, I found that indeed the weather station sent my password to "the cloud", along with some other data. The data include the weather stations MAC address, the SSID of the WiFi network, and some hex encoded snippets.

Not only should data like this not be transmitted "in the clear", but in addition, there is no need for Netatmo to know the WPA password for my network. 

I reported the problem to Netatmo, and got the following reply:

Indeed at first startup we dump weather station memory for debug purposes, we will not dump it anymore.
We will remove this debug memory very soon (coming weeks).


So far I haven't seen any additional transmissions from the weather station containing the password, even after restarting it. I didn't do a full factory reset yet. But in general, the data appears to be unencrypted. The MAC address of the station and the outdoor sensor are easily found in the payload. So far, I couldn't find a documentation for the protocol, so it will take a bit more time to reverse it.

According to the weather station map provided by Netatmo, these devices are already quite popuplar. Here a snapshot of the map in my "Neighborhood":

Johannes B. Ullrich, Ph.D.

Keywords: debug iot netatmo
7 comment(s)


So this "High Tech" weather station is still using low tech encryption? Hummm.... Dr. "J" you play with some odd toys! :o
Feb 13 : Netatmo weather stations no longer send debug information at installation time. Thanks for reporting this.
I have this message from Netatmo support after inquiring about this issue:

This morning, at 6:54 AM, EST.


Thank you for your email. Netatmo weather stations no longer send debug information at installation time.

Nathalie - Netatmo

So--they believe it is fixed...
Yes. this has been fixed as of Firmware Version 101 (for the 'indoor module'). CVE-2015-1600 was assigned to this vulnerability. The firmware update will happen automatically without user interaction via Netatmo's cloud service.
Nice catch! I was curious about your snort/ids/security setup. If it's not a secret, it might be great for a topic some rainy day.
Hey, nice find, do you know, if they fixed the unencrypted data transmission as well? (i mean the weather/temp/co2/humidity/noise data)
Has anyone tried to dump the outdoor remote sensor which has the ability to both tx and Rx to do a lateral wifi password grab from the base station?

Diary Archives