Secure Credential and Certificate Management for Data Pipelines

Authors: Matthew Hall, Brian Waskiewicz, and Mike ForgioneThreat intelligence feeds and other sensitive data pipelines found in many contexts make use various different Authentication methods to protect data when transferred or at rest.Some examples of these methods are:<ol><li>Totally Unauthenticated</li><li>Unique / Secret HTTP file path</li><li>Proprietary HTTP Headers</li><li>Proprietary Login APIs</li><li>HTTPS with HTTP Basic Authentication</li><li>HTTPS / SSL/TLS with Client Certificate (and Private Key)</li><li>SSH / SCP / SFTP / RSYNC Private Keys</li></ol>The wide range of authentication complicates the secure software development process. One must consider the TLP (Traffic Light Protocol) restrictions, cryptographic best practices (such as PCI or FIPS requirements), and system hardening (such as NIST recommendations), to create a secure solution.<h2>Secure Credential Storage</h2>The most secure methods for accessing sensitive data, such as HTTP Basic Authentication and TLS Client Certificates, or SSH infrastructure, require secure credential storage to allow automated access to a data pipeline.Secure credential storage consists of:<ol><li>a keystore, which is an encrypted file or database managed by a security library. A FIPS-compliant keystore does not allow direct access to keying material to protect the credentials during use.</li><li>a passphrase, which is stored in a separate location from the keystore, itself, to protect the credentials at rest.</li></ol>When these requirements are met, it greatly complicates the process of credential exposure and/or exfiltration, or in the case of a hardware implementation, can potentially guarantee exfiltration is impossible.<h2>Common Implementation Issues</h2>Sadly, most popular software development reference sites, such as StackOverflow, Github projects, open-source code, programing language API guides, etc. recommend some or all of a series of common unsafe practices, which will increase the risk of compromise as well as making it difficult to certify for PCI and FIPS compliance:<ol><li>Storing credentials in source control or source code repositories: adversary groups regularly take advantage of credentials and certificates located in source code checked out on compromised endpoints, and use it to fan out and infiltrate critical security and operations infrastructure at large target organizations.Database credentials were stolen from a GitHub repository and used to exfiltrate personal information regarding 50,000 Uber drivers:<a href="http://arstechnica.com/security/2015/03/in-major-goof-uber-stored-sensitive-database-key-on-public-github-page/">Uber Database Credential Theft</a>An Adobe code signing certificate was stolen and used to sign malware. Users were tricked into installing the malware, because it appeared to come from Adobe:<a href="http://blogs.adobe.com/security/2012/09/inappropriate-use-of-adobe-code-signing-certificate.html">Adobe Code Signing Certificate Theft</a></li><li>Passing credentials as command line arguments: credentials in command lines are accessible to anyone who can execute "ps auxww" on a system, including the cracker that happened to find a shell-injection attack against your web server or web stack, and any other unexpected unprivileged users.There are a few programs which overwrite the arguments or retitle themselves with <code>setproctitle()</code> after reading the credentials, but it isn't a complete guarantee since a patient adversary can still catch them in the clear early in the process's life, or by disrupting or slowing the process during launch.</li><li>Storing certificates and private keys in unsafe formats: unprotected certificates and private keys are easily accessible to anyone who can read them from the filesystem. Many daemons load them as root before dropping privileges, but often retain access after privileges are dropped, to use them during processing, where an attacker can access them if the daemon is exploitable.This happens often in HTTPS servers and SSH environments.Most of the classic HTTPS servers don't support keystores, or require entering passwords during boot, which is cumbersome. SSH agents are hard to configure, and don't have good support for headlessly entering the passphrases needed for automated access.For SSH at least, one can use some special extensions to the <code>authorized_keys</code> file format to restrict the purpose and scope of headless SSH keys to prevent misuse. This is explained in the <code>sshd(8)</code> man page section, <code>AUTHORIZED_KEYS FILE FORMAT</code>.<a href="http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man8/sshd.8"><code>sshd(8)</code> man page</a></li><li>Disabling critical SSL/TLS protections for data in transit: most widely-available example code and a lot of open-source code disables SSL/TLS hostname verification and SSL/TLS certificate path validation, as defined in RFC 5280, which should never be disabled in production systems. Data that transfers through unvalidated connections is vulnerable to MITM attacks, thus it cannot be trusted anymore:<a href="http://www.rfc-editor.org/rfc/rfc5280.txt">RFC 5280: PKIX (Public Key Infrastructure for X.509)</a></li></ol><h2>Mitigating the Risks</h2>Running software that relies upon unsafe code is a security risk and a liability risk, as well as a business risk. It also cannot be sold to the US Government and many highly-security-conscious organizations. Fortunately, the industry developed a small number of platform-independent techniques for secure credential storage to mitigate these risks:<ol><li><code>libnss</code> with <code>nss-db</code> and <code>libsecmod</code>: this is the only popular open-source multi-language multi-platform cryptography and SSL/TLS library with an integrated FIPS-compliant keystore. OpenSSL, GnuTLS and most other libraries do not offer much assistance with these requirements. Because of this <code>libnss</code> is widely used in browsers.<a href="https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS">NSS Library Home Page</a>Several technology vendors have banded together to ensure libnss is FIPS-validated:<a href="https://wiki.mozilla.org/FIPS_Validation">NSS Library FIPS Validation</a> <a href="http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140crt/140crt1280.pdf">NSS Library FIPS Certificate</a>Developers can also use NSS bindings available for Java (see below) and Python. We would love to know if anyone is aware of additional bindings.</li><li>Java <code>PKCS#11</code> provider (includes support for NSS and smartcard / HSM): this is the gold standard for high-security operations in Java. This includes any of the following:<ul><li>Tomcat, JBoss, Glassfish, Grizzly, or other J2EE servers</li><li>JCE, JSSE, Bouncy Castle and other popular cryptographic frameworks</li><li>any other JVM-based environments (Groovy, Scala, Jython, JRuby, etc.)</li></ul><a href="http://docs.oracle.com/javase/8/docs/technotes/guides/security/p11guide.html">Oracle Java 8 PKCS#11 Guide</a>Developers can use this adapter with NSS or another FIPS-certified <code>PKCS#11</code> device to get a FIPS-certified solution.</li><li><code>PKCS#12</code> cryptographic archive file format: this format is not necessarily as heavily-secured and feature-rich as the other formats, but still provides great protection and works in the widest range of environments, because it has been around the longest.</li></ol><h2>Practical Example</h2>Recently, we needed to access a data pipeline which used a <code>PKCS#12</code> containing an SSL/TLS Client Certificate and Private Key, from inside of a Python application.We decided to use <code>pycurl</code> because we had existing products that used it, so it was simpler than using NSS, and it provided sufficient security for the type of data pipeline we were building.Fortunately, <code>pycurl</code> can be configured to access a <code>PKCS#12</code> keystore with a passphrase protecting the Client Certificate and Private Key. However the configuration and troubleshooting process was somewhat difficult due to a usability bug in <code>libcurl</code> itself, which we fixed and released to the community:<a href="https://github.com/bagder/curl/pull/208"><code>curl</code> pull request to improve <code>PKCS#12</code> errors</a>When troubleshooting our code sample sample below, we found that three different failure points in the <code>PKCS#12</code> load process used the same non-specific error message, <code>unable to use client certificate (no key found or wrong pass phrase?)</code>. This made it difficult to determine the true cause of a failure in the <code>PKCS#12</code> initialization process. In our patch we added separate messages for each, and logic to retrieve a more detailed error from inside OpenSSL itself for more detail.This code sample loads a <code>PKCS#12</code> file in <code>pycurl</code>, and uses the credentials to access a target URL:<pre> <code>import cStringIO import pycurl request = pycurl.Curl() response = cStringIO.StringIO() request.setopt(pycurl.URL, request_url) request.setopt(pycurl.SSLCERTTYPE, "P12") request.setopt(pycurl.SSLCERT, pkcs12_file_path) request.setopt(pycurl.SSLKEY, pkcs12_file_path) request.setopt(pycurl.SSLKEYPASSWD, pkcs12_file_passphrase) request.setopt(pycurl.WRITEFUNCTION, response.write) request.perform() </code></pre><h2>Conclusion</h2>We encourage everyone to take a little time to think about the sensitive data in a system while it is in transit, in use, or at rest. We enjoy working with the security and technology industry to set good examples, and educate developers about safe ways to handle sensitive credentials. We will keep encouraging everyone to build data pipelines that are secure by default.