Imperva breach update puts blame on exposed AWS API keys

Imperva admitted that an exposed compute instance led to the breach affecting cloud web application firewall customers.

Kunal Anand, CTO of Imperva, posted updated information about a breach that occurred in October 2018 and was originally disclosed in August of this year. Anand said the Imperva breach started with an internal cloud instance the company left exposed, which led to the theft of an AWS API key that was used to access customer data.

"Some key decisions made during the AWS evaluation process, taken together, allowed information to be exfiltrated from a database snapshot," Anand wrote in a blog post. "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.

"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."

According to Anand, the AWS API key was used on an AWS production account in October 2018 to access a database snapshot from September 2017. The snapshot contained email addresses, hashed and salted passwords, API keys and TLS keys for a "small subset" of Imperva's Cloud WAF customers. 

"We have since gone back and looked for malicious activity, leveraging threat intelligence feeds in conjunction with audit logs, related to accounts in the dataset," Anand wrote. "Thus far, we have not found any malicious behavior targeting our customers and have implemented procedures to continue monitoring for such activity."

A spokesperson for the company told SearchSecurity that in response to the Imperva breach, the company forced customers to change passwords older than 90 days, but they could not force resets for compromised API keys or TLS certificates. Instead, Imperva actively reached out to customers and "strongly recommended that they rotate their own certs and keys, provided them with audit logs to allow them to review for potential malicious activity within their accounts, and have implemented procedures that now also allow us to monitor customer accounts for potential malicious activity against our IP threat reputation feeds."

Ultimately, Anand said in the blog post that the efforts led to customers changing "more than 13,000 passwords, rotating over 13,500 SSL certificates, and regenerating over 1,400 API keys."

The company would not say exactly how many customers were affected in the Imperva breach. While Anand's blog post emphasized the importance of transparency, it also described a "natural tension" between transparent disclosure and the investigative process.

The Imperva spokesperson explained that "there is inherent tension between wanting to be transparent and proactive and the need to allow the investigation to play out and only sharing information when we are confident in the data and know it to be true."

In an effort to ensure another Imperva breach does not occur, Anand said security protocols were improved, including tighter access controls, decommissioning inactive instances, more frequent snapshot audits, credential rotations and infrastructure scanning, and putting all internal compute instances behind a VPN by default. 

The Imperva spokesperson said "ensuring that new database instances are created behind our VPN by default increas[es] the monitoring and patching programs in place and a [creates] clear defined process to decommission unused and non-critical compute instances."