In the two days since JumpCloud sent out a tweet to its customers that it was invalidating its API keys, there is still no word on what kind of security incident the cloud-based directory services company was experiencing.
However, security researchers contacted by SC Media did say companies don’t revoke API keys lightly and that reinstalling the API keys could cause up to several minutes or several hours of downtime since applications tied to JumpCloud would not work while the keys are reinstalled.
Based on the limited information available right now, JumpCloud has reason to believe that the admin API keys for some customer accounts were leaked somehow from their servers, explained Krishna Vishnubhotla, vice president of product strategy at Zimperium. Vishnubhotla said once they reset the admin password, that customer needs to re-generate all the keys on their end that are derived from the admin key.
“And that is where the pain is, as all the enterprise applications using these keys immediately stop working,” said Vishnubhotla. “This normally means customer personnel most likely can't log in and/or access enterprise applications necessary to log in, work and be productive remotely. It could bring work to a standstill across the entire company.
Nick Rago, Field CTO at Salt Security, added that invalidating all the API keys could potentially disrupt all systems relying on this API for operation, management and administration of single sign-on (SSO), MFA, password management, and device management with the JumpCloud platform. Because thousands of organizations rely on this platform for management of these critical services, the customer impact is potentially severe, Rago said.
“Other than a notice that API keys were invalidated and must be reset, and an apology for any disruption, there doesn't seem to be much transparency at this time into what the security incident was or how long API keys might have been potentially exposed, or how they are remedying this type of incident from happening again,” said Rago. “However, the incident must have been pretty significant for JumpCloud to take this action across its whole customer base. To give some context, a JumpCloud API key in the wrong hands could compromise the administration and configuration of key directory and identity services for an organization.”
Rago added that many organizations rely on the cloud-based service provider's APIs to manage key critical infrastructure and business-driving services every day. He said this incident serves as a reminder that organizations should ask their cloud service providers for an option to lock down API access to their account from a limited whitelist of locations, to limit any risk of an adversary causing harm if they accessed a privileged API key.
Zimperium’s Vishnubhotla said to protect data, businesses typically try to select encryption algorithms that are as robust as possible. However, most app teams don't take the time to ensure the resulting cryptographic keys are safe at-rest, in-motion, and in memory.
“The problem is further amplified on mobile devices because we see many popular apps embedding keys in the application,” said Vishnubhotla. “Furthermore, app teams rely on secure hardware on the device to keep the keys safe, which cannot be trusted if the device is compromised. API keys are similarly exposed, embedded in an application, making them vulnerable to theft when reverse-engineered and inspected.”
Murali Palanisamy, chief solutions officer at AppViewX, said invalidating API keys pretty much locks the customers out of the identity provider. Palanisamy said a potential exploit of API keys can have a wide-ranging impact, depending on the access levels and controls that are in place.
“It can be as simple as access to dashboard and visibility into different login reports to potentially elevating access to a takeover of the complete environment, especially with a cloud-based identity provider,” said Palanisamy. “Though there are controls in place to protect the API keys and tokens, adoption of more dynamic and ephemeral keys is not widespread.”
.
