Formerly known as Incapsula, the Cloud WAF analyzes requests coming into applications, and flags or blocks suspicious and malicious activity.
The company announced the breach in August, but at the time said it didn’t know how the attackers were able to gain access. In a Thursday post, CTO Kunal Anand laid out what happened. He explained that in October 2018, the attackers stole and used an administrative AWS API key in one of Imperva’s production AWS accounts, to access a database snapshot containing emails, hashed and salted passwords, and some customers’ API keys and TLS keys.
“I’ll start by going back to 2017 when our Cloud WAF, previously known as Incapsula, was under a significant load from onboarding new customers and meeting their critical demands,” he wrote in the blog post. “That year, our product development team began the process of adopting cloud technologies and migrated to AWS Relational Database Service (RDS) to scale our user database.”
At that point, Imperva created a database snapshot for testing; and also, an internal compute instance was misconfigured and publicly accessible, he said. That compute instance contained the AWS API key that the hackers were then able to lift and access the snapshot in October 2018. Because the database was accessed as a snapshot, the hackers made off with only old Incapsula records that go up to Sept. 15, 2017.
“Non-human identities like API keys, machines (every EC2 instance can be identified), service accounts, and bots have grown exponentially to accommodate the unprecedented levels of automation Balaji Parimi, CEO, CloudKnox Security, said in an emailed statement. “There are thousands of such identities in every enterprise. There is no easy way to gain visibility into how many of them exist, what privileges they have and which privileges they are actually using. This lack of visibility and the inability to manage their privileges and their proliferation creates a huge risk. In the case of the Imperva breach, it was a single compute instance that created the opportunity for hackers to steal an AWS API key in order to access its cloud infrastructure and wreak havoc. That’s all it takes sometimes – losing track of one identity with excessive privileges.”
While the exposure of users’ emails and hashed and salted passwords is concerning, the exfiltration of API keys and SSL would allow an attacker to break companies’ encryption and access corporate applications directly, Chris Morales, Head of Security Analytics at Vectra, told Threatpost in August.
“Secure web gateways, firewalls, intrusion detection and prevention systems, and data loss prevention (DLP) products all perform some form of SSL intercept and decryption to perform DPI,” he explained.
Morales isn’t alone in his concern.
That an EC2 instance was compromised and AWS credentials exposed is, like, whatever. Film at 11. But that TLS keys were exposed is inexcusable. #imperva #aws #cloud #security https://www.zdnet.com/article/imperva-blames-data-breach-on-stolen-aws-api-key/ …
Anand said that so far, Imperva hasn’t detected malicious or suspicious activity (odd logins, rule changes and the like), but that it will continue to monitor for it.
In the aftermath, Imperva said that it has implemented tighter security access controls; and has audited snapshot access and increasing the frequency of infrastructure scanning. It’s also decommissioning inactive compute instances and putting all internal instances behind a VPN by default; and, it said it’s rotating credentials and strengthening its credential management processes.
“We regret that this incident occurred and have been working around the clock to learn from it and improve how we build and run Imperva,” Anand wrote. “Security is never ‘done’ and we must continue to evaluate and improve our processes every single day. Our vision remains the same: to lead the world’s fight on behalf of our customers and their customers to keep data and applications safe from cybercriminals. Now, more than ever, we commit to our vision, where data and applications are kept safe.”