A security firm published a blog post today explaining how they compromised an endpoint security system. The vendor, Carbon Black, responded in a blog post explaining that this feature is off by default and customers receive a warning when they turn it on.
Setting aside the topic of responsible disclosure for the moment, take a look at this statement in the research firm’s blog post:
“We noticed that the other files were all uploaded by a similar uploader. This service obscures the uploader behind an API key, in this case: 32d05c66.”
As I mention in this past article on wireless security, encryption, authentication, and authorization all become useless if someone can steal the key used in the process. The key unlocks all those protections. This disclosure shows what happens when an attacker gets a key and uses it to compromise a system.
A Key Is a Password – Protect It!
Attackers are not brute-forcing keys in many cases, they are simply finding them. The key could be an SSH key, an API key, an encryption key, an identity key, or any other type of key that grants access to a system or data. A key is a password. Keys are the equivalent of a front door lock on a house. If malicious people get ahold of that key they can get in with ease. No need to break your windows or pick your lock.
To prevent stolen keys, limit who knows and can access those keys. Storing keys in source control is a very bad idea. Avoid sharing keys. Don’t let anyone touch the keys at all if possible. Design a system that generates keys with no humans in the process whatsoever and no humans have access to key storage or backup locations. Prevent programmatic access to keys via malicious or untrained programmers as well.
Store encryption keys in systems designed for proper key storage such as Venafi or an HSM (Hardware Security Module). Hardware vendors can store keys in specially designed key storage components call a TPM (Trusted Platform Module). In the cloud, Amazon offers two key storage services: KMS and CloudHSM. Azure has a service called Key Vault. Google has a Cloud Key Management Service.
Architect Systems and Processes to Protect Keys (and Key Identifiers)
According to the disclosure blog post, the implementation of the Carbon Black system does not consider that a single key can compromise the whole system. If one person were to hack his or her own key by looking at the API and figuring out the key, that would be no big deal. That customer would be able to hack his or her own data. Knock yourself out! But when the same key allows access to whole system, then an attacker can access everyone’s data using that single key. In one Twitter response to a posted article, a person notes that the item disclosed is not a key, but a key identifier. If the key identifier allows access to the system it is just as good as a key.
One recommendation would be to have each customer use a different key rather than having one key used by every single customer. A good approach for ensuring one key does not compromise the whole system is via the use of key hierarchies. Amazon explains key hierarchies in a blog post related to their Cloud HSM service.
Companies should consider not if, but when attackers steal keys how they will respond. A good key rotation process will allow a company to quickly mitigate the problem. Monitoring and a way to quickly shut down access when a compromise is taking place will help too. — Teri Radichel (@teriradichel)
Related articles:
Pentest firm calls Carbon Black “world’s largest pay-for-play data exfiltration botnet”
DirectDefense Incorrectly Asserts Architectural Flaw in Cb Response
API Keys ≠ Security: Why API Keys Are Not Enough
OWASP Cryptographic Storage Cheat Sheet
OWASP REST Security Cheat Sheet
A Look Inside Responsible Disclosure
“Keys are the equivalent of a front door lock on a house.” I think you may have meant to say: “Keys are the equivalent of a house key to the front door lock on a house.”
Yes! I did notice that and meant to go back and fix it. Hopefully most people could make the leap 🙂 Thanks