Published Date: 2015-01-06
| Postmortem Analysis | |
|---|---|
| Timeline | 1. The software failure incident at Moonpig happened in January 2015. [32707, 32385, 32813] |
| System | 1. Moonpig's mobile apps API system failed to securely authenticate users, leading to a security vulnerability that exposed personal details of customers [32707, 32385, 32813]. 2. Moonpig's mobile apps failed to properly authenticate customer IDs, allowing unauthorized access to customer accounts [32385, 32813]. 3. Whiplr's internal database system failed to securely store user credentials, leading to passwords being stored in plain text format [75809]. |
| Responsible Organization | 1. Moonpig's mobile apps developer, Paul Price, who discovered the security vulnerability and disclosed it to Moonpig but received no fix for almost 18 months, leading him to go public with the flaw [32707, 32385, 32813]. 2. Moonpig, the online greetings card company, was responsible for the software failure incident due to the security flaw in its API that exposed personal details of its customers [32707, 32385, 32813]. |
| Impacted Organization | 1. Moonpig - 3 million customers had their personal details exposed due to a security bug in the mobile apps [32707, 32385, 32813] 2. Whiplr - Users of the fetish app had their passwords stored in plain text, leaving them vulnerable to exploitation by hackers [75809] |
| Software Causes | 1. The software failure incident at Moonpig was caused by a security bug in the application programming interface (API) used by their mobile apps, which allowed any attacker to access personal details of customers without proper authentication [32707, 32385, 32813]. 2. The vulnerability in Moonpig's system was due to the API sending every request protected by the same credentials, rather than securely sending information protected by individual usernames and passwords [32707, 32385, 32813]. 3. The flaw in Moonpig's software allowed attackers to access customer IDs, personal information, credit card details (including the last four digits and expiry dates), and other sensitive data without proper authentication [32707, 32385, 32813]. 4. The failure incident was exacerbated by the lack of timely response and action by Moonpig to address the security vulnerability even after being notified by the developer, leading to a prolonged exposure of customer data [32707, 32385, 32813]. |
| Non-software Causes | 1. Lack of timely response and action by Moonpig to address the security vulnerability reported by the developer, Paul Price, over a period of 17 months [32707, 32385, 32813]. 2. Failure of Moonpig to implement proper authentication mechanisms in their API, allowing unauthorized access to customer accounts [32707, 32385, 32813]. 3. Insufficient security measures and oversight in the development and maintenance of Moonpig's mobile apps, leading to the exposure of sensitive customer data [32707, 32385, 32813]. 4. Failure of Moonpig to prioritize customer data security despite being made aware of the vulnerability, potentially exposing customer information for an extended period [32707, 32385, 32813]. |
| Impacts | 1. Personal details of 3 million Moonpig customers were exposed due to a security bug, allowing attackers to access addresses, birthdays, email addresses, phone numbers, and partial credit card data [32707, 32385]. 2. The vulnerability in Moonpig's API allowed attackers to view saved addresses, the last four digits of credit cards, and place orders on other customers' accounts [32385, 32813]. 3. Moonpig's mobile apps were shut down, and investigations were launched to address the security flaw, impacting the availability of the app for customers [32385, 32813]. 4. The incident raised concerns about the company's handling of customer data security, leading to public scrutiny and questions about the seriousness of the security issue [32813]. 5. Moonpig faced criticism for not addressing the security vulnerability promptly, potentially exposing customer data for an extended period [32813]. 6. The incident highlighted the importance of proper authentication and security measures in software development to prevent unauthorized access to sensitive customer information [32707, 32385, 32813]. |
| Preventions | 1. Timely response to vulnerability reports: Moonpig could have prevented the software failure incident by promptly addressing the security bug reported by the developer, Paul Price, when he initially disclosed it to them in August 2013. A timely fix within the industry standard of 90 days could have prevented the exposure of customer data [32707, 32385]. 2. Proper authentication mechanisms: Implementing proper authentication mechanisms in the software, such as requiring individual usernames and passwords for each user rather than using static credentials for all requests, could have prevented unauthorized access to customer accounts [32707, 32385]. 3. Regular security audits and testing: Conducting regular security audits and testing of the software, including the API used by Moonpig's mobile apps, could have helped identify and address vulnerabilities before they were exploited by attackers [32707, 32385]. 4. Strong password protection: Storing user passwords securely using encryption methods like hashing and salting, as well as implementing two-factor authentication, could have prevented the exposure of user credentials in plain text format, as seen in the Whiplr app incident [75809]. |
| Fixes | 1. Implement proper authentication mechanisms in the API to ensure that requests are securely authenticated based on individual user credentials, rather than using static credentials for all users [32707, 32385, 32813]. 2. Enforce rate limiting on API calls to prevent attackers from easily cycling through different customer IDs to access accounts [32385, 32813]. 3. Enhance security measures by hashing and salting user passwords to protect them in the internal database, as well as implementing two-factor authentication for added security [75809]. 4. Respond promptly to security vulnerability reports and prioritize fixing such issues within a reasonable timeframe to prevent potential data breaches [32707, 32385, 32813]. 5. Conduct thorough security audits and testing to identify and address any existing vulnerabilities in the software system [32707, 32385, 32813]. |
| References | 1. Developer Paul Price [32707, 32385, 32813] 2. Moonpig's official statements [32707, 32385, 32813] 3. Security experts and analysts [32707, 32385, 32813] 4. Whiplr's data protection officer Ido Manor [75809] 5. Engadget [75809] |
| Category | Option | Rationale |
|---|---|---|
| Recurring | one_organization, multiple_organization | (a) The software failure incident having happened again at one_organization: - The developer Paul Price, who discovered the security vulnerability in Moonpig's API, had previously disclosed a vulnerability in another British greetings-card website, Funky Pigeon, in October 2013 [32385]. - Moonpig, the online greetings card company, was accused of ignoring a security issue for over a year that exposed customer data, as revealed by developer Paul Price [32813]. (b) The software failure incident having happened again at multiple_organization: - The article mentions that Whiplr, a popular fetish app, was found to be storing users' passwords in plain text, leaving them vulnerable to exploitation by hackers [75809]. - It is noted that T-Mobile Austria and Twitter have also been involved in incidents where passwords were stored in plain text, indicating a broader issue with password security practices in various organizations [75809]. |
| Phase (Design/Operation) | design, operation | (a) The software failure incident related to the design phase: - Moonpig's security flaw was due to a vulnerability in the section of software that lets MoonPig’s mobile apps communicate with its servers, called an application programming interface (API). The flaw allowed any attacker to access the personal details of every single customer on the website, view past orders, and place new ones on any account. This flaw was a result of how the API sent every request protected by the same credentials, regardless of which user was signed in, rather than securely sending information protected by individual usernames and passwords [32707, 32385]. - Developer Paul Price discovered the security vulnerability in Moonpig's API, which exposed customer data, and he initially disclosed it to MoonPig in private in August 2013. Despite Price's efforts to alert MoonPig, the company took almost 18 months to address the issue, leading Price to go public with the flaw. This delay in fixing the vulnerability highlights a failure in the design phase of the software development process [32707, 32385]. - Moonpig's security issue allowed attackers to access customer IDs by sending API requests without requiring authentication. This flaw was a result of the API calls not being rate-limited, enabling a determined hacker to work through different combinations until they hit each customer ID. The vulnerability exposed contact details, the last four digits of saved credit cards, and allowed unauthorized orders to be placed on someone else's card. This flaw in the design of the system posed a significant security risk to customer data [32813]. (b) The software failure incident related to the operation phase: - Moonpig's security flaw was discovered by a mobile app developer, Paul Price, while examining the security settings of the code used in Moonpig's Android and iOS applications. The flaw allowed unauthorized access to any of Moonpig's three million customer accounts through the mobile apps. This issue was a result of the operation or misuse of the system, where the app failed to authenticate customers' usernames and passwords, making it possible to input any customer ID to access their account [32385]. - Moonpig suspended its mobile apps following claims of a security flaw that allowed access to customer accounts. The company urged customers to use its main website instead of the apps while they investigated the security issue. This operational failure led to a disruption in service as the apps were temporarily unavailable during the investigation [32385]. - Moonpig's security vulnerability, which exposed customer data, was a result of a failure in the operation phase where API calls were not rate-limited, allowing attackers to access customer IDs and sensitive information without authentication. This flaw in the operation of the system posed a risk to customer data security and privacy [32813]. |
| Boundary (Internal/External) | within_system | (a) The software failure incident related to Moonpig's security flaw can be categorized as within_system. The incident was caused by a security bug in Moonpig's API that allowed any attacker to access personal details of customers, view past orders, and place new orders on any account [32707, 32385, 32813]. The flaw was due to the API sending every request protected by the same credentials, regardless of the user signed in, making it vulnerable to unauthorized access [32707, 32385]. The vulnerability was discovered by a developer, Paul Price, who disclosed it to Moonpig but the firm took almost 18 months to address the issue, leading Price to go public with his findings [32707, 32385]. The incident highlighted a failure in the system's security measures and architecture, indicating an internal flaw within Moonpig's software system. |
| Nature (Human/Non-human) | non-human_actions, human_actions | (a) The software failure incident occurring due to non-human actions: - In the Moonpig incident, the security flaw that exposed personal details of customers was due to a security bug in the software, specifically in the section of software that lets Moonpig’s mobile apps communicate with its servers (Article 32707). - The vulnerability allowed any attacker to access personal details, view past orders, and place new orders on any customer account. This flaw was related to how the application programming interface (API) sent every request protected by the same credentials, regardless of the user signed in, making it easy for unauthorized access (Article 32707). - The flaw was discovered by a developer, Paul Price, who disclosed it to Moonpig in private initially but decided to go public after almost 18 months of no fix from the company (Article 32707). - Moonpig's mobile apps were shut down after Price's post was published, sealing off the security hole caused by the software flaw (Article 32707). (b) The software failure incident occurring due to human actions: - The security flaw in Moonpig's mobile apps was discovered by a mobile app developer, Paul Price, who found that the software failed to authenticate customers' usernames and passwords properly, allowing access to any customer account by inputting any customer ID (Article 32385). - Price contacted Moonpig about the security flaw in 2013, but the company did not resolve the issue for 17 months, leading him to go public with the vulnerability (Article 32385). - Moonpig's response to the flaw was delayed, and the company only suspended access to its mobile apps and launched an investigation after Price's public disclosure (Article 32385). - The vulnerability in Moonpig's API, which exposed customer data, was due to a specific situation where a user could not have been identified via email address, indicating a flaw in the software's authentication process (Article 32813). |
| Dimension (Hardware/Software) | software | (a) The software failure incident occurring due to hardware: - There is no information in the provided articles indicating that the software failure incident at Moonpig was caused by contributing factors originating in hardware. Therefore, the incident was not related to hardware issues [Article 32707, Article 32385, Article 32813]. (b) The software failure incident occurring due to software: - The software failure incident at Moonpig was primarily caused by software-related issues. The incident involved a security bug in Moonpig's mobile apps that exposed personal details of millions of customers. The flaw was related to the software's application programming interface (API) not securely sending information protected by individual credentials, allowing any attacker to access customer data without proper authentication [Article 32707, Article 32385, Article 32813]. |
| Objective (Malicious/Non-malicious) | non-malicious | (a) The software failure incident related to Moonpig's security flaw can be categorized as malicious. The incident involved a security bug that exposed personal details of millions of customers due to a vulnerability in the application programming interface (API) used by Moonpig's mobile apps. The developer who discovered the vulnerability, Paul Price, disclosed the flaw to Moonpig in 2013 but after almost 18 months of inaction by the company, he decided to go public with the findings to force them to fix it [32707, 32385, 32813]. (b) The incident was non-malicious in the sense that the security flaw was not intentionally introduced to harm the system but was a result of a failure in the software development process and inadequate security measures. The flaw allowed unauthorized access to customer data, including personal information and partial credit card details, due to the lack of proper authentication mechanisms in the API used by Moonpig's mobile apps [32707, 32385, 32813]. |
| Intent (Poor/Accidental Decisions) | poor_decisions | (a) poor_decisions: - The software failure incident at Moonpig was primarily due to poor decisions made by the company in handling a security vulnerability. The developer, Paul Price, discovered a security flaw in Moonpig's API and disclosed it to the company in August 2013. However, Moonpig did not take appropriate action to fix the vulnerability for almost 17 months despite being informed multiple times [Article 32385]. - Moonpig's response to the security bug was criticized by Price as having "the worst security I’ve ever seen from a large company" and described the security measures as "half-arsed" [Article 32707]. - Moonpig's handling of the security issue, including failing to address the vulnerability promptly and not taking customer data security seriously, reflects poor decisions made by the company [Article 32813]. (b) accidental_decisions: - The software failure incident at Moonpig was not accidental but rather a result of deliberate actions or inactions by the company in addressing the security vulnerability [Article 32385]. - The incident was not accidental but stemmed from the company's failure to prioritize customer data security and address the reported vulnerability in a timely manner [Article 32813]. |
| Capability (Incompetence/Accidental) | development_incompetence, accidental | (a) The software failure incident occurring due to development incompetence: - The incident at Moonpig was a result of a security bug that exposed personal details of 3 million customers due to a flaw in the software's API [32707]. - The vulnerability was discovered by a developer, Paul Price, who disclosed it to Moonpig in August 2013. However, Moonpig did not address the issue for almost 18 months, showcasing a lack of prompt action and professional competence in handling security vulnerabilities [32707]. - Price criticized the security measures implemented by Moonpig, stating that the flaw was a result of poor architecture in the system, indicating a lack of proper design and implementation practices [32707]. - Moonpig's delayed response and failure to fix the vulnerability in a timely manner despite being notified earlier by Price reflect a level of development incompetence in addressing critical security issues [32385]. (b) The software failure incident occurring accidentally: - The security flaw in Moonpig's API that led to the exposure of customer data was not intentional but rather a result of a bug in the software [32707]. - Moonpig's response to the incident, including suspending its mobile apps and conducting investigations, indicates that the exposure of customer data was accidental and not a deliberate act [32385]. - The storing of user passwords in plain text by the Whiplr app was also an accidental vulnerability, as it was discovered when a user was asked to submit their password, username, and email address in plain-text format to verify their account [75809]. - Whiplr acknowledged the error and took steps to secure passwords with one-way encryption after the incident, indicating that the storage of passwords in plain text was unintentional and not a deliberate security practice [75809]. |
| Duration | temporary | (a) The software failure incident in the Moonpig case was temporary. The security flaw that exposed personal details of millions of customers was discovered by developer Paul Price, who initially disclosed it to Moonpig in August 2013. Despite Price's efforts to alert the company and give them time to fix the issue, the vulnerability persisted for almost 18 months until Price decided to make it public in January 2015. Moonpig then shut down its mobile apps to address the security hole [32707, 32385, 32813]. (b) The software failure incident in the Whiplr case was also temporary. The app was found to be storing users' passwords in plain text, leaving them vulnerable to exploitation by hackers. After this vulnerability was pointed out, Whiplr stated that they would implement greater security measures to protect users' credentials, such as securing passwords with one-way encryption and adding more security measures in the future [75809]. |
| Behaviour | omission, value, other | (a) crash: The articles do not mention any instance of a crash where the system loses state and does not perform any of its intended functions. (b) omission: The software failure incident can be categorized under omission as it involved a security flaw that allowed unauthorized access to customer accounts, enabling potential hackers to place orders, retrieve credit card details, and obtain personal information without proper authentication [Article 32385]. (c) timing: The incident does not relate to timing issues where the system performs its intended functions but at the wrong time. (d) value: The software failure incident falls under the value category as it involved the system performing its intended functions incorrectly by allowing access to customer accounts without proper authentication, compromising personal data and credit card details [Article 32385]. (e) byzantine: The incident does not align with a byzantine failure where the system behaves erroneously with inconsistent responses and interactions. (f) other: The software failure incident can be further categorized as a security vulnerability in the system's API that led to unauthorized access to customer accounts, exposing personal information and credit card details [Article 32707, Article 32813]. |
| Layer | Option | Rationale |
|---|---|---|
| Perception | None | None |
| Communication | None | None |
| Application | None | None |
| Category | Option | Rationale |
|---|---|---|
| Consequence | property, theoretical_consequence | (d) property: People's material goods, money, or data was impacted due to the software failure. The software failure incident involving Moonpig's mobile apps exposed personal details of millions of customers, including names, addresses, birthdays, email addresses, phone numbers, and a portion of credit card data [32707, 32385, 32813]. This breach of sensitive information could potentially lead to financial harm or loss for the affected customers. Additionally, the vulnerability allowed unauthorized access to customer accounts, enabling attackers to view saved addresses, place orders on someone else's card, and retrieve credit card details [32385, 32813]. |
| Domain | information, finance | (a) The failed system was related to the information industry as it involved an online greetings card service, Moonpig, which allows customers to order and send personalized greeting cards [Article 32385]. (h) The failed system was also related to the finance industry as it involved the security of customer data, including payment information, within the Moonpig app [Article 32385]. (m) The failed system was not related to any other industry mentioned in the options. |
Article ID: 32707
Article ID: 32385
Article ID: 32813
Article ID: 75809