Incident: Smart Lock Vulnerability Exposes Home Security Risks and Lack of Transparency

Published Date: 2016-08-25

Postmortem Analysis
Timeline 1. The software failure incident with August's first- and second-generation smart locks, as reported in Article 47041, happened in August 2016. [47041]
System 1. August's first- and second-generation smart locks 2. August's guest access feature
Responsible Organization 1. Jmaxxz, a software engineer, security expert, and white-hat hacker, who uncovered vulnerabilities in August's first- and second-generation smart locks [47041]. 2. August, the company responsible for the smart locks, which did not respond to the security issues with the expected transparency and promptness [47041].
Impacted Organization 1. August company [47041]
Software Causes 1. Vulnerabilities in August's first- and second-generation smart locks related to guest access, allowing guests to hack the software and enroll a new key, granting them control even after being removed as a guest [47041].
Non-software Causes The non-software causes of the failure incident mentioned in the article include: 1. Vulnerabilities in the physical design of the smart locks that allowed for unauthorized access [47041]. 2. Lack of transparency and communication from the company regarding the security issues [47041]. 3. Delay in issuing firmware updates to address the identified vulnerabilities [47041].
Impacts 1. The software failure incident with August's smart locks allowed guests to hack the software and enroll a new key, giving them control over the lock even after the homeowner removed them as a guest [47041]. 2. The incident raised concerns about the transparency of August in responding to the issues, as the company did not communicate clearly about the flaw and took time to fix it, leading to customer uncertainty [47041]. 3. The delay in fixing the vulnerability and lack of clear communication from August caused confusion among users and the public, highlighting the importance of prompt and transparent responses to software failures [47041].
Preventions 1. Conducting thorough security testing and audits before releasing the software to identify vulnerabilities [47041]. 2. Implementing a transparent and proactive communication strategy when security issues are discovered [47041]. 3. Releasing timely firmware updates to address identified vulnerabilities [47041].
Fixes 1. Implementing necessary firmware updates to address the vulnerabilities highlighted by the security researcher [47041]. 2. Enhancing transparency and communication with customers regarding security issues and fixes in a timely manner [47041]. 3. Conducting an independent review to confirm that the identified problems have been adequately resolved [47041].
References 1. Jmaxxz, a software engineer, security expert, and white-hat hacker who spoke at the Defcon technology security conference [47041] 2. August, the company behind the smart locks that were vulnerable to hacking [47041] 3. Steve Conaway, the Associate Technical Editor who was able to enroll a new key and control the August Smart Lock [47041] 4. Twitter users who reached out to August questioning whether the issues had been fixed [47041] 5. Johns Hopkins University Computer Science Professor and Information Security Institute Technical Director Avi Rubin [47041]

Software Taxonomy of Faults

Category Option Rationale
Recurring one_organization, multiple_organization (a) The software failure incident related to the August smart locks happened again at the same organization. After Jmaxxz uncovered vulnerabilities in August's first- and second-generation smart locks, the company patched most of the problems he found. However, it was mentioned that they still hadn't issued a firmware update to address all the issues highlighted by Jmaxxz [47041]. (b) The software failure incident related to the August smart locks also occurred with other organizations or their products and services. The article mentions various security vulnerabilities in different security systems, standalone cameras, and deadbolts, highlighting that the ability to hack or compromise security devices is a common issue across the industry [47041].
Phase (Design/Operation) design, operation (a) The software failure incident related to the design phase: The incident with August's smart locks highlighted vulnerabilities in the design of the guest access feature. The vulnerability allowed guests to hack the software and enroll a new key, giving them control over the smart lock even after the homeowner removed them as a guest. This flaw in the design of the guest access feature led to a potential security risk [47041]. (b) The software failure incident related to the operation phase: The failure in the operation phase was evident when the Associate Technical Editor was able to enroll a new key and control the August Smart Lock, showcasing a flaw in the operational functionality of the smart lock system. This operation-related failure was demonstrated through the ability to manipulate the system even after the guest access was removed [47041].
Boundary (Internal/External) within_system (a) The software failure incident related to the August smart locks can be categorized as within_system. The vulnerability discovered by Jmaxxz was related to the guest access feature of the smart locks, allowing guests to hack the software and enroll a new key, granting them continued access even after being removed as a guest [47041]. The issue was within the system's design and implementation, leading to unauthorized access and control of the smart locks.
Nature (Human/Non-human) non-human_actions, human_actions (a) The software failure incident occurring due to non-human actions: The software failure incident in the article was primarily due to vulnerabilities in August's first- and second-generation smart locks that were uncovered by Jmaxxz, a security expert and white-hat hacker. These vulnerabilities allowed guests to hack August's software and enroll a new key, giving them control over an August Smart Lock even after the homeowner removed them as a guest. The incident was not a result of human actions introducing vulnerabilities but rather due to inherent flaws in the software [47041]. (b) The software failure incident occurring due to human actions: The response to the software failure incident by August, the company behind the smart locks, involved human actions that influenced the handling of the situation. Despite the vulnerabilities being identified by Jmaxxz and replicated by others, August initially downplayed the issue and did not respond with the expected transparency. There were delays in fixing the problem, with Twitter interactions showing that the company was slow to address the backdoor issue and only fully resolved it on August 19 after public scrutiny. The incident highlighted the importance of timely and transparent communication from companies in response to software vulnerabilities [47041].
Dimension (Hardware/Software) software (a) The software failure incident occurring due to hardware: The article does not mention any specific hardware-related contributing factors to the software failure incident. Therefore, it is unknown if the software failure incident occurred due to hardware-related issues. (b) The software failure incident occurring due to software: The software failure incident in the article is primarily related to vulnerabilities in August's first- and second-generation smart locks. These vulnerabilities allowed guests to hack August's software and enroll a new key, granting them control over an August Smart Lock even after the homeowner removed them as a guest. The incident involved flaws in the software that enabled unauthorized access and control of the smart locks, highlighting software-related contributing factors to the failure incident [47041].
Objective (Malicious/Non-malicious) non-malicious (a) The software failure incident in the article is non-malicious. The vulnerability in August's smart locks, as highlighted by Jmaxxz, was not exploited for malicious purposes such as break-ins. The incident was more about identifying and addressing security flaws in the system rather than using them for harmful intent. [47041]
Intent (Poor/Accidental Decisions) poor_decisions (a) The intent of the software failure incident related to poor_decisions: The software failure incident related to the August smart locks vulnerability can be attributed to poor decisions made by the company in handling the security issues. Despite the vulnerabilities being highlighted by Jmaxxz, the company did not respond with the expected level of transparency and urgency. August downplayed the severity of the issue in their initial responses and delayed implementing necessary fixes promptly. This lack of proactive and transparent communication can be considered a poor decision on the part of the company [47041]. (b) The intent of the software failure incident related to accidental_decisions: The software failure incident does not seem to be related to accidental decisions or unintended mistakes. Instead, it appears to be more about the company's response to the identified vulnerabilities and the delay in addressing them effectively. The incident was not accidental but rather a result of the company's approach to handling the security flaws [47041].
Capability (Incompetence/Accidental) development_incompetence (a) The software failure incident occurring due to development incompetence: The incident with August's smart locks was primarily due to vulnerabilities in the software that were identified by Jmaxxz, a security expert and white-hat hacker. These vulnerabilities allowed guests to hack the software and enroll a new key, granting them unauthorized access to the smart lock even after the homeowner removed them as a guest. Despite the vulnerabilities being discovered, August initially downplayed the severity of the issue and did not respond with the expected level of transparency and urgency in fixing the problems. This lack of professional competence in addressing security vulnerabilities in the software led to concerns about the security of the smart locks [47041]. (b) The software failure incident occurring accidentally: The incident with August's smart locks was not accidental but rather a result of deliberate hacking attempts by Jmaxxz to identify security vulnerabilities in the software. The vulnerabilities were exploited to demonstrate how guests could enroll new keys and retain access to the smart lock even after their guest access was revoked. The incident was not accidental but a deliberate effort to highlight flaws in the software's security measures [47041].
Duration temporary (a) The software failure incident in the article was temporary. The vulnerabilities in August's first- and second-generation smart locks were uncovered by Jmaxxz, a security expert, through live demonstrations at the Defcon technology security conference. These vulnerabilities allowed guests to hack August's software and enroll a new key, giving them control over the smart lock even after the homeowner removed them as a guest. The company patched most of the problems uncovered by Jmaxxz, and as of August 19, no one could replicate them anymore. The incident was temporary as the vulnerabilities were fixed by the company [47041]. (b) The software failure incident was temporary as the vulnerabilities in August's smart locks were actively worked on by the company to fix the issues. Despite initial downplaying of the issue by August in statements to the press and on social media, they eventually acknowledged the problems and worked on deploying patches and updates to address the vulnerabilities. The incident was temporary as the company took steps to resolve the software flaws [47041].
Behaviour crash, omission, value, other (a) crash: The software failure incident in the article can be categorized as a crash. The vulnerability discovered by Jmaxxz allowed guests to hack August's software and "enroll a new key," which ultimately led to unauthorized control of an August Smart Lock even after the homeowner removed them as a guest. This indicates a failure in the system's state, resulting in the software not performing its intended function of maintaining secure access control [47041]. (b) omission: The software failure incident can also be categorized as an omission. The vulnerability in August's guest access feature allowed guests to enroll new keys and retain control of the smart lock even after their access was revoked. This omission in the system's functionality led to unauthorized access being granted, which was not the intended behavior of the software [47041]. (c) timing: The software failure incident does not align with a timing failure. The issue was not related to the system performing its intended functions too late or too early. Instead, the vulnerability allowed guests to manipulate the system to retain access even after their permissions were supposed to be revoked [47041]. (d) value: The software failure incident can be associated with a value failure. The vulnerability discovered in August's smart locks allowed guests to enroll new keys and maintain control over the lock even after their access was supposed to be removed. This incorrect behavior of the system led to unauthorized individuals having access to the smart lock, compromising its security value [47041]. (e) byzantine: The software failure incident does not align with a byzantine failure. The system did not exhibit inconsistent responses or interactions; rather, the vulnerability allowed for a specific exploit that granted unauthorized access to the smart lock [47041]. (f) other: The software failure incident can be categorized as a failure related to security vulnerability exploitation. The incident involved a flaw in the guest access feature of August's smart locks, which allowed guests to enroll new keys and retain control over the lock even after their access was supposed to be revoked. This unauthorized access highlights a critical security issue in the software system [47041].

IoT System Layer

Layer Option Rationale
Perception sensor, embedded_software (a) The failure was related to the perception layer of the cyber physical system that failed due to contributing factors introduced by sensor error. The vulnerability in August's smart locks discovered by Jmaxxz was related to guest access, where guests could hack the software and "enroll a new key" to control the lock even after being removed as a guest. This issue was specifically related to the sensor aspect of the smart lock system, where the sensor (digital key) could be manipulated by guests to gain unauthorized access [47041]. (b) There is no specific mention of the failure being related to the actuator in the articles. (c) The failure was not directly related to the processing unit of the cyber physical system. (d) The failure was not directly related to network communication errors. (e) The failure was related to the embedded software error in August's smart locks. The vulnerability discovered by Jmaxxz allowed guests to hack the software and enroll a new key, giving them continued access to the lock even after being removed as a guest. This issue was attributed to a flaw in the embedded software of the smart lock system [47041].
Communication unknown The software failure incident discussed in the articles does not directly relate to the communication layer of the cyber-physical system. Instead, it focuses on vulnerabilities in smart lock software that allowed unauthorized access and control of the locks. The failure was more related to security flaws in the software itself rather than issues at the communication layer of the system. Therefore, the failure was not at the link_level or connectivity_level of the cyber-physical system.
Application TRUE The software failure incident related to the August smart locks, as reported in Article 47041, was indeed related to the application layer of the cyber physical system. The vulnerability discovered by Jmaxxz allowed guests to hack August's software and enroll a new key, granting them control over the smart lock even after the homeowner removed them as a guest. This vulnerability stemmed from a flaw in the guest access feature of the smart lock application, showcasing a failure introduced by bugs and incorrect usage within the application layer of the system [47041].

Other Details

Category Option Rationale
Consequence property, non-human, theoretical_consequence (a) unknown (b) unknown (c) unknown (d) Property: The software failure incident related to vulnerabilities in August's smart locks allowed guests to hack the software and enroll a new key, giving them control over the smart lock even after the homeowner removed them as a guest. This could potentially lead to unauthorized access to people's homes and compromise their security [47041]. (e) unknown (f) Non-human: The software failure incident involved vulnerabilities in smart locks, which are non-human entities. The vulnerabilities allowed for unauthorized access and control over the smart locks, impacting their functionality and security [47041]. (g) unknown (h) Theoretical_consequence: The article discusses the potential security risks and consequences of the software-based locks being hacked, such as unauthorized access to homes. It mentions that while the vulnerability was discovered, there were no reported break-ins resulting from it. The FBI report cited in the article also indicates that home invasions related to hacking smart devices are rare [47041]. (i) unknown
Domain information (a) The failed system in the article was related to the information industry as it involved vulnerabilities in smart locks that are connected to the internet and allow for the sharing of digital keys [47041].

Sources

Back to List