Imperva, a leading provider of Internet firewall services that help Web sites block malicious cyberattacks, alerted customers on Tuesday that a recent data breach exposed email addresses, scrambled passwords, API keys and SSL certificates for a subset of its firewall users.
Redwood Shores, Calif.-based Imperva sells technology and services designed to detect and block various types of malicious Web traffic, from denial-of-service attacks to digital probes aimed at undermining the security of Web-based software applications.
Image: Imperva
Earlier today, Imperva told customers that it learned on Aug. 20 about a security incident that exposed sensitive information for some users of Incapsula, the company’s cloud-based Web Application Firewall (WAF) product.
“On August 20, 2019, we learned from a third party of a data exposure that impacts a subset of customers of our Cloud WAF product who had accounts through September 15, 2017,” wrote Heli Erickson, director of analyst relations at Imperva.
“We want to be very clear that this data exposure is limited to our Cloud WAF product,” Erickson’s message continued. “While the situation remains under investigation, what we know today is that elements of our Incapsula customer database from 2017, including email addresses and hashed and salted passwords, and, for a subset of the Incapsula customers from 2017, API keys and customer-provided SSL certificates, were exposed.”
Companies that use the Incapsula WAF route all of their Web site traffic through the service, which scrubs the communications for any suspicious activity or attacks and then forwards the benign traffic on to its intended destination.
Rich Mogull, founder and vice president of product at Kansas City-based cloud security firm DisruptOps, said Imperva is among the top three Web-based firewall providers in business today.
According to Mogull, an attacker in possession of a customer’s API keys and SSL certificates could use that access to significantly undermine the security of traffic flowing to and from a customer’s various Web sites.
At a minimum, he said, an attacker in possession of these key assets could reduce the security of the WAF settings and exempt or “whitelist” from the WAF’s scrubbing technology any traffic coming from the attacker. A worst-case scenario could allow an attacker to intercept, view or modify traffic destined for an Incapsula client Web site, and even to divert all traffic for that site to or through a site owned by the attacker.
“Attackers could whitelist themselves and begin attacking the site without the WAF’s protection,” Mogull told KrebsOnSecurity. “They could modify any of the security Incapsula security settings, and if they got [the target’s SSL] certificate, that can potentially expose traffic. For a security-as-a-service provider like Imperva, this is the kind of mistake that’s up there with their worst nightmare.”
Imperva urged all of its customers to take several steps that might mitigate the threat from the data exposure, such as changing passwords for user accounts at Incapsula, enabling multi-factor authentication, resetting API keys, and generating/uploading new SSL certificates.
Alissa Knight, a senior analyst at Aite Group, said the exposure of Incapsula users’ scrambled passwords and email addresses was almost incidental given that the intruders also made off with customer API keys and SSL certificates.
Knight said although we don’t yet know the cause of this incident, such breaches at cloud-based firms often come down to small but ultimately significant security failures on the part of the provider.
“The moral of the story here is that people need to be asking tough questions of software-as-a-service firms they rely upon, because those vendors are being trusted with the keys to the kingdom,” Knight said. “Even if the vendor in question is a cybersecurity company, it doesn’t necessarily mean they’re eating their own dog food.”
Well… this is awkward.
Indeed; appreciate the irony.
LOL! Exact same thing went through my head! Seems similar to successfully holding up and robbing a policemans gala.
Love how the Akamai (competitor to Imperva) ad appears at the end of the article. Opportunistic marketing.
Cough ryoungbl@akamai.com cough cough
I would agree, except that it tends to show up at the end of every story here. They are a major supporter, even if they couldn’t afford to keep protecting the site pro bono after the Mirai botnet hammered it.
So it’s amusing, ironic coincidence, rather than any particular marketing decision meant to twist the knife.
The end of article Akamai advertisement appears to be in violation of the FTC “.com” advertisement rules. Unlike the other adverts on the site, which include an “advertisement” text label, this advert is not “presented clearly and conspicuously”. There is no indication that it is not an image that is part of the article.
Michael,
Akamai has been one of several advertisers on this site for many months now. Currently, they are the only advertiser occupying that particular comment box ad spot, which is why their ad appears at the bottom of every story here at the moment.
“We want to be very clear that this data exposure is limited to our Cloud WAF product,”
Uhhh, thanks for clearing up literally the worst possible sentence ever.
“Just to be clear, the car crash only killed the occupants of the car and anyone nearby.” ?!?!?!
Their response reminded me of Councilman Dexhart from Parks and Rec. “I just want to be clear: in my defense, it was my birthday and I really wanted to do it.”
Imperva also provides an on-prem WAF product called SecureSphere, so the point of that sentence is to clarify that only Incapsula was affected, and even further, only Incapsula WAF users and not customers who use only the Incapsula DDOS protection and other Incapsula services. And to narrow it even further only WAF customers who had actually uploaded SSL keys might have had them exposed.
In fairness, Imperva provide other tools and services so I dont see anything wrong in emphasizing that only Cloud WAF related data had been exposed vs secure sphere for example.
“Scrambled passwords” does not equal “encrypted passwords!” What exactly is Imperva saying with this statement?
They didn’t say scrambled. I did. They said hashed, but I didn’t want to explain that in the lede.
It is helpful to customers using their other services. Now those customers can focus on finding another provider instead of having to scramble to clean up the mess like their Incapsula customers.
Having worked with a company that used imperva to monitor database activity in its PCI/PiFi zone… no, no it’s not the worst possible news from the company.
So… passwords and certs that have changed since 2017 are OK or what?
I was wondering about that. The way it’s cut off at a certain time/date makes me wonder if a test system seeded with old customer data was exposed, or if some old backups themselves were exposed.
It would be interesting to get a forensic analysis of this one day and, uh, what steps this allegedly professional cybersecurity firm is taking to prevent this sort of thing in the future.
Maybe an old laptop was stolen and a recent audit discovered it was missing.
Moral of the story is – NO data is safe these days. 🙁
I thought the moral of the story was: how good of a cybersecurity firm could they be, if they can’t keep their own computers from getting hacked? And it took a “third party” to point out to them that they had been hacked (were you that third party Krebs?). If I was there customer, I’d be immediately looking to replace them with another firm.
Besides Brian, it could also have been Hold Security, someone Brian has partnered with in the past. Reference https://krebsonsecurity.com/tag/hold-security/.
I’m glad you pointed that out! I was wondering the same thing. Why would it take a third party to report a breach to a company if they’re supposed to practice what they preach?
The truth is they have two WAFs. One on-prem and one in the cloud.
This is double exposure.
I don’t believe it is double exposure. Secure Sphere is a separate offering to Incapsula which was bought by Imperva a few years ago.
Certs and keys can be stored in hardware HSMs for on prem solutions.
In other news, cybersecurity firm Imperva announced today they are changing their name to Penetrova. /s
Dang. I thought I had the perfect pun all lined up but I was beaten to the punch by a better one.
LOL!!!
Too funny!
I wonder if instead of using usernames and passwords, they used Gibson’s SQRL technology would Imperva be protected?
Seems a little sad to salt and hash passwords, but leave the API keys and private certificates just hanging around in plain text.
Taken was “hashed and salted passwords”s …How was it hashed and how was it salted? The fact that they didn’t tout their rock solid data encryption makes me wonder if they are using something far less than rock solid. Were the salt values in the same database and also taken?
Imperva wouldn’t answer questions beyond what was in their public statement.
Salting just protects you from pre-calculated hash attacks. There is no benefit to storing the salt away from the hashed password.
But if the salt key is stored with the hash values, couldn’t a new Rainbow table be generated by taking known/popular passwords and salting them first to make the new table before doing a Rainbow attack? I would think you never want to store salts with the hashes. Either I have misunderstood your comment or I am lacking some knowledge about how the salts are used.
A salt is supposed to be unique for each user, not secret. The idea is that the attacker would either need to learn the salt used for that particular user and then create a rainbow table of all possible passwords for that unique salt, or create a separate table for every salt (and each of those tables would need to list every possible password). You’re trying to make the work needed greater than just downloading a pre-computed MD5/SHA/ETC rainbow table and using that against the entire database.
What you are looking for, that is a secret that is mixed with the users password before being hashed is called a pepper and is different to a salt. A pepper is generally the same for all users in that particular database and it should be protected in the same way as you would protect a private key. I hope that makes things clearer for you.
Excellent answer. I had never heard of a ‘pepper’ until now. I was also not aware that a ‘salt’ is unique for each user. I had assumed that an organization used the same ‘salt’ and applied it to each users password. Thank you.
+1 informative.
I don’t run a WAF, but I do have Nginx flag certain words that are obviously used in hacking. Even if you do have a WAF, I would also flag on keywords. For instance no request should have wget in it. I look at my error log to find new hacks and of course errors. Nginx also has a return code of 400 which catches a lot of hackers. If the IP is from a data center, they get on the banned list.
`According to Mogull, an attacker in possession of a customer’s API keys and SSL certificates could use that access to significantly undermine the security of traffic flowing to and from a customer’s various Web sites.`
So every customer had the same access to do the same ?
I don’t know Imperva, but seems they put more trust into their customers than they do.
“I don’t know Imperva, but seems they put more trust into their customers than they do.” What?
Sean’s fault
All it takes is One disgruntled employee, One corrupt employee……….Always the human factor…..Always
i suspect they didnt protect their app with the WAF . its easy to configured a filter on response , where the response contains emals , hashes , certificates etc
This isn’t the first Application Security company to encounter something like this. Cloudflare, Akamai, RSA, and many others have had this happen. My guess is that this was a legacy instance of their cloud they bought from Incapsula. I don’t see a company like this not having a defense in depth posture to their Web Apps. Especially the ones that run their own customers WAF deployments.
The first customer that runs to another vendor is simply running away cause they didn’t want to be there in the first place. If we faulted every security company and ran as soon as something “bad” happened we would have thrown our blackberry in the trash 16 years ago when there was a known breach of their NoC. We would have tossed our new iPhone in the tub when apple announced its OS has a known vulnerability that most likely was exploited by 1,000s of hackers. We would have never saw companies like Oracle or EMC grow up to be what they are today.
If you ask me, when something like this happens, this is the first company I would want to be with, as they know you can be forgiven 1 time only, and never again. There will be all hands on deck to ensure this never happens again. Orrrr run to a competitor who’s probably shifting their funds to marketing and off security simply to bait the hook and hope Imperva customers run. Those will be the vendors who make the news next but the breach will be a lot worse.
I don’t know about the others, but RSA wasn’t breached. It took a while for it to come out, but the NSA had them put in a back door. Which was of course found by malicious actors then exploited against the government…. We need a term for exploit installed at government’s request. EIGA, nah, something stupid and evil sounding is needed.
So take the away: don’t upload root certs to any cloud provider, use their MFA option; do not rely on just passwords and always test your API’s.
What is not 100% clear here is whether the SSL Certificates include the corresponding Keys. It is the Keys that are important and not the certificates, since anyone can get those from the site itself.
That;s why at the leading firm that talks about Zero Trust these days talks about ” Assuming a hostile environment~~~~ Always Verify Never Trust !
Shameless
Wait, his name is really Rich Mogull?
Seems like Rich Mogul should change his name to Poor Underling.
brilliant! I have known about this guy for years but never noticed it… rich mogul.
My strong feeling is the customer in question had not taken simple steps to secure the access to the Imperva Cloud portal. Thus the culpability will be as much with the customer as much as the vendor. This type of attack is as relevant to Akamai or any cloud WAF/DDOS provider.
Did the customer do something wrong here?
Symantec™ Managed Security Services (MSS): Quick Start Guide for Imperva® Incapsula WAF
HOWTO125888
Last Updated February 27, 2019
This quick start guide will help Symantec™ Managed Security Services (MSS) customers configure Imperva® Incapsula WAF to allow log collection from the Log Collection Platform (LCP).
The document includes the following topics:
Supported Versions
Port Requirements
Configuring Incapsula WAF
LCP Configuration Parameters
Supported Versions
A list of supported versions is available in the MSS Supported Products List document (Symantec_MSS_Supported_Products_List_CUSTOMER.xlsx) which can be found at: https://mss.symantec.com/PortalNextGen/Reports/Documents
Port Requirements
Table 1-1: Port requirements for LCP communication.
Source
Destination
Port
Description
LCP
https://my.incapsula.com/api/visits/v1
443 (TCP)
Default port
Configuring Incapsula WAF
For log collection, we need the API ID and API Key to authenticate Incapsula WAF through API. No other device configurations are required.
LCP Configuration Parameters
Table 1-2 The Incapsula WAF event collector properties to be configured by MSS are shown in the table.
Property
Default Value
Description
Incapsula URL
https://my.incapsula.com/api/visits/v1
Incapsula Get Visit API URL.
API ID (API authentication identifier)
Custom Value
The API ID mentioned in the Pre-Installation Questionnaire (PIQ) is based on the Incapsula account.
API Key
Custom Value
The API Key mentioned in the PIQ is based on the Incapsula account.
Number of visits to fetch
100
This is the count of visits the collector fetches from the Incapsula Cloud in a single call. The default value is 100.
– https://support.symantec.com/us/en/article.HOWTO125888.html
Not Always TECHNOLOGY to be blamed, Human factor as said in one of the comments.
This is a PR nightmare for Imperva. It’s likely we’ll never know how this happened because it will make the company look foolish or lacking goverance.
They haven’t even told their customers about the intrusion. They reset passwords. That’s it. No email communication and no banner’s in the Control Panel or anything.
Though I don’t think there’s an excuse for that at all, I wonder if they were trying to get all the details before they let the customers know. But, on the other hand, why would they have reset the passwords already if they were planning on letting their customers know to begin with? Seems as though they are horribly mismanaging this whole situation. Sadly, though, I doubt much will happen as a result.
Not true, they blasted all users of Imperva cloud. There was a huge massive email campaign. If anything, they over communicated
The motto is “not if you will get attacked, but when”. Security companies will get attacked too.
Salted hashes I would think are no big concern. If they were salting, they were probably using a good 256/512 bit hash algorithm. Active customers will have time to set new passwords before any (if at all) hashes are cracked.
The SSL certificates will be revoked (CRL) and reissued. They only contain Public keys. I’ll bet many of them were expired by Web Apps/Customers that are no longer supported or in use.
The API keys for those Web Apps/Customers still in use, though, I would think would be the bigger issue. Those may be private keys allowing more elevated access to the Web Applications. They’ll obviously be replaced too.
If the breach happened between August 20-28, then log files need to be examined for any of those September 15, 2017 customers that are still active.
That’s my thoughts anyway. I don’t feel any animosity towards Imperva yet, or any security firms unless negligence is shown. Cloud providers are big targets.
Just read that Hostinger got exposed August 23, after non-authorized access to an API server exposed 14M passwords using the older SHA-1 hash with customers now being asked to reset passwords using SHA-256. Any relation?
Imperva has great case studies of their customers in case anyone is thinking of signing up with them.
https://www.imperva.com/resources/customers/
Brian,
Not sure having disrupt ops as a security authority source is a great idea.
Disrupt’s basic security posture is truly terrible. They can’t even get basic ssl config right.
https://observatory.mozilla.org/analyze/disruptops.com
Are there any cloud providers with security that isn’t horrible?
That says it all to me Andrew – I’d never do business with them!!
Please, please can we not say they stole ‘certificates’ when what was probably stolen was their private keys. Certificates contain public keys only. And yes, private keys in clear text is an abomination, but seems to be common in cloud environments.
I’d say the fact the Certificates have been compromised, actually means RSA Private keys have been exposed. Which means they’ve been pretty well owned. And going from experience the perps have probably been in for 3 months or more. I wonder what ticked them off about it… it would’ve been a gold mine for whoever got in.
In layman’s terms this is similar to a crook breaking into a police station and making away with the complains book unscathed and unnoticed. Quite embarrassing and scary.