Full Report
In 2019, McAfee Advanced Threat Research (ATR) disclosed a vulnerability in a product called BoxLock. Sometime after this, the CEO... The post My Adventures Hacking the iParcelBox appeared first on McAfee Blog.
Analysis Summary
# Incident Report: Cloud Misconfiguration Leading to IoT Device Compromise via OSINT
## Executive Summary
This analysis, initiated as a proactive security review sponsored by iParcelBox, quickly evolved into an investigation revealing significant security weaknesses stemming from poor operational security (OSINT controls) by development staff. Attackers could leverage publicly available forum posts containing development insights, configuration details, and potentially shared AWS credentials to gain unauthorized control over customer iParcelBox devices. The swift action by iParcelBox resulted in a rapid remediation, setting a good precedent for vendor response times.
## Incident Details
- Discovery Date: Sometime after the product's disclosure/sponsorship (2019 context, actual discovery date not specified).
- Incident Date: Occurred during the research phase prior to disclosure.
- Affected Organization: iParcelBox (UK Company)
- Sector: Internet of Things (IoT) / Smart Home Hardware
- Geography: United Kingdom (Primary installation/customer base implied)
## Timeline of Events
### Initial Access
- Date/Time: Not specified, occurred during the vendor-sponsored security evaluation.
- Vector: Open Source Intelligence (OSINT) combined with physical/network analysis of the device during setup.
- Details: Researchers obtained the 16-character random WPA2 key during a brief setup Wi-Fi AP window. By connecting immediately, they analyzed the device's webserver (Port 443) and disassembled the Android application (APK).
### Lateral Movement
- Details: While direct lateral movement within a network wasn't the focus, the research uncovered that an extracted AWS certificate and private key, visible through forum posts regarding Mongoose-OS development, allowed control over *any* customer iParcelBox, effectively gaining "lateral movement" across the fleet.
### Data Exfiltration/Impact
- Details: The mechanism for data exfiltration or direct impact was confirmed to be the ability to control any device using compromised AWS credentials linked to the shared Cognito identity, allowing unauthorized access/control over customer parcels.
### Detection & Response
- Detection: Discovered by McAfee ATR researchers during focused analysis, triggered by OSINT findings on Mongoose-OS forums.
- Response Actions: Vulnerabilities disclosed immediately to iParcelBox. The vendor responded rapidly (within 12 hours) by changing admin passwords, patching API logic to check Customer IDs, and fixing certificate pinning in the Android app.
## Attack Methodology
- Initial Access: Analyzing device firmware/AP communication protocol (MQTT) and exploiting exposed development details via OSINT.
- Persistence: Implied through continued unauthorized use of the MQTT broker access granted by shared AWS credentials across the device fleet.
- Privilege Escalation: Attackers did not need to escalate privileges on a single device; compromised cloud credentials granted administrative control over *all* devices via the centralized MQTT/AWS infrastructure.
- Defense Evasion: Specific evasion techniques not detailed, but the reliance on misconfiguration (shared cloud secrets) bypassed standard application security controls.
- Credential Access: Implicitly gained by tracking developer posts on Mongoose-OS forums, leading to the discovery of shared AWS certificates/private keys associated with the device fleet.
- Discovery: Analysis of disassembled APK code, device port scanning, and DNS lookups against internal hostnames.
- Lateral Movement: Across the entire fleet of deployed devices via the shared cloud backend (AWS/DynamoDB).
- Collection: The ability to interrogate the centralized database (DynamoDB) for user data, circumvented by wrapping queries in Customer ID checks post-patch.
- Exfiltration: Not explicitly detailed, but the capability to read/manipulate data related to customer boxes existed.
- Impact: Unauthorized control over physical security devices and potential access to customer metadata/logs.
## Impact Assessment
- Financial: Costs associated with the emergency patching by the vendor (not quantified).
- Data Breach: Customer information potentially accessible through the shared Cognito credentials and DynamoDB access.
- Operational: Potential for widespread disruption if the vulnerability were exploited maliciously (e.g., denying package access).
- Reputational: Potential for significant negative publicity, mitigated by the swift and transparent response from iParcelBox.
## Indicators of Compromise
- Network indicators: Traffic between the application and iParcelBox likely used MQTT over Port 443 (encrypted). Potential exposure of configuration domains like `config.iparcelbox.com` during setup.
- Behavioral indicators: Unauthorized control/commands sent to shared MQTT topics; unauthorized DynamoDB access requests not validated against Customer IDs.
## Response Actions
- Containment: Immediate disclosure to iParcelBox management.
- Eradication: Vendor action included changing the master admin password, isolating device control via mandatory Customer ID checks on database queries, and patching certificate usage.
- Recovery: Vendor verified fixes by ensuring no single device's certificate/key could control others and updated the Android app to enforce certificate pinning.
## Lessons Learned
- Online Data Hygiene is Critical: Simple mistakes in OSINT and managing developer forum posts exposed architecture details, platform usage (Mongoose-OS/ESP32), and critical AWS credentials spanning the entire product fleet.
- Shared Credentials are Catastrophic: A major finding was the use of a configuration where one device’s AWS certificate/private key could control *all* devices.
- Vendor Security Focus: iParcelBox demonstrated an excellent response time (12 hours for a critical patch) and inherent good security practices (SSL usage, flash encryption, disabling UART/Bluetooth).
## Recommendations
- Implement strict security policies for internal development teams regarding public-facing forum participation, ensuring zero technical details (even seemingly minor ones) that characterize architecture or configuration standards are shared.
- Ensure cloud infrastructure uses strict, unique Identity and Access Management (IAM) roles or credentials for every deployed device/customer partition, preventing fleet-wide compromise from a single stolen set of keys.
- Conduct regular, independent audits of application code and cloud configurations, particularly focusing on how customer identifiers are enforced during data access (DynamoDB queries).