Athom Homey Security Review | Transmits unencrypted WiFi credentials (CVE-2020-9462)

---

TL;DR: All Athom Homey and Athom Homey Pro devices, up to the current version (v4.2.0) transmit their initial configuration in the clear which includes your WiFi password. At the time of writing, Athom have no plans to fix this.

---

I will preface this with the fact that this vulnerability is not the most exciting in history, however, it is a vulnerability and the company should be doing better. The Athom Homey device is a smart-hub and can connect with other devices using a lot of different protocols.

In principle, the device is great as it means you should only have one place to orchestrate your smart home.

Despite it’s flaws, I actually really like this device.

Essentially, when setting up the device it has to connect to your WiFi network. The device has no exposed Ethernet port which is a shame, but, on the most part, this doesn’t seem to be a problem.

Athom Homey Security Vulnerability

The vulnerability only exists when going through the setup routine. The vulnerability exists because the device creates a temporary WiFi hotspot that is unencrypted which the user must connect to in order to perform the initial configuration. Crucially this means that when you configure the devices WiFi connection, you send the WiFi password in an unencrypted link to the device.

I sent Athom an email which contained the following:

The security vulnerability I wish to report to you today is the fact
that during sign up, your devices receive the WiFi security key without
being protected by any form of encryption. This means that an attacker
who is physically within range would be able to receive a copy of the
encryption key and therefore be able to gain unauthorised access to the
victim’s WiFi network. This is the same vulnerability that Amazon’s Ring
Doorbell made international news about in November 2019:

Read more about ring doorbell WiFi vulnerability

Which got the following response:

Thank you for your effort and letting us know your findings!

We are aware of the security risk involved in sending the credentials in plain text during setup of Homey.

We have made the decision back when this feature has been designed that while the process is in theory insecure, in practice it has a very low risk attack vector. In fact, there are many smart devices that use a similar way to set-up said devices.

Because the user must manually enable Wi-Fi Setup on Homey by turning it physically upside down, and another hacker must be present at the same time with equipment that’s not available to most, we have decided to focus our security efforts on more pressing matters. I am happy to say that 3rd party penetration tests have been performed on Homey and no one was able to gain access.

On a technical note, there is no secure way to set-up devices over a Wi-Fi hotspot without an out-of-band key. Homey does not have this printed in a manual, sticker etc. so we cannot simply issue an update. All other mechanisms are by definition unsafe because they rely on a shared secret, which is always crackable for any determined hacker.

We take the security and privacy of our users very seriously.

Not a bad response, though it got me to thinking…

It is true that other devices use a similar WiFi configuration routine, but, as demonstrated by Amazon’s Ring, it isn’t considered good enough on those devices either. It is also true that devices using completely different protocols, such as ZigBee, also have a similar type of key-exchange flaw. Again, it isn’t considered good enough here either.

I also don’t think it is fair to suggest that this configuration process only happens once. I’ve had this device for a while and I use it a fair bit and during that time I have ended up having to reset it and reconfigure it.

Nevermind that, but, it doesn’t take much to realise that an attacker could easily create a circumstance that would encourage the victim user to start this reconfiguration process even when it wasn’t needed.

So I sent them another email:

Thank you for your response an, but I respectfully disagree.

There are methods in a closed ecosystem to perform key exchange. For example, the software on the Homey could be instructed to use knowledge of an Athom internal Root Certificate Authority to perform Homey to Smart-phone authentication, and the user’s smart-phone could be issued with an identity that is cryptographically derived from Athom’s internal CA and as such can be trusted by the device.

This then provides encrypted comms between Homey and the Smart phone which is already a big step-up. In theory though, this could be subjected to a Man-in-the-Middle attack. For example, where another user with a legitimate certificate could trick the victim Homey and the victim smart-phone into communicating with the attacker. To prevent this circumstance it would be best to have mutual authentication, but that is very difficult to achieve with devices that have already been deployed. There is a solution though – either Diffie Hellman key exchange (DH KX) which reveals an active attacker the moment they stop intercepting communications, or a variant of DH KX called STS (Station to Station)…

Furthermore, the Homey does have the ability to perform out of band key validation – amongst other methods, it speaks! This would allow key exchange and validation to be completed in the same manner as Bluetooth key exchange is completed with a PIN number.

I’m also worried about your analysis of the risk involved – just because this only happens during setup and that there must be user interaction does not make it immune to problems. For example, it is perfectly possible for an active attacker within RF range to perform a de-authentication attack against the device until the user chooses to reset it. Granted that when calculating its CVSS, having user interaction does reduce the score, but, I would suggest the result is still relatively high at approximately 5.0, with a vector of CVSS:3.0/AV:L/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N. This is owing to the ability of the attacker to not only intercept the communications which reveals the WiFi network key that in turn changes the scope of the attack, but also, because there is also the possibility of an integrity issue, such that at attacker could get the Homey device to connect to a malicious WiFi network and thus be able to perform other attacks against the device.

And finally, I don’t consider your assertion that “other people do this too” an adequate defence to your own lack of security. Just because it is done elsewhere does not make it right.

Please reconsider your position. I would be delighted to be of further help.

They were gracious enough to send me another response:

I do agree with some of the points you make, however, at this time we do not have the capacity to change Homey’s behavior during Wi-Fi setup. While you are technically right, we deem the attack vector to be small enough to be acceptable.

In any future products we will consider your findings.

As of this date, no fix for this is in place which is disappointing. You can find The official CVE for this issue by clicking here:

Learn how YGHT can help you imrpove your cybersecurity