Vulnerabilidades de riesgo crítico y moderado en kiali afecta a Red Hat OpenShift Service Mesh

kiali es una herramienta Open Source, que permite visualizar la configuración, supervisar el tráfico y analizar los elementos rastreados de todos los servicios disponibles, permitiendo a los usuarios ver las vías de comunicación entre estos servicios, cómo se gestionan y cómo fluye el tráfico casi en tiempo real, facilitando la gestión y la resolución de problemas, esta herramienta es utilizada por OpenShift Service Mesh de Red Hat.

¿Qué pasó?

Recientemente se ha publicado dos vulnerabilidades en kiali, las cuales han sido identificadas y catalogadas como CVE-2020-1764 de riesgo crítico y CVE-2020-1762 de riesgo moderado, las mismas afectan a las versiones anteriores a 1.15.1 de kiali, que a su vez afectan a Openshift Service Mesh 1.0 para RHEL 7 x86_64 de Red Hat.

El CVE-2020-1764, existe debido a que en el archivo predeterminado de configuración de kiali se encontró una vulnerabilidad de clave criptográfica codificada, un atacante remoto que logre descubrir esta clave, podría utilizarla para crear sus propios tokens JWT firmados, así omitir los mecanismos de autenticación de kiali y realizar todas las funciones de administración a través de la API, como por ejemplo:

  • Ver los logs de un pod.
  • Ver métricas Istio, seguimientos, etc.
  • Alterar las configuraciones de enrutamiento de Istio, como:
    • Cambiar la disponibilidad del pod, agregando variaciones a la ponderación, y
    • Evitar que el tráfico llegue a un pod.

Desde Red Hat afirman que el OpenShift ServiceMesh hace uso de esta clave de firma, pero también incluye un access_token, el cual es generado a partir de un inicio de sesión exitoso, por lo que el atacante primero debería capturar el access_token válido y luego crear sus propios tokens JWT firmados, logrando dificultar así la explotación de esta vulnerabilidad.

Mientras que el CVE-2020-1762, es debido a una validación insuficiente de JWT en kiali. La explotación exitosa de esta vulnerabilidad, permitiría a un atacante remoto robar una cookie JWT válida y usarla para falsificar una sesión de usuario.

Cabe destacar que los cuatros mecanismos de autenticación (inicio de sesión, token, openshift y ldap) de kiali son vulnerables.

¿Cómo detectar una versión vulnerable?

Para detectar si la versión de kiali utilizada es vulnerable, deberá ejecutar el siguiente script bash:

KIALI_VERSION=$(kubectl get pods -n istio-system -l app=kiali -o yaml | sed -n ‘s/^.*image: .*:v\(.*\)$/\1/p’ | sort -u) kubectl get deploy kiali -n istio-system -o yaml | grep -q LOGIN_TOKEN_SIGNING_KEY TEST_KEY_ENV=$? kubectl get cm kiali -n istio-system -o yaml | grep signing_key | grep -vq kialiTEST_KEY_CFG=$? VERSION_ENTRIES=(${KIALI_VERSION//./ }) echo «Your Kiali version found: ${KIALI_VERSION}» [ ${VERSION_ENTRIES[0]} -le «1» ] && [ ${VERSION_ENTRIES[1]} -le «15» ] && [ ${VERSION_ENTRIES[2]} -le «0» ] && echo «Your Kiali version is vulnerable» [ $TEST_KEY_ENV -eq 1 ] && [ $TEST_KEY_CFG -eq 1 ] && echo «Your Kiali configuration looks vulnerable»

El resultado será igual a la imagen en caso de ser vulnerable:

Recomendaciones:

  • Actualizar kiali a la versión 1.15.1. o posteriores
  • En caso de no ser posible la actualización de kiali, se podría aplicar la siguiente medida de mitigación:
    • Si la instalación se realizó a través del operador kiali, utilizar el siguiente script bash:

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

  • Si la instalación se realizó a través de lstio helm charts o del comando istioctl, utilizar el siguiente script bash:

“KIALI_INSTALL_NAMESPACE=istio system SIGN_KEY=$(chars=abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890; for i in {1..20}; do echo -n «${chars:RANDOM%${#chars}:1}»; done; echo) kubectl get cm kiali -n $KIALI_INSTALL_NAMESPACE -o yaml | sed «s/server:/login_token:\\n signing_key: $SIGN_KEY\\n server:/» | kubectl apply -f – kubectl delete pod -l app=kiali -n $KIALI_INSTALL_NAMESPACE”

  • Además, para OpenShift ServiceMesh podrá actualizar kiali de manera manual, para ello debe ejecutar el siguiente comando:

“oc get kiali -n $ (oc get kiali –todos los espacios de nombres –no-headers -o custom-columnas = NS: .metadata.namespace) -o yaml | sed «s / spec: / spec: \ n login_token: \ n sign_key: $ (chars = abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ1234567890; para i en {1..20}; do echo -n» $ {chars: RANDOM}: $ # # 1} «; hecho; eco) /» | oc aplica -f -”

Referencias:

Compartir: