DisConnecting the August Connect

Venera (CVE-2018–20100), was an unpatched attack on the August Connect setup that allows nearby attackers to snoop Wifi credentials.

August is an IOT company offering a myriad of home security products. Its core product is the Smart Lock, which is installed on an existing deadbolt and allows full control of the doorknob via Bluetooth. Users download the August app, pair the device and subsequently lock and unlock the door automatically when within range. The August Connect is a supplementary device acting as a bridge between the Home Wifi network and the Bluetooth lock. Via the Connect users can monitor and control their lock from anywhere over the internet.

August Connect

August Smart Lock

The August Smart Lock has been thoroughly researched. Jmaxxz presented a “guest to permanent admin” vulnerability in the cloud interface in DC24 (2016), while MIT published a reasonably detailed security assessment in 2017. However, there is little on the web concerning the Connect, so it is a good candidate to target.

One of the major attack surfaces is the Wifi setup process. Schematically, the Connect is plugged in to a power supply in range of the Smart Lock, then the setup button is pressed, after which a green light starts flashing. A configuration access point called “August Connect-<SERIAL#>-WAC” is set up and found by the app. Finally, the user selects the desired Wifi network, specifies the password and completes the setup. Once Connect gains internet connection it is automatically paired to the user via the August cloud.

At this point it seemed reasonable to further understand how Wifi credentials are passed. Sniffing on a rooted Android is a piece of cake:

Looking at the /secure/network HTTP post we see an 80-byte obviously encrypted blob:

At this point the standard course of action is whipping out the APK source code and finding the relevant packet builder. Before long we find the incredibly self-explaining AugustWifiDevice class with the following snippets of code:

Ciphertext constructor method

Building, encrypting and sending the JSON object

So we can gather that a JSON object is built, containing the Wifi SSID and password. It is encrypted via the result of getKey(augDeviceType) using AES encryption in CBC mode with PKCS7 padding (Java cipher names are painfully misleading). A random 16 byte IV is generated and prepended to the ciphertext. Let’s find out what getKey does:

Just a wrapper to zzy()

KEY defined as constant

A futile attempt to make decryption a little less obvious

So August really dropped the ball here. The key is simply a constant value de-obfuscated by transforming the “n-z” character range to “a-m”.

Deriving the plain encryption key

So now we have all that we need to decrypt the packet, and indeed:

Decrypting the JSON object

So at this point we can conclude that anyone with a monitor-mode Wifi chip and decent reception should be able to snoop Wifi credentials. Well played, August, well played.

Now we tried going for a more reliable attack — joining the access point and ARP spoofing the Connect and smartphone before the POST is sent. While this seemed very promising, we soon found out Connect segments between connected devices at layer 2. DHCP and ARP broadcasts don’t make it to the victim phone so we can’t poison it. A surprisingly clutch isolation for an otherwise defenseless open access point.

Eventually we went with a different attack flow. First, we scan for the open August network and connect to it. We send it the network SSID and password of a network we know, making it connect to the internet and therefore releasing its hosted network. At this point we raise our own AP, mimicking the real network SSID. Now all that is left is to listen on port 80 for the HTTP POST and decrypt it. The app will identify the pairing was not successful and will instruct the user to press the setup button again, so it is unlikely the user will suspect of anything.

This is what the victim seems when connected to our rogue AP:

And this is the execution of the attack from shell:

We called the attack Venera as a reference to a series of soviet space probe sent to gather data from Venus, the August source code name for Connect. It is important to note that although we did not take a look at the August Doorbell, from the app code it seems the same exact attack would work on sniffing Doorbell configuration as well. It is simply a matter of changing the hardcoded encryption key.

August Response:

On 14/12, August acknowledged the vulnerability and stated a patch will likely not be ready for the publication timeline. The following advisory was asked to be sent to its users:

“In your publication please note that the suggested workaround is to do the Connect WiFi setup using an IOS device. This will use WAC instead of the preshared key and should be more resistant to a targeted attack.”

We leave the question of whether it is reasonable to ask customers with Android to use iOS for security to the reader.

Mitigations:

There are many ways to secure the Wifi credentials transfer. Ideally the app would send credentials over SSL with the app verifying the device’s certificate is signed by August. Preferably each device will contain its own public-private key pair to prevent attackers from extracting keys in their lab. Patching existing Connect is a major issue since they do not ship with a key to verify their identity, so perhaps dropping the access point signal power will aid in stopping attackers outside the home. In our tests the AP signal was alarmingly strong. Above all, companies must accept the fact that their products will be picked and torn apart and cannot assume client side hard-coded values provide any real security.