Bug 1810383 (CVE-2020-1764)

Summary: CVE-2020-1764 kiali: JWT cookie uses default signing key
Product: [Other] Security Response Reporter: Mark Cooper <mcooper>
Component: vulnerabilityAssignee: Red Hat Product Security <security-response-team>
Status: CLOSED ERRATA QA Contact:
Severity: high Docs Contact:
Priority: high    
Version: unspecifiedCC: gmollett, kconner, mazz, rcernich, security-response-team
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
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.
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-03-26 04:31:50 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On:    
Bug Blocks: 1810199    

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

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

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):


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


Comment 19 RaTasha Tillery-Smith 2021-04-23 11:52:21 UTC

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.