Elastic Support Alert: Kibana Reporting Vulnerability

By
Elastic Engineering

Elastic has recently identified that the Kibana reporting feature used to generate PDF reports unintentionally transmits user authentication credentials (i.e., Kibana username and password in reversible hashed format) in the HTTP headers used to request data from external resources whose data may be incorporated into the report.

Background

User credentials are encrypted at rest by Kibana and are intended for use to authenticate to an Elasticsearch server to generate reports but are not intended to be transmitted to external resources. However, in this case, the HTTP headers used to request data from external resources in connection with the Kibana PDF reporting feature also included user credentials. The types of external resources or services that may be reported in Kibana include web proxies, Kibana URL field formatters, Timelion visualizations, markdown, Vega visualizations and mapping services.

To address this issue we have released ESA-2018-17 (CVE-2018-17245), Elastic Stack versions 5.6.13 and 6.4.3 contain fixes for this issue.

Affected Users

This issue affects Kibana users on versions 4.0 to 4.6, 5.0 to 5.6.12, and 6.0 to 6.4.2 of the Elastic Stack for both self-managed and hosted deployments. It affects users who have used Kibana’s PDF reporting feature to include data from external resources. It is not triggered by requests to generate CSV reports.

Recommend Changing User Credentials

While requests to some of the external resources may have been conducted via HTTPS using encryption, there can be no assurance that all requests were encrypted and, in any event, the credential would have been exposed to external resource provider following receipt of such request. We note that we are not aware of any unauthorized use or access associated with any of the affected user credentials. Nevertheless, consistent with security best practices and as a precautionary measure, we recommend that all affected users change affected credentials.

Recommended Actions

If you are an affected Kibana user (i.e., (i) you have used Kibana’s PDF reporting feature to include data from external resources) and (ii) you are on one of the affected versions described above, then you should consider changing your credential as described below.

Native Realm

This recommendation applies where users have used the "native" registration feature of the Elastic Stack, i.e., have registered using the Kibana user management interface and have created a unique username and password at the time of registration. If you are native realm user of Kibana then your user details are stored in an Elasticsearch index. This means that the individual user can change his or her credentials directly using the Kibana user management interface or, alternatively, the Elastic Stack administrator can change all user credentials via an Elasticsearch API.

Please note that native is the default security realm for customers of our Elasticsearch Service on Elastic Cloud.

File Realm

This recommendation applies where the Elastic Stack is configured to use file based user authentication. Users are managed via the ‘user’ command line utility shipped with Elasticsearch. The Elastic Stack administrator must change all user credentials using command line tools.

LDAP and Active Directory Realms

This recommendation applies where the Elastic Stack administrator has enabled user registration utilizing user credentials stored in LDAP and Active Directory. Because these user credentials affect more services than just the Elastic Stack, all affected users should be instructed to change their user credentials for LDAP and Active Directory.

SAML Realm

The SAML realm is not affected by the plaintext disclosure flaw, but a session replay attack does affect the SAML realm. The SAML realm uses a pair of tokens: access tokens and refresh tokens. Access tokens are short lived (20 mins), but refresh tokens can be valid for at most 24 hours and can be used to get new access tokens. To address this potential attack, we have provided instructions (later in this blog) on how to expire SAML refresh tokens.

PKI and Kerberos Realms

The PKI and Kerberos realms are not compatible with Kibana at this time and are not affected by this flaw.

Custom Realms

If you have a custom realm you should review the authentication process to decide what actions should be taken.

Instructions for Expiring SAML Refresh Tokens

Depending on number of tokens/users you may need to scroll. This is per SAML realm:

curl -uelastic -X GET "https://localhost:9200/.security/_search?pretty" -H 'Content-Type: application/json' -d' 
{
    "query": {
        "bool": {
            "filter": [
              { "term": { "doc_type": "token" } },
              { "term": { "access_token.realm": "<NAME OF SAML REALM>" } },
              { "term": { "refresh_token.invalidated": false } }
            ]
        }
    },
    "_source": ["refresh_token.token"]
}
'

Each result from this query will contain a refresh token that needs to be invalidated. Invalidate each token by:

curl -uelastic -X DELETE "https://localhost:9200/_xpack/security/oauth2/token" -H 'Content-Type: application/json' -d'
{
  "refresh_token" : "<REFRESH TOKEN HERE>"
}
'

Going Forward

Elasticsearch 5.6.13, 6.4.3, and above come with a bug fix for this vulnerability. If you are unable to upgrade, be sure to follow the recommended actions above.

Subscription customers are encouraged to reach out to their support contact. If you have questions, please visit our forum.