Bug 1810383 (CVE-2020-1764) - CVE-2020-1764 kiali: JWT cookie uses default signing key
Summary: CVE-2020-1764 kiali: JWT cookie uses default signing key
Keywords:
Status: CLOSED ERRATA
Alias: CVE-2020-1764
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
high
high
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks: 1810199
TreeView+ depends on / blocked
 
Reported: 2020-03-05 06:25 UTC by Mark Cooper
Modified: 2020-04-15 23:19 UTC (History)
5 users (show)

Fixed In Version: kiali 1.15.1
Doc Type: If docs needed, set a value
Doc Text:
A hard-coded cryptographic key vulnerability in the default configuration file was found in Kiali, versions 0.4.0 to 1.15.0. A remote attacker could abuse this flaw by creating their own JWT signed tokens and bypass Kiali authentication mechanisms, possibly gaining privileges to view and alter the Istio configuration.
Clone Of:
Environment:
Last Closed: 2020-03-26 04:31:50 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2020:0975 None None None 2020-03-25 22:42:37 UTC

Description Mark Cooper 2020-03-05 06:25:28 UTC
A vulnerability was found in Kiali v1.9 where the default signing key for JWT cookies is known in the source. A session can be spoofed without user information and the authentication mechanism of Kiali bypassed.

Comment 4 Mark Cooper 2020-03-09 06:42:48 UTC
Mitigation:

The Kiali configuration can be manually updated for ServiceMesh so that the default signing_key cannot be easily determined:

oc get kiali -n $(oc get kiali --all-namespaces --no-headers -o custom-columns=NS:.metadata.namespace) -o yaml | sed "s/spec:/spec:\n    login_token:\n      signing_key: $(chars=abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890; for i in {1..20}; do echo -n "${chars:RANDOM%${#chars}:1}"; done; echo)/" | oc apply -f -

Comment 8 Guilherme de Almeida Suckevicz 2020-03-19 16:34:16 UTC
Acknowledgments:

Name: Dagan Henderson (Akoya, LLC)

Comment 10 Mark Cooper 2020-03-23 02:27:52 UTC
Statement:

If exploited an attacker can perform all Kiali admin functions via the API including:
 - View the logs of a pod
 - View Istio metrics, tracing etc.
 - Alter Istio routing configurations:
     - Change the pod availability: adding variances to the weighting, i.e. all traffic goes to 1 pod, or 95% of all traffic. 
     - Prevent traffic reaching a pod, DoS

Whilst OpenShift ServiceMesh Kiali uses the default signing key for JWT cookies, it also includes an access_token. This token is generated with a successful login and cannot be easily determined. 

To access the Kiali API in this case, a valid session token would need to be captured first and then added to the JWT cookie.

Comment 16 errata-xmlrpc 2020-03-25 22:42:36 UTC
This issue has been addressed in the following products:

  Openshift Service Mesh 1.0

Via RHSA-2020:0975 https://access.redhat.com/errata/RHSA-2020:0975

Comment 17 Product Security DevOps Team 2020-03-26 04:31:50 UTC
This bug is now closed. Further updates for individual products will be reflected on the CVE page(s):

https://access.redhat.com/security/cve/cve-2020-1764

Comment 18 Mark Cooper 2020-03-26 06:36:25 UTC
External References:

https://kiali.io/news/security-bulletins/kiali-security-001/


Note You need to log in before you can comment on or make changes to this bug.