Send Attackers Phishing Somewhere Else
A few years ago, I heard a keynote by Eleanor Saitta where she asked the question “How fast can you burn out a compromised user?”, and which she posited that anything longer than one minute was just too long. After I picked my jaw up off the floor, I realized that traditional credentials management within the scope of any complex system was just being managed too haphazardly, and change was the order of the day.
So just how do we manage credentials, and why is that bad? Or better yet, what are credentials and why are they important within the scope of building a system?
Anyone who has conducted any business transaction on the internet should be familiar with the most basic form of credentials, that of a username and password. Websites use these to uniquely identify an individual for the purpose of conducting business with them, this process is called authentication. Once an individual has been identified, or authenticated, then they are authorized to conduct some specific actions on a site, for example buying a pair of shoes, or a new hard drive.
The same basic concept is used within systems. Take for example a database that contains very sensitive data, a website application would need to authenticate with the database in order to identify itself for the purpose of reading or writing data to and from the database. Just like a website account, a database issues credentials in the form of a username and password, and a website application identifies itself to the database by presenting these credentials.
So now credentials management comes into the picture. The developer of the website application needs to provide one or more instances of the application with credentials to a database. So just how does one do that? Perhaps a configuration file stored on the file system of a server? For example, if you are using Apache Tomcat as a web application container, you might be tempted to do something like this in the server context XML file:
<Resource name="jdbc/myoracle" auth="Container"
type="javax.sql.DataSource" driverClassName="oracle.jdbc.OracleDriver"
url="jdbc:oracle:thin:@127.0.0.1:1521:mysid"
username="scott" password="tiger" maxTotal="20" maxIdle="10"
maxWaitMillis="-1"/>
There are several problems with this. First, how do we ensure that file is only viewable by those who need to view it (think locking down SSH access to the server to specific groups of people)? And which of your users need that type of access to your hosts, and are those users different for hosts in different environments (dev, test, production)?
A typical organization may have multiple people supporting the website application in a production environment that is configured like the example above, where those people all need to know what the database username and password are for this particular application. In fact, there may be dozens of applications like this in the production environment, perhaps each with its own username/password combination, or perhaps sharing, or most likely some combination of per-application credentials and shared credentials. These multiple people who support this website application must be able to configure the application properly, which means ensuring the application has the correct set of credentials to identify itself with the database, and thus each one of these people would need read access to these credentials in order to be able to create the context configuration like the example above.
So what happens if one of those people record those credentials in a plain text file on their work laptop? What if someone else is able to access that person’s laptop and find that plain text file?
According to an article from infosecurity-magazine.com “A full 80% of data breaches are caused by silly mistakes by those responsible for managing secrets … It’s not that the adversaries are so sophisticated.” This means that those people we trust to keep our secrets safe are the #1 easiest target of attack for a would be intruder, and Phishing is their game.
But ask these people who are responsible for managing these secrets if they even care what those secrets are? Most of them, outside of ensuring the system operates successfully, would probably rather not even have to know what those secrets are.
Enter Hashicorp’s Vault into the equation. Vault is Security as a Service, and provides a variety of functionality to address many common issues with credentials management. Going back to how we started this conversation, what if a website application could just dynamically obtain credentials for interacting with a database and throw them away when it is done using them, and what if that usage window is less than one minute of time? Even if an attacker somehow managed to get their hands on a username and password, and even if they knew which database those credentials were for and had a network path to that database, the credentials would expire by the time the attacker could actually attempt to use them. Setting up credentials management in this manner gives the website application a very strong security posture. This functionality is provided by Hashicorp Vault in the form of dynamic credentials, provided through a secrets engine.
As an example of dynamic credentials, take a look at a real HTTP request sent to a Vault service to obtain a username and password for a MySQL database:
$ curl --header "X-Vault-Token: 7b7dd433-01cc-f716-8cf8-35e57ffc0d6b" https://vault.somedomain.com/v1/database/creds/my-role | jq '.'
{
"request_id": "947aa9ca-4518-1ba9-bd0f-44e7b133a043",
"lease_id": "database/creds/my-role/8568b2c6-b967-296a-ceb1-baa6a60b35c3",
"renewable": true,
"lease_duration": 60,
"data": {
"password": "A1a-TgFA8MyrR1dAffCP",
"username": "v-root-my-role-oOBwwjM8P7ydGp07j"
},
"wrap_info": null,
"warnings": null,
"auth": null
}
$
Imagine that HTTP request being made by a web application instead of curl (see graphic below), and now our organization no longer needs its support staff sharing database credentials with each other in order to deploy and manage our web application, and no longer has to take the risk of any credentials leaking out. And even if credentials leaked, they would expire in less than 60 seconds anyway, or maybe less time.
The example in the graphic above presents one use case of using a Vault secrets engine for a MySQL database. However, Vault supplies many other types of secrets engines across a wide array of technology and online services. One such example is Vault’s AWS secrets engine, which can be used in a manner similar to the MySQL database secrets engine, shown in the graphic above, in providing AWS secrets to an application. A possible use case for that is a non-cloud service that needs to access the AWS API using time limited IAM credentials.
Vault provides a variety of other functionality to complete the As a Service picture including, but not limited to, encrypted secrets storage, secrets cubbyholing, secrets revocation, secrets access auditing, and declarative policies for secrets provisioning. Vault cubbyhole, for example, is a powerful mechanism for securely providing the Vault token, a credential used by a service when it requests dynamic database credentials from Vault, in a way such that a service provisioner doesn’t even have to know the credentials being provided to a service it is provisioning. Also, with declarative policies, Vault can ensure that some services can obtain dynamic database credentials while other services can’t.
And finally, a highly available Vault service can easily be provisioned using Hashicorp Terraform, taking all of the pain away from getting started using it. Foghorn Consulting has built such a Terraform module for assisting our clients in deploying a Vault service. Contact us here and we can assist you with getting going quickly.
Stay tuned for a future blog post on Vault’s cubbyhole.
