• Articles
    • Editorial Articles
    • Research Articles
    • WatchGuard Articles
  • The 443 Podcast
  • Threat Landscape
  • About
    • About Us
    • Contact Us
    • Contribute to Secplicity

Secplicity - Security Simplified

Powered by WatchGuard Technologies

Carbon Black Data Leaks – A Good Reminder to Protect Keys

August 9, 2017 By Teri Radichel

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.

Protect encryption and authentication keys

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

Share This:

Related

Filed Under: Editorial Articles Tagged With: api, carbon black breach, Cloud, cloud security, data leak, DLP, key, keys, Sandbox, sandboxing, security

Comments

  1. Nobody says

    August 10, 2017 at 11:17 am

    “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.”

    Reply
    • Teri Radichel says

      August 16, 2017 at 5:45 am

      Yes! I did notice that and meant to go back and fix it. Hopefully most people could make the leap 🙂 Thanks

      Reply

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

The 443 Podcast

A weekly podcast featuring the leading white-hat hackers and security researchers. Listen Now
the 443 podcast

Threat Landscape

Filter and view Firebox Feed data by type of attack, region, country, and date range. View Now
threat landscape

Top Posts

  • US National Cybersecurity Strategy
  • Cybersecurity’s Toll on Mental Health
  • Cybersecurity News: Free Cybersecurity Training, TrickBot Group Exposed, Major GoDaddy Breach, and Russia to Legalize cybercrime?!
  • Here Come The Regulations

Email Newsletter

Sign up to get the latest security news and threat analysis delivered straight to your inbox

By signing up you agree to our Privacy Policy.


The views and opinions expressed on this website are those of the authors and do not necessarily reflect the policy or position of WatchGuard Technologies.

Stay in Touch

Recent Posts

  • Here Come The Regulations
  • US National Cybersecurity Strategy
  • Cybersecurity News: Free Cybersecurity Training, TrickBot Group Exposed, Major GoDaddy Breach, and Russia to Legalize cybercrime?!
  • Cybersecurity’s Toll on Mental Health
  • Successfully Prosecuting a Russian Hacker
View All

Search

Archives

Copyright © 2023 WatchGuard Technologies · Cookie Policy · Privacy Policy · Terms of Use