It’s not a surprise when saying that secrets should be stored securely in vaults and password managers. However, as human beings, we’re all susceptible to mistakes such as committing secrets in Git, pasting secrets over Slack etc. Detecting leaked secrets is something that InfoSec teams are always on the lookout for. Detecting hashes is not an easy task and can be operational intensive! Even if a secret detector is configured, it will return a lot of false positives.
Over the last few months, a sneaky feature was released in Elastic Cloud. Over the past months, the InfoSec team together with the Elastic Cloud Platform team has been working on adding a 4-letter prefix to Elastic Cloud API keys. Searchable API keys using prefixes are not something new to the industry as such features are already implemented by organizations such as GitHub and Slack. While such an update could be seen as a small one, it has numerous advantages for InfoSec teams leveraging secret scanning platforms.
The 4 letter prefixes are the following:
essu_: This is for Elastic Cloud API Keys
The following is a regex that one can leverage to detect Elastic Cloud API Keys
^essu_(?:[A-Za-z0-9+\/]{4})*(?:[A-Za-z0-9+\/]{4}|[A-Za-z0-9+\/]{3}=|[A-Za-z0-9+\/]{2}={2})$
The following API call can be used to validate the key:
curl --location 'https://api.elastic-cloud.com/api/v1/deployments' \
--header 'Accept: application/json' \
--header 'Authorization: <APIKEY>'
If the key is valid, the response should be something like the below:
{
"deployments": [
{
"id": "ab8bccce810b4eb4824a18a9221fdf5f",
"name": "Lab",
"resources": [
{
"ref_id": "main-elasticsearch",
"id": "668d892c50a14c798c34e09c5b32b7d8",
"kind": "elasticsearch",
"region": "gcp-us-central1",
"cloud_id": "Lab:dXMtY2VudHJhbDEuZ2NwLmNsb3VkLmVzLmlvOjQ0MyQ2NjhkODkyYzUwYTE0Yzc5OGMzNGUwOWM1YjMyYjdkOCRkYjY4YjZmM2MwNTE0NjI2YTQ5NjhiZDhjOGE2MGFlOA=="
},
{
"ref_id": "main-kibana",
"elasticsearch_cluster_ref_id": "main-elasticsearch",
"id": "db68b6f3c0514626a4968bd8c8a60ae8",
"kind": "kibana",
"region": "gcp-us-central1"
},
{
"ref_id": "main-integrations_server",
"elasticsearch_cluster_ref_id": "main-elasticsearch",
"id": "0d2bf192c0254bfe9633627d9f44d232",
"kind": "integrations_server",
"region": "gcp-us-central1"
}
]
}
]
}
Otherwise, if the key is not a valid one, the response should be something like the below:
{
"errors": [
{
"code": "root.unauthenticated",
"message": "The supplied authentication is invalid"
}
]
}
We know that this improvement might be a small one, however, such a feature will help secret scanning processes detect any exposed Elastic Cloud User API keys. This update is one of many more related tasks that will continue to improve the security posture of Elastic and our customers.