Hard-coded-key Wi-Fi password disclosure

1. Summary

The August Connect Wi-Fi Bridge and its Android companion app (August Home) hand off the user’s home Wi-Fi credentials to the bridge over an unencrypted access point during initial provisioning, protecting the payload with AES/CBC encryption whose key is hard-coded into the app and only obfuscated with ROT13. Because the key is static and shared across the product line, an attacker within Wi-Fi range of the setup process can capture the encrypted payload and decrypt it using the recovered key. The result is disclosure of the home Wi-Fi network password in plaintext, giving the attacker a foothold on the victim’s local network. The flaw does not permit unlocking the paired smart lock.

2. Affected products & versions

3. The vulnerability in detail

The August Connect Wi-Fi Bridge is a small plug-in gateway that gives the August Smart Lock Pro remote connectivity. The lock itself has no internet radio; it speaks Bluetooth Low Energy (BLE) to the bridge, and the bridge relays to August’s cloud over the internet. That cloud-facing channel is, importantly, built correctly: bridge-to-server traffic runs over TLS with certificate pinning, and the account layer uses two-factor authentication so that only the owner can fully control the lock [4]. The vulnerability does not live there. It lives in a completely different and much weaker path — the one-time credential handoff that happens when the bridge is first provisioned [3][4].

The flaw’s root cause is the use of a hard-coded cryptographic key (CWE-798 per NIST; CWE-321 per Bitdefender) [1]. During “initial device configuration,” the Connect bridge cannot yet reach the internet because it does not yet know the home Wi-Fi credentials — so it bootstraps by creating its own OPEN, unencrypted Wi-Fi access point [4]. The owner’s phone joins that open AP, and the app pushes the home Wi-Fi SSID and password to the bridge so the bridge can subsequently join the home network on its own. Because that channel is unencrypted at the Wi-Fi layer, anything transmitted across it is visible to any device within radio range that is listening [4].

The designers were aware the channel was open, and they attempted to compensate at the application layer: the app encrypts the credential payload with AES in CBC mode before sending it over the open AP [4]. This is where the defect turns a reasonable-sounding mitigation into no mitigation at all. The AES key is not negotiated, not derived from any secret shared only between the two legitimate endpoints, and not unique per device. Instead, the app carries the key inside its own code, selecting a constant string by device type and applying ROT13 to “deobfuscate” it into the working AES key [4]. ROT13 is a trivial letter-rotation cipher with no key and no security value; it is an obfuscation speed bump, not encryption. Anyone who extracts the constant from the Android APK and reverses the ROT13 recovers the exact AES key the app uses [4]. And because that key is static and fleet-wide — the same key ships to every install of the app for a given device type — recovering it once compromises the provisioning payload of every device in the field [1][4].

The mechanism and trigger are straightforward. The precondition is proximity: the attacker must be within Wi-Fi/RF range (adjacent-network) of the home while the bridge’s open AP is live and the phone is transmitting the credential payload during setup [1]. No account, no authentication, and no credentials of any kind are required — the attacker never touches August’s cloud or the lock account. The step-by-step exploitation chain is [3][4]:

1. The attacker positions within Wi-Fi range of the target home during — or forces — the August Connect provisioning window.
2. The bridge stands up its OPEN access point and the victim’s phone joins it to hand over the home Wi-Fi credentials.
3. The attacker passively sniffs the open-AP traffic and captures the AES/CBC-encrypted credential payload.
4. The attacker extracts the ROT13-obfuscated key constant from the Android app (selected by device type) and applies ROT13 to obtain the static AES key.
5. The attacker decrypts the captured AES/CBC ciphertext with that key, recovering the home Wi-Fi password in plaintext.
6. The attacker joins the home Wi-Fi network and can pivot to other devices on it. Critically, this flaw does NOT grant the ability to unlock the door [3].

A key nuance concerns the size of the exposure window. August argued the device is only vulnerable during setup and is no longer vulnerable once fully configured, and that an attacker would need to know precisely when setup occurs [5]. Bitdefender rebutted this by demonstrating a technique to force setup to happen on demand, meaning an attacker need not wait for an organic provisioning event — the vulnerable window can be induced [5]. Note also that only the Android app is affected; the iOS app is not, which the vendor attributed to Apple’s platform security and Bitdefender confirmed [5].

