Hace poco se dio a conocer la noticia de que fueron encontradas cerca de 19 vulnerabilidades en la pila TCP/IP patentada de Treck, las cuales pueden ser explotadas mediante el envío de paquetes especialmente diseñados.

Las vulnerabilidades encontradas, fueron asignadas al nombre en código Ripple20 y  algunas de estas vulnerabilidades también aparecen en la pila KASAGO TCP/IP de Zuken Elmic (Elmic Systems), que comparte raíces comunes con Treck.

Lo preocupante de esta serie de vulnerabilidades encontradas, es que la pila TCP/IP Treck se utiliza en muchos dispositivos industriales, médicos, de comunicación, integrados y de consumo, desde lámparas inteligentes hasta impresoras y fuentes de alimentación ininterrumpida), así como en equipos de energía, transporte, aviación, comercio y producción de petróleo.

Sobre las vulnerabilidades

Los objetivos notables para los ataques que usan la pila Treck TCP/IP incluyen impresoras de red HP y chips Intel.

La inclusión de problemas en la pila Treck TCP/IP resultó ser la razón de las vulnerabilidades remotas recientes en los subsistemas Intel AMT e ISM explotados mediante el envío de un paquete de red.

Intel, HP, Hewlett Packard Enterprise, Baxter, Caterpillar, Digi, Rockwell Automation y Schneider Electric confirmaron las vulnerabilidades. Además de que otros 66 fabricantes, cuyos productos usan la pila Treck TCP/IP, aún no han respondido a los problemas, 5 fabricantes, incluido AMD, anunciaron que sus productos no estaban sujetos a problemas.

Los problemas se encontraron en la implementación de los protocolos IPv4, IPv6, UDP, DNS, DHCP, TCP, ICMPv4 y ARP, y fueron causados ​​por el procesamiento incorrecto de los parámetros con el tamaño de los datos (usando un campo con un tamaño sin verificar el tamaño real de los datos), errores al verificar la información de entrada, doble liberación de memoria, leer desde un área fuera del búfer, desbordamientos de enteros, control de acceso incorrecto y problemas al procesar cadenas con un separador cero.

El impacto de estas vulnerabilidades variará debido a la combinación de las opciones de compilación y tiempo de ejecución utilizadas al desarrollar diferentes sistemas integrados. Esta diversidad de implementaciones y la falta de visibilidad de la cadena de suministro han exasperado el problema de evaluar con precisión el impacto de estas vulnerabilidades. 

En resumen, un atacante remoto no autenticado puede usar paquetes de red especialmente diseñados para causar una denegación de servicio, revelar información o ejecutar código arbitrario.

Los dos problemas más peligrosos (CVE-2020-11896, CVE-2020-11897), a los que se les asigna el nivel de CVSS 10, le permiten a un atacante poder ejecutar su código en el dispositivo enviando paquetes IPv4/UDP o IPv6 de cierta manera.

El primer problema crítico aparece en dispositivos con soporte para túneles IPv4, y el segundo en versiones habilitadas para IPv6 lanzadas antes del 4 de junio de 2009. Otra vulnerabilidad crítica (CVSS 9) está presente en el solucionador de DNS (CVE-2020-11901) y permite que el código se ejecute enviando una solicitud de DNS especialmente diseñada (el problema se usó para demostrar el pirateo de UPS APC de Schneider Electric y aparece en dispositivos con soporte de DNS).

Mientras que otras vulnerabilidades CVE-2020-11898, CVE-2020-11899, CVE-2020-11902, CVE-2020-11903, CVE-2020-11905 le permiten conocer el contenido mediante el envío de paquetes especialmente diseñados de IPv4 / ICMPv4, IPv6OverIPv4, DHCP, DHCPv6 o IPv6 áreas de memoria del sistema. Otros problemas pueden llevar a la denegación de servicio o a la fuga de datos residuales de las memorias intermedias del sistema.

La mayoría de las vulnerabilidades se solucionaron en el lanzamiento de Treck 6.0.1.67 (el problema CVE-2020-11897 se corrigió en 5.0.1.35, CVE-2020-11900 en 6.0.1.41, CVE-2020-11903 en 6.0.1.28, CVE-2020-11908 en 4.7. 1.27).

Dado que la preparación de actualizaciones de firmware para dispositivos específicos puede demorarse o ser imposible, ya que la pila Treck se ha suministrado durante más de 20 años, muchos dispositivos se han dejado desatendidos o son problemáticos para actualizar.

Se aconseja a los administradores aislar los dispositivos problemáticos y configurar la normalización o el bloqueo en los sistemas de inspección de paquetes, firewalls o enrutadores paquetes fragmentados, bloquean túneles IP (IPv6-in-IPv4 e IP-in-IP), bloquean el «enrutamiento de origen», activan la inspección de opciones incorrectas en paquetes TCP, bloquean mensajes de control ICMP no utilizados (MTU Update y Address Mask).