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: 2021-04-23 11:52 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. 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 Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2020:0975 0 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 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/

Comment 19 RaTasha Tillery-Smith 2021-04-23 11:52:21 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.


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