The data breach that security firm Imperva disclosed in August was the result of an attacker compromising an internal compute instance and stealing an AWS API key that was then used to access a database snapshot containing customer API keys and other data.
The incident occurred in October 2018 but Imperva officials only became aware of it in August when a third party reached out to the company to inform them of an issue and requesting a bug bounty. As a result of the intrusion, data from customers of Imperva’s Cloud WAF product as of Sept. 15, 2017, was stolen, including email addresses, hashed and salted passwords, API keys, and TLS keys. The incident was not the result of a vulnerability in the Cloud WAF itself, but rather a compromise of one of Imperva’s internal compute instances created during a transition to the AWS Relational Database Service.
“Some key decisions made during the AWS evaluation process, taken together, allowed information to be exfiltrated from a database snapshot. These were: (1) we created a database snapshot for testing; (2) an internal compute instance that we created was accessible from the outside world and it contained an AWS API key; (3) this compute instance was compromised and the AWS API key was stolen; and (4) the AWS API key was used to access the snapshot,” Imperva CTO Kunal Anand said in a post-mortem on the incident.
“We compared the SQL dump in the provided dataset to our snapshots and found a match. As of this post, we can say that the elements of customer data defined above were limited to Cloud WAF accounts prior and up to September 15, 2017. Databases and snapshots for our other product offerings were not exfiltrated.”
“We take ownership of the fact that the incident was a result of our choices, actions we took and failed to take before, during, and after our database migration."
Anand said the company has not detected any abuse of customer accounts as a result of the intrusion. After the initial discovery of the compromise, Imperva officials forced password resets and affected customers also rotated SSL certificates and created new API keys. The company also made a number of changes to its internal processes as a result of the incident, including increasing minimum password complexity and decreasing the time to rotate passwords for Cloud WAF customers. Imperva also implemented single sign-on and MFA for its AWS console, but that was done after the incident but before it was discovered. Anand said those protections would not have prevented the compromise, though.
Imperva also changed the way that it handles security event feeds from AWS.
“While we enabled AWS CloudTrail and GuardDuty and ingested those log events in our SIEM two years ago, we are being more proactive today and are getting those events forwarded into our UEBA, including VPC NetFlow logs. We’ve created alerts and workflows around key events. We have also developed SOC dashboards to monitor and alert on malicious activity at the customer account level (API and management console),” Anand said.
Among the lessons the company learned from the incident were to communicate with customers and the public as quickly and clearly as possible and to continue to be transparent throughout the investigation and aftermath.
“We take ownership of the fact that the incident was a result of our choices, actions we took and failed to take before, during, and after our database migration. We recommend all organizations take the time to fully understand the shared responsibility of deploying and managing applications and data in Infrastructure as a Service (IaaS) solutions,” Anand said.