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.
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 -
Acknowledgments: Name: Dagan Henderson (Akoya, LLC)
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
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
External References: https://kiali.io/news/security-bulletins/kiali-security-001/
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.