Full Report
On November 9, 2014, BrowserStack suffered a breach when a hacker accessed an old, unpatched prototype server via the shellshock vulnerability. The server contained AWS credentials, allowing the attacker to create an instance, access a backup, and partially copy user data (ema...
Analysis Summary
# Incident Report: BrowserStack Shellshock Breach (Nov 2014)
## Executive Summary
On November 9, 2014, BrowserStack experienced a security breach originating from an attacker exploiting the unpatched Shellshock vulnerability on an old prototype server. The compromise of AWS credentials led to the partial copying of user data, including email addresses and hashed passwords. BrowserStack contained the incident quickly by blocking the attacker, revoking keys, and initiating a comprehensive security review.
## Incident Details
- Discovery Date: November 9, 2014 (Implied shortly after exploitation triggered alerts)
- Incident Date: November 9, 2014
- Affected Organization: BrowserStack
- Sector: Software/Cloud Testing Services
- Geography: Not explicitly stated (Global operations)
## Timeline of Events
### Initial Access
- Date/Time: November 9, 2014
- Vector: Vulnerability Exploitation (Shellshock)
- Details: A hacker accessed an old, unpatched prototype server using the **Shellshock vulnerability** (CVE-2014-6271/related).
### Lateral Movement
- Date/Time: Post-Initial Access (Simultaneous with Data Exfiltration)
- Vector: Utilizing Stolen Credentials
- Details: The exploited server contained **AWS credentials**, which the attacker used to create unauthorized AWS instances and access a system backup.
### Data Exfiltration/Impact
- Date/Time: November 9, 2014
- Vector: Data Copying/Theft
- Details: The attacker partially copied user data, specifically **email addresses, hashed passwords, and test URLs**.
### Detection & Response
- Date/Time: November 9, 2014
- Vector: Internal Alerting
- Details: The intrusion triggered internal alerts, leading BrowserStack to **quickly block the attacker**. The company immediately revoked compromised AWS keys and initiated remediation.
## Attack Methodology
- Initial Access: **Vulnerability Exploitation** (Shellshock on an old server).
- Persistence: Not explicitly detailed, but access was maintained long enough to access backups.
- Privilege Escalation: **Credential Access** (Compromise of cached AWS credentials).
- Data Collection: Accessing a backup repository.
- Exfiltration: Partially copying user data (emails, hashed passwords, test URLs).
- Impact: Unauthorized access to user PII and configuration data; potential reputational damage.
## Impact Assessment
- Financial: Not specified.
- Data Breach: **Partial compromise** of user data, including:
- Email addresses
- **Hashed passwords**
- Test URLs
- Operational: Minimal reported downtime; incident response focused on rapid containment.
- Reputational: The hacker attempted reputational damage by emailing fewer than 1% of users with false claims of a total shutdown.
## Indicators of Compromise
*Note: Specific IoCs were not provided in the context.*
- Network Indicators: Excessive traffic originating from new, unauthorized AWS instances linked to the attacker's ingress point. (Defanged)
- Behavioral Indicators: Use of compromised AWS credentials to create new compute resources and access backup systems.
## Response Actions
- **Containment (Immediate):**
- Immediately revoked all compromised AWS access keys.
- Blocked the attacker's access path.
- **Eradication/Remediation:**
- Confirmed that no sensitive payment data (handled by external processors) was compromised.
- Verified that no other production systems were breached.
- **Recovery:**
- Initiated the process of implementing encrypted backups moving forward.
- Initiated a third-party security audit.
## Lessons Learned
- **Vulnerability Management Failure:** The primary cause was an old, unpatched prototype server being accessible, indicating a failure in retiring or hardening legacy infrastructure.
- **Credential Storage Risk:** AWS credentials were stored on the compromised prototype server, leading directly to lateral capability.
- **Communication Management:** The attacker attempted external manipulation by emailing users with false shutdown claims.
## Recommendations
- **Asset Inventory and Decommissioning:** Immediately review and decommission all forgotten or unmonitored prototype/staging servers.
- **Separation of Duties/Least Privilege:** Ensure that credentials for critical services (like AWS) are never stored on low-security or outdated environments.
- **Patch Management:** Implement rigorous and automated patching schedules, especially addressing critical vulnerabilities like Shellshock, across all active components.
- **Security Auditing:** Continue engaging third-party auditors to validate security posture post-incident.