Hard-coded smart-lock application credentials

1. Summary

The Chirp Access Android application ships with a hard-coded BEACON_PASSWORD embedded in the distributed APK. Because the credential is compiled into a publicly downloadable client, anyone can recover it by decompiling the app, and the secret is shared across the deployed fleet rather than being unique per device or per installation. An attacker who is within Bluetooth Low Energy (BLE) radio range of a Chirp beacon can present this recovered credential to change the beacon’s configuration — for example, disabling the proximity-notification behavior that the app relies on. The flaw is a use-of-hard-coded-password weakness (CWE-259) affecting versions before 1.26.0.

2. Affected products & versions

3. The vulnerability in detail

The defect lives in the Chirp Access Android client itself, not in any server-side component or in the lock/door hardware. Chirp Systems builds a smart-access ecosystem for multifamily residential properties, in which resident-facing mobile apps communicate with BLE beacons that mediate access-control behaviors such as proximity unlock and notifications. To let the app authenticate to, and manage, those beacons, the application carries a credential named BEACON_PASSWORD. The root cause of CVE-2024-2197 is that this credential is hard-coded into the shipped application binary rather than provisioned dynamically, stored in a protected keystore, or made unique per device or per user [1][4]. In other words, the same static secret is baked into every copy of the app that every resident downloads from the public app store.

This is a textbook instance of CWE-259, “Use of Hard-coded Password.” The essential problem with a hard-coded password is that the “secret” is not actually secret: any party who can obtain the software can obtain the credential. A password only provides a security boundary when the defender controls who knows it; once it is embedded in client software that is freely distributed, the attacker population is effectively “everyone who can download the app.” Worse, because the credential is shared fleet-wide, compromising one copy compromises the authentication factor for the entire install base — reported at roughly 50,000 units — and there is no per-tenant blast-radius containment [4]. Rotating the secret is not a config change; it requires shipping a new build to every client, which is precisely why the recovery path (below) carries a recall-class cost.

The mechanism of extraction is straightforward and requires no privileged access to Chirp infrastructure. Researcher Matt Brown obtained the public APK for a version prior to 1.26.0 and decompiled it — a routine reverse-engineering operation on Android packages — to recover the BEACON_PASSWORD string directly from the app’s code/resources [4]. No server compromise, no interception of live traffic, and no insider access is needed; the secret is simply present in an artifact that Chirp itself publishes.

The exploitation chain, as substantiated by the authoritative advisory record, proceeds as follows [1][4]:

1. Obtain the public Chirp Access APK for any version before 1.26.0.
2. Decompile the APK to recover the embedded BEACON_PASSWORD.
3. Move within BLE radio range of a target Chirp beacon (BLE is a short-range radio protocol, on the order of tens of meters).
4. Authenticate to the beacon using the recovered shared credential and rewrite its configuration — notably disabling the proximity-notification behavior.

Critically, the reachable effect of this credential is bounded. The authoritative sources are consistent that the recovered BEACON_PASSWORD governs beacon configuration and broadcast/notification behavior — not the door-unlock mechanism itself. NVD’s revised description and the vendor’s advisory both characterize the impact as an attacker within Bluetooth range changing beacon configuration and disabling proximity notifications, with no ability to unlock a door, gate, or lock [1][3][5]. The vendor states explicitly that the flaw affects only Bluetooth beacon broadcast distance/notifications and is “unrelated to the separate unlocking mechanism” [3].

There is an important, unresolved dispute embedded in this history. The vulnerability was originally scored as critical (CVSS ~9.1) on the theory that it enabled remote unlocking of residents’ locks via a separate “August” API path [6]. After further review, CISA revised the advisory (Update C), retracted the remote-unlock claim, and downgraded the vector to Adjacent with only low integrity impact [2][5]. The original researcher, Matt Brown, disputes this downgrade and continues to argue that residents could be remotely unlocked [4]. This review carries the revised framing as the primary technical position, because it is the one reflected in the current NVD record and the CISA advisory of record, while flagging the dispute explicitly.