Bitdefender’s whitepaper documents the full workflow — open-AP capture, ROT13 deobfuscation, and AES/CBC decryption — and states the team could force setup on demand [4].

4. Discovery & timeline

The vulnerability was discovered by the Bitdefender IoT Vulnerability Research Team as part of a research series conducted in partnership with PCMag; Bitdefender is the assigning CNA [4][5]. The coordinated-disclosure timeline [4][5]:

• Dec 9, 2019 — initial vendor contact, PGP keys exchanged.
• Dec 10, 2019 — report sent in advance.
• Dec 18, 2019 — information re-sent, vulnerability confirmed, and CVE-2019-17098 reserved by Bitdefender.
• Jan 16, 2020 — Bitdefender requests a status update.
• May 11, 2020 — vendor requests coordinated public disclosure scheduled for early June 2020.
• Jul 2, 2020 — Bitdefender requests another update.
• Aug 6, 2020 — report becomes public after the vendor did not respond (per whitepaper); PCMag article publication cited as Aug 11, 2020.
• Sep 30, 2020 — NVD publishes CVE-2019-17098.

Disclosure spanned roughly eight months, nearly triple the standard 90-day window [5]. The vendor acknowledged the issue and said it was “currently working to resolve” it; no fixed version is documented in the sources [5].

5. Technical reference

• CVE: CVE-2019-17098 [1][2]
• CWE: CWE-798 (Use of Hard-coded Credentials, NIST) / CWE-321 (Use of Hard-coded Cryptographic Key, Bitdefender) [1]
• CVSS v3.1 (NIST): 6.5 MEDIUM — AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N [1]
• CVSS v3.1 (Bitdefender CNA): 3.5 LOW — AV:A/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N [1]
• CVSS v2.0: 3.3 LOW [1]
• Code/commit refs: none public. The specific hard-coded key value and device-type constant appear only as images in the whitepaper and are not text-extractable [4].

What the metrics mean here: the two published CVSS vectors diverge on two axes. NVD models AV:A (adjacent network — RF proximity), C:H (high confidentiality impact, treating the disclosed Wi-Fi password as a serious secret), and UI:N (no user interaction), yielding 6.5 MEDIUM. Bitdefender’s CNA vector keeps AV:A but sets UI:R (the victim must be performing setup) and C:L (low confidentiality impact), yielding 3.5 LOW. Both agree on PR:N (no privileges), I:N and A:N (no integrity or availability impact). The disagreement over UI is materially weakened by Bitdefender’s own demonstration that setup can be forced on demand.

6. Consequence & CFSE path analysis

Real-world consequence: an attacker within Wi-Fi range during (or forcing) the bridge’s provisioning window recovers the victim’s home Wi-Fi password in plaintext. That password is a reusable, sensitive secret — not one-shot telemetry — and once known it grants the attacker persistent access to the home network, from which they can enumerate and attack other devices (cameras, NAS, PCs, other IoT). The consequence is a network-access breach and a bridgehead for lateral movement, not lock compromise: the flaw explicitly does not let the attacker open the door [3].

Why the CFSE Path Score differs from CVSS: CVSS collapses this into a single confidentiality metric and lands at 6.5 MEDIUM (NVD) or even 3.5 LOW (Bitdefender). The CFSE path analysis instead models the terminal consequence type and the credential’s downstream reusability, which surfaces risk that the CVSS scalar understates — hence the direction is UNDER relative to the 6.5 MEDIUM baseline.

Carried CFSE verdict from seed:

verdict: HIGH. The entry decomposes the vulnerability into a single risk path with terminal type DATA_PRIVACY, scored in the HIGH band and the dominant path. The path models an adjacent-network attacker (RE:2, Wi-Fi proximity during the provisioning window) who captures setup traffic, undoes the ROT13 obfuscation, and decrypts it with a hardcoded static AES key (EC:3) to recover the home Wi-Fi password in plaintext. The disclosed credential is treated as a reusable, sensitive secret (DP:3 / C:H) rather than ordinary telemetry, and as a cross-boundary bridge (CH:3) enabling lateral movement onto the home network and attacks on other devices, though authority is bounded (AT:2 — it does not grant lock control or admin authority) and there is no direct physical/safety actuation (PH:0). The static key is shared fleet-wide across the product line (SR:4), but each exploitation still requires per-device proximity and a live capture during setup (SX:2), and recovery needs a coordinated app/firmware update plus Wi-Fi password rotation (OR:3). Overall path_verdict is HIGH (direction UNDER relative to the published CVSS baseline of 6.5 MEDIUM), driven by the credential-disclosure privacy consequence with the privacy-only cap keeping it at HIGH.

7. Remediation & mitigations

Vendor-side (the actual fix required):

• Eliminate the hard-coded, ROT13-obfuscated AES key entirely. A static, fleet-wide key embedded in a client cannot provide confidentiality.
• Stop performing the credential handoff over an open access point, or protect it with keys negotiated over an authenticated/encrypted channel — the same class of protection the product already applies to its cloud path (TLS with certificate pinning) [4].
• Use per-device or ephemeral keys rather than a single shared constant, so recovering one key does not compromise the entire fleet.
• A complete remediation requires a coordinated app and firmware update. No official patched app or firmware version is documented in the sources [5].

User/operator-side (specific to this bug):

• Rotate the home Wi-Fi password after completing bridge setup — this directly invalidates any credential an attacker may have captured during provisioning.
• Provision the bridge in a controlled, RF-quiet environment (minimize the chance a sniffer is in range during the setup window).
• Apply any vendor app/firmware update once released.

No generic detection controls meaningfully apply: the capture is passive over an open AP and leaves no signal on the victim’s side.

8. Sources

[1] NVD — CVE-2019-17098 — NVD (NIST) — https://nvd.nist.gov/vuln/detail/CVE-2019-17098 — Authoritative CVE record: description, CWE-798/CWE-321, both CVSS vectors, affected versions, publish date. Credibility: primary advisory.

[2] CVE-2019-17098 — MITRE / cve.org record — MITRE CVE — https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2019-17098 — Canonical CVE assignment confirming vulnerability wording and affected product/version scope; Bitdefender named as assigning source. Credibility: primary advisory.

[3] Smart Locks Not So Smart with Wi-Fi Security — Bitdefender Labs — https://www.bitdefender.com/en-us/blog/labs/smart-locks-not-so-smart-with-wi-fi-security — Original researcher writeup establishing root cause (hardcoded/ROT13 key on the AES/CBC channel) and the “Wi-Fi access, not lock control” impact framing. Credibility: researcher-primary.

[4] Cracking the August SmartLock: WiFi Password Eavesdropping Made Easy (whitepaper) — Bitdefender — https://www.bitdefender.com/files/News/CaseStudies/study/363/Bitdefender-PR-Whitepaper-AugustConnect-creat4699-en-EN-GenericUse.pdf — Full technical whitepaper with the AES/CBC scheme, ROT13 static key, open-AP capture/decryption workflow, and disclosure timeline. Credibility: researcher-primary.

[5] Exclusive: August Smart Lock Flaw Opens Your Wi-Fi Network to Hackers — PCMag — https://medium.com/pcmag-access/exclusive-august-smart-lock-flaw-opens-your-wi-fi-network-to-hackers-e19b64ba4145 — Coordinated-disclosure media partner; documents the timeline, vendor response, Android-only claim, and the “force setup on demand” rebuttal. Credibility: reputable press.

[6] August Smart Lock security flaw gives hackers full access to your Wi-Fi network — Android Central — https://www.androidcentral.com/august-smart-lock-security-flaw-gives-hackers-full-access-your-wi-fi-network — Independent technical-press corroboration of the flaw scope (Wi-Fi access, not lock control). Credibility: reputable press.

[7] Smart-Lock Hacks Point to Larger IoT Problems — Dark Reading — https://www.darkreading.com/threat-intelligence/smart-lock-hacks-point-to-larger-iot-problems — Industry analysis placing the CVE in the broader pattern of hardcoded keys/weak obfuscation and non-remediation across IoT. Credibility: reputable press.