Ideas clave:
- Posiblemente sólo dispositivos Digi tengan las vulnerabilidades críticas de Ripple20
- Actualmente no existe un método (gratuito) para determinar con precisión si se tienen dispositivos con afectaciones graves de Ripple20 (CVE-2020-11896 y CVE-2020-11898)
- ¿La vulnerabilidad presente en un servidor de virtualización afecta a las máquinas virtuales? (¡¿?!)
Contexto
A mediados de junio del 2020 la firma israelí JSOF especializada en la investigación de vulnerabilidades y su explotación en dispositivos embebidos, dio a conocer el descubrimiento de 19 vulnerabilidades que afectaban la implementación de TCP/IP de Treck, este conjunto de vulnerabilidades se denominó como Ripple20. Dicha implementación se encuentra en multitud de marcas y dispositivos, incluyendo servidores, impresoras, dispositivos IoT, equipo médico, etc. Las vulnerabilidades varían en criticidad desde baja hasta alta, las más graves permiten ejecución de código, así como la filtración de información directamente de la memoria del equipo afectado.
Desarrollo
Actualmente los escaneos automatizados a nivel infraestructura pueden revelar aparentemente la existencia de la vulnerabilidad, como es el caso de Nessus, es importante aclarar que Nessus no arroja el detalle de cuál de las 19 vulnerabilidades de Ripple20 está presente en el equipo afectado, simplemente lanza el listado de los CVE involucrados, por lo que es tarea de los equipos de seguridad investigar detalles sobre la vulnerabilidad y encontrar algún método de detección para identificar equipos afectados en la red.
 |
| Imagen 1 y 2. Resultado de Nessus referente a Ripple20. |
De las 19 vulnerabilidades son de interés las que permitirían ejecución de código, así como filtración de información, tal es el caso de CVE-2020-11896 y CVE-2020-11898, por lo que es recomendable prestar atención en ellas para identificarlas y remediarlas.
Para tener un panorama más amplio de lo que se está hablando se recomienda revisar el documento publicado por JSOF en donde exponen los detalles técnicos de la vulnerabilidad.
Luego de revisar el documento podemos darnos cuenta que la naturaleza de la vulnerabilidad es la causa de que actualmente sólo existan públicamente scripts que fueron diseñados para detectar algunas de las vulnerabilidades más críticas de Ripple20.
Herramientas de detección usadas
Se usaron principalmente 2 herramientas disponibles de forma pública, ambas herramientas fueron desarrolladas en Python y hacen uso de Scapy.
• Script desarrollado por Laboratorios NVISO
Este script intenta abusar de CVE-2020-11898 en conjunto con CVE-2020-11896 por medio un paquete IPv4 malicioso encapsulado dentro de otro paquete IPv4, luego, el paquete se envía a la víctima en 2 fragmentos.
Cuando la implementación de treck en el equipo víctima intenta ensamblar el paquete interno de los 2 fragmentos externos, causa un mensaje de error ICMP de “protocolo inalcanzable”, debido a una lectura fuera de los límites en el código fuente, causado por la falta de coincidencia entre la indicación del tamaño del paquete interno y su longitud real. El resultado es que algunos datos de la memoria se copien por error en la respuesta que se envía al atacante. Este script originalmente se ejecutó contra un módulo de Digi, específicamente el Connect ME 9210, el cual es uno de los productos identificados como vulnerable. Se muestra un escenario con la prueba que realizó:
 |
| Imagen 3. Escenario básico para la prueba |
En esta primera prueba se ejecutó el script apuntando a una máquina virtual Windows Server ejecutándose sobre un servidor (físico) de HP, que según el fabricante está dentro de su lista de equipos afectados por Ripple20.
 |
| Imagen 4. No existió filtración de información |
Si el equipo fuera vulnerable, según la documentación del script, debería verse información filtrada en la sección donde se encuentran las A (0x41), lo cual no ocurrió en ninguna de las pruebas que se hicieron.
Se apuntó el script a la IP de administración del servidor (físico) asumiendo que es en el firmware del servidor donde se encuentra la vulnerabilidad, pero la prueba arrojó el mismo resultado.
• Script desarrollado por BAIMAOHUI
Este script realiza 3 pruebas de diferente confiabilidad, la más confiable envía un paquete malformado ICPM tipo 165, si el equipo afectado responde con un paquete ICMP tipo 166 significa que el equipo tiene la implementación de treck vulnerable.
 |
| Imagen 5. No se aprecia un paquete ICMP tipo 166 en la respuesta del equipo afectado |
En este caso no se vio un paquete ICMP tipo 166 como respuesta de 170.25.140.210.
Los resultados de las pruebas desarrolladas no son lo suficientemente fiables y certeras para determinar si existe o no realmente las vulnerabilidades (críticas) en el equipo o se trata de un falso-positivo de Nessus. Cabe mencionar que los scripts también se ejecutaron hacia una laptop Dell que se encuentra en la lista del fabricante como equipo afectado por Ripple20 y el resultado fue el mismo, no hubo evidencia de la existencia de la vulnerabilidad.
Llegado a este punto e investigando más se halló que SCADA desarrolló 3 pruebas con el fin de detectar la vulnerabilidad en dispositivos con la implementación de Treck vulnerable, en 2 de éstas 3 pruebas no se obtuvo evidencia certera de la existencia de la afectación, y la tercera prueba fue en un dispositivo que no tenía reporte de afectación, cuando realmente sí era vulnerable, sin embargo SCADA apegándose a una estricta política de divulgación responsable sólo comunicaran la afectación al fabricante.
Comentarios finales y recomendaciones
Es importante la detección ya que la vulnerabilidad puede estar presente en diferentes versiones de dispositivos que han estado en el mercado durante 20 años o más, por lo que algunos incluso ya no tienen soporte o garantía, de existir la vulnerabilidad en un equipo con esas características la única opción es cambiar el dispositivo, y en el mejor de los casos se deberá actualizar el firmware.
Es importante considerar que los equipos donde se ha confirmado (hasta el momento) la existencia de la vulnerabilidad, por medio de una PoC, ha sido sólo en modelos del fabricante Digi. Es probable que con el paso del tiempo las implementaciones de Treck hayan sufrido variaciones realizadas por el fabricante del dispositivo en cuestión, de tal suerte que, aunque sea una versión de Treck (en teoría) vulnerable, realmente no lo sea. Si lo anterior es cierto, esto aumenta el costo de la elaboración de un exploit, ya que deberá ajustarse a las diferentes implementaciones vulnerables.
Ante este escenario será necesario seguir buscando alguna otra alternativa para buscar los equipos vulnerables en la red, evaluar el riesgo y decidir si se es posible asumirlo o es necesario mitigarlo.
Existen herramientas de pago disponibles que han desarrollado las firmas para la detección de Ripple20 (aquí y aquí), de momento los resultados de dichas herramientas están fuera del alcance de este artículo.
Fuentes:
Fuente obtenida de: https://www.hackplayers.com/2020/08/ripple20-preocupado-lee-esto.html