4. Discovery & timeline

• The vulnerability was discovered by security researcher Matt Brown (an AWS engineer, researching independently) via decompilation of the Chirp Access Android APK [4].
• Brown disclosed the issue in March 2021 — roughly three years before it reached public warning [4].
• The vendor (Chirp Systems, owned by RealPage / Thoma Bravo) was unresponsive to the disclosure and to CISA [2][4].
• April 2024: CISA issued an ICS advisory (ICSA-24-067-01) publicizing the issue; it was initially framed as a critical remote-unlock vulnerability [6].
• April 22, 2024: CISA revised the advisory (Update C), downgrading severity and retracting the remote-unlock claim, alongside the vendor’s statement that the flaw could not be used to gain physical access [5].
• The vendor advisory confirms the fix ships in Chirp Access 1.26.0 [3].

5. Technical reference

• CVE: CVE-2024-2197 [1]
• CWE: CWE-259 — Use of Hard-coded Password [1][2]
• CVSS v3.1: 4.3 (MEDIUM) — vector AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N [1]
• AV:A (Adjacent) is the load-bearing metric here: exploitation requires BLE radio proximity, not network-remote reach. This single change from the original AV:N framing is what collapsed the score from critical to medium.
• PR:N/UI:N: no privileges and no user interaction are needed once in range, because the credential is universally recoverable.
• C:N/I:L/A:N: no confidentiality or availability impact, and only low integrity impact — reflecting bounded beacon-config tampering (disabling proximity notifications), not device takeover.
• CVSS v4.0: 2.3 (LOW) [1] — the newer metric set scores the bounded, proximity-gated impact even lower.
• Affected versions: prior to 1.26.0; fixed: 1.26.0 [1][3].
• Code/commit refs: none public; the defect is an embedded string in the closed-source APK, recovered by decompilation [4]. No commit-level fix reference is available.
• Advisory of record: CISA ICSA-24-067-01 (Update C) [2].

6. Consequence & CFSE path analysis

Real-world consequence: An attacker standing within roughly 30 meters of a Chirp beacon, armed with a credential trivially extracted from the public app, can reconfigure that beacon — for instance disabling proximity-unlock notifications. This is a bounded tampering effect on the beacon’s advertised behavior. It does not, per the current advisory record, unlock doors or grant physical entry. The disputed higher-impact claim (remote unlock) was retracted by CISA/NVD.

Why the CFSE Path Score diverges from CVSS: CVSS collapses this into a single medium/low base score dominated by the Adjacent attack vector and low integrity impact. The CFSE path decomposition instead reasons about the credential’s authority and its safety/recovery consequences as separate terminals, which surfaces risk that a single CVSS number hides — chiefly the fleet-wide, shared-secret nature (SR:4) and the recall-class remediation burden (OR:4), neither of which CVSS base metrics capture.

Carried CFSE bands / verdict from seed:

Verdict: HIGH. The entry decomposes the vulnerability into two co-dominant risk paths, both banded HIGH, yielding an overall path_verdict of HIGH. The ACCOUNT_AUTHORITY path (authority family) reasons that the hardcoded BEACON_PASSWORD (CWE-259/798) is trivially extractable from the public Chirp Access app and is a shared, fleet-wide credential (SR:4), but its reachable authority is bounded to beacon/back-end configuration functions rather than fleet administration or firmware-signing root (AT:2). The DEVICE_CONTROL_SAFETY path (safety family) reasons that turning the credential into effect requires BLE proximity (~30m), producing bounded beacon reconfiguration such as disabling proximity-unlock notifications, with no confirmed remote door unlock or severe physical harm (PH:2). Both paths carry recall-class recovery uplift (OR:4) because remediation requires an app/firmware update to rotate the embedded secret across the install base and the vendor was unresponsive. The entry explicitly excludes the initially alleged remote-unlock claim, noting it was retracted after CISA/NVD revised the vector to Adjacent (AV:A, I:L). The overall verdict is HIGH, driven co-dominantly by the account-authority and device-control-safety terminals.

The gap between the LOW/MEDIUM CVSS and the HIGH CFSE verdict is therefore not a disagreement about the immediate technical impact of a single exploitation — both agree it is bounded and proximity-gated. It is a disagreement about systemic posture: a shared, un-rotatable secret across ~50,000 units, remediable only by pushing a new build to the entire fleet, with an unresponsive vendor, is a HIGH-severity program-level condition even when any one exploitation is modest.

7. Remediation & mitigations

• Apply the fix: upgrade Chirp Access to 1.26.0 or later, which removes/rotates the hard-coded BEACON_PASSWORD [1][3]. This is the only real remediation, because the secret is baked into the client and cannot be revoked server-side without a client update.
• Fleet rollout is the hard part: because the credential is shared across the install base, the fix is only effective once every client (and any dependent beacon config) has been updated. Partial rollout leaves the shared secret extractable from any un-updated APK still in circulation. Operators managing Chirp deployments across properties should track update coverage across their entire fleet, not per-tenant.
• Proximity as a natural limiter: exploitation requires BLE range (~tens of meters). Physical-proximity controls around beacon locations are a partial compensating control while updates propagate, but they do not address the root shared-secret problem.
• Vendor-responsiveness caveat: the disclosure history shows a multi-year gap and an unresponsive vendor [2][4]; operators should not assume silent auto-remediation and should verify the deployed app version directly.

(No generic SOC boilerplate applies: there is no network signature to alert on for a passive decompile, and the on-device action is a legitimate-looking BLE beacon-config write.)

8. Sources

[1] NVD - CVE-2024-2197 — NVD / NIST — https://nvd.nist.gov/vuln/detail/CVE-2024-2197 — Authoritative CVE record with the revised scoring (CVSS v3.1 4.3 AV:A...I:L, v4.0 2.3), CWE-259, affected versions <1.26.0, and the bounded beacon-reconfiguration description. Credibility: primary advisory.

[2] Chirp Systems Chirp Access (Update C) | CISA ICS Advisory ICSA-24-067-01 — CISA / ICS-CERT — https://www.cisa.gov/news-events/ics-advisories/icsa-24-067-01 — Canonical government advisory of record; documents CWE-259 hard-coded BEACON_PASSWORD, the Update-C downgrade retracting the remote-unlock claim, credit to Matt Brown, and vendor non-response. Credibility: primary advisory.

[3] CVE-2024-2197 | RealPage security advisory — RealPage (Chirp Systems parent) — https://www.realpage.com/support/security/responsible-disclosure/security-advisories/cve-2024-2197/ — Vendor advisory confirming the hard-coded BEACON_PASSWORD before 1.26.0, the fix version, and the vendor’s framing that the flaw affects only beacon broadcast/notifications and is unrelated to unlocking. Credibility: primary advisory.

[4] Crickets from Chirp Systems in Smart Lock Key Leak — Krebs on Security — https://krebsonsecurity.com/2024/04/crickets-from-chirp-systems-in-smart-lock-key-leak/ — Investigative writeup of Matt Brown’s decompilation discovery, the March 2021 disclosure timeline, his dispute of the downgrade, the RealPage/Thoma Bravo context, ~50,000 affected units, and vendor unresponsiveness. Credibility: reputable press.

[5] US government downgrades bug in Chirp Systems app that contained hardcoded password — TechCrunch — https://techcrunch.com/2024/04/22/cisa-chirp-systems-remotely-unlock-smart-locks/ — Documents CISA’s downgrade and retraction of the remote-unlock claim, the revised limited impact, and Chirp’s statement that it could not be used to gain physical access. Credibility: reputable press.

[6] CISA warns of critical vulnerability in Chirp smart locks — The Register — https://www.theregister.com/2024/04/15/critical_vulnerability_chirp_lock/ — Coverage of the initial critical-severity warning (pre-downgrade), capturing the originally alleged remote-unlock framing and disclosure/vendor-silence background. Credibility: reputable press.