En nuestra última investigación, encontramos 3 vulnerabilidades diferentes en pequeño cheque, una herramienta de código abierto desarrollada y publicada por Félix Aimé, uno de los expertos GReAT de Kaspersky. Cada una de las vulnerabilidades tiene una alta severidad por sí misma. Una vez combinado en una cadena, un atacante remoto podría explotarlo para obtener una RCE (ejecución remota de código) en la máquina TinyCheck remota.
En pocas palabras, utilizamos el credenciales predeterminadas de TinyCheck para editar dos secciones en un archivo de configuración:
- En el primero, agregamos un payload malicioso, que se ejecutará más tarde a través de comando de inyección vulnerabilidad.
- En el segundo, agregamos una URL a una lista que causará SSRF, que luego activará la carga maliciosa de la primera sección.
¿Qué es Tiny Check?
TinyCheck permite al usuario analizar la red de un dispositivo. El usuario puede conectar su dispositivo al proxy WiFi de TinyCheck, que capturará la actividad de la red. Esta actividad se puede analizar en busca de tráfico malicioso que pase por la red.
Ya que tenemos experiencia con proxy en Android, sabíamos que un proxy simple no debería tener demasiados problemas para manejar el tráfico potencialmente malicioso. Pero TinyCheck tiene más funciones y ofrece una mejor capacidad de rastreo que un simple script de proxy. El código fuente está disponible en GitHub que permitió examinarlo.
TinyCheck tiene 3 servicios relevantes:
- “Backend”: un servidor Flask que está abierto al mundo y protegido por nombre de usuario/contraseña (autenticación básica). El servidor se centra principalmente en la edición de la configuración.
- "Frontend": un servidor Flask que se ejecuta en localhost, no tiene contraseña y su trabajo principal es iniciar/detener/administrar la captura de red.
- "Observadores": un servicio de vigilancia que iterará sobre una lista de URL y les hará una solicitud HTTP GET.
Vulnerabilidad n.º 1: credenciales predeterminadas
Esta es la más simple de las 3 vulnerabilidades, pero esencial para todo el ataque. De forma predeterminada, TinyCheck viene con las credenciales predeterminadas de “tinycheck” como nombre de usuario y contraseña.
Tener tales credenciales predeterminadas sin requerir que el usuario las cambie en el primer uso presenta un riesgo innecesario.
Al usar las credenciales predeterminadas, teníamos acceso a una variedad de puntos finales en el servidor "backend", lo que nos brindaba una superficie de ataque más amplia.
El punto final importante que usaremos más adelante fue el que edita el archivo de configuración YAML.
https://tinycheck.local/config/edit/CATEGORY/KEY/VALUE
Más sobre cómo lo usamos a continuación.
Vulnerabilidad #2 – SSRF
El olvido de solicitud del lado del servidor (SSRF) siempre es emocionante y muchas veces los desarrolladores o investigadores de seguridad lo pasan por alto. Al explotar esta vulnerabilidad, pudimos obligar al servidor a realizar una solicitud HTTP. Es útil para eludir el cortafuegos o para acceder a la red interna, a la que antes no se podía acceder.
Descubrimos que el servidor tiene una lista de direcciones URL almacenadas en el archivo de configuración YAML en watchers/iocs:
Usando la primera vulnerabilidad, pudimos reescribir la lista y cambiarla a nuestras propias URL:
Curiosamente, ahora pudimos hacer que el servicio de "observadores" realice una solicitud HTTP GET a cualquier URL que elijamos. Lo más importante, podríamos acceder al servidor "frontend" mientras se ejecuta en localhost una vez recargado el servicio de “watchers”.
Nuevamente, eso nos dio una superficie de ataque más amplia para llegar a más puntos finales y más lógica que podíamos explotar.
Vulnerabilidad n.º 3: inyección de comandos
Empezamos a investigar el servidor “frontend”. No se confunda con el nombre, este es un servidor Flask, no solo una interfaz JS.
Teniendo un mundo completamente nuevo de puntos finales de la vulnerabilidad SSRF, examinamos las clases de servicio, las funciones y las utilidades que podrían explotarse.
Después de leer el código fuente y profundizar en la pila de llamadas a funciones, nos topamos con este código:
Popen("tshark -i {}".format(self.iface), shell=True)Popen es la forma de llamar a un subproceso en Python. los shell=True y del format son las partes explotables, lo que significa que el comando que se ejecutará se interpretará como una cadena. Si bien la intención original aquí funciona si self.iface es solo una cadena como "eth0", nos dimos cuenta de que si pudiéramos inyectar una cadena creada con fines malintencionados, podríamos ejecutar código arbitrario.
Por suerte para nosotros, el self.iface en realidad se leyó del archivo de configuración bajo el network/in sección, se supone que su valor original apunta a una interfaz de red.
self.iface = read_config("network/in")Al igual que la vulnerabilidad SSRF, inyectamos nuestra carga útil utilizando el mismo punto final de edición de configuración.
La inyección en sí era simple:
; whoami>/tmp/exploit.outEso significa que con nuestra carga útil, el comando original se formateará como:
Popen("tshark -i ; whoami>/tmp/exploit.out", shell=True)De hecho, el archivo contenía la palabra root, lo que significa que podríamos tomar el control del sistema, ya que el servidor se ejecuta como root y no como un usuario dedicado con pocos privilegios.
Pero teníamos que activar este código. En este momento, nuestra carga útil se ejecutó justo cuando el usuario comienza a capturar la actividad de la red a través de la interfaz de usuario.
La cadena de explotación completa
Para unir todo, necesitábamos una forma de activar nuestra carga útil.
Lo hicimos aprovechando el SSRF para llamar a uno de los puntos finales locales "frontend", que inicia la función de captura de red para que no tengamos que esperar a que el usuario lo haga.
Esto llamó al código vulnerable del servicio de "observadores" y para que la inyección de comando se ejecutara con nuestra carga maliciosa.
Divulgación al equipo de seguridad de Kaspersky
La divulgación de la vulnerabilidad al equipo de seguridad de Kaspersky fue una experiencia extraordinariamente buena para nosotros. Un saludo para ellos por comunicarse con nosotros muy rápidamente y obtener la ventaja del producto, Félix Aimé, implicado que resolvió todas las vulnerabilidades en cuestión de uno o dos días.
Cronología de divulgación
- 2020-12-14: Informe detallado enviado a [email protected]
- 2020-12-15: Primera respuesta del equipo de seguridad de productos de Kaspersky
- 2020-12-18: Todas las vulnerabilidades parcheadas + del asesoramiento para actualizar a la versión parcheada
- 2021-01-22: CVE emitidos
- 2021-02-11: Entrada de blog publicada
¿Quieres escuchar más?
Una reunión de consultoría gratuita incluida.
