Los investigadores de la firma de seguridad de IoT Nozomi Networks advierten que una biblioteca popular para el lenguaje de programación C para productos de IoT es vulnerable a ataques de envenenamiento de caché de DNS. El error tiene 10 años y, en la actualidad, sus mantenedores no pudieron solucionarlo.
La investigadora de seguridad de Nozomi, Andrea Palanca, descubrió que la implementación del Sistema de nombres de dominio (DNS) de las bibliotecas uClibc y uClibc-ng C utilizadas en varios productos populares de IoT genera identificadores de transacciones (ID) incrementales y predecibles en las comunicaciones de red de respuesta y solicitud de DNS.
uClibc dejó de mantenerse en 2012 después del lanzamiento de la versión uClibc-0.9.33.2, mientras que la bifurcación uClibc-ng está diseñada para usarse dentro de OpenWRT, un sistema operativo común para enrutadores «posiblemente implementado en varios sectores de infraestructura crítica», según Palanca.
VER: La botnet Emotet está de regreso y tiene nuevos trucos para propagar malware
También se sabe que uClibc es utilizado por Linksys, Netgear y Axis, y distribuciones de Linux, como Embedded Gentoo, señala Palanca.
Nozomi ha optado por no revelar los dispositivos IoT específicos que probó porque el error no está corregido. Sin embargo, Palanca señala que los dispositivos probados eran «una gama de dispositivos IoT conocidos que ejecutan las últimas versiones de firmware con una alta probabilidad de que se implementen en toda la infraestructura crítica».
La bifurcación uClibc-ng es una pequeña biblioteca C para desarrollar sistemas Linux integrados con la ventaja de ser mucho más pequeña que la biblioteca GNU C (glibc).
Palanca dice que informó el problema a ICS-CERT en septiembre para llevar a cabo un caso VINCE (Entorno de coordinación e información de vulnerabilidad) con CERT/CC. En abril, CERT/CC aprobó su solicitud para proceder con la divulgación de vulnerabilidades el 2 de mayo. El problema se rastrea como ICS-VU-638779, VU#473698.
CERT/CC invitó al mantenedor de uClibc-ng al caso VINCE a mediados de marzo, pero el desarrollador dijo que no podía implementar la solución por sí mismo y sugirió compartir el informe de vulnerabilidad en la lista de correo con una «comunidad bastante pequeña» que podría ser capaz de ayudar a implementar una solución.
Seis meses después del informe de error original a ICS-CERT, el error permanece sin parchear y sirve como un recordatorio de los desafíos en la seguridad del software de código abierto y, en términos más generales, en la cadena de suministro de software debido a la falta de fondos y recursos para desarrolladores.
El principal riesgo de los ataques de envenenamiento de DNS es que pueden forzar una respuesta de autenticación. El DNS, a menudo descrito como la ‘guía telefónica de Internet’, es responsable de traducir las direcciones IP en nombres de dominio.
Un ataque de envenenamiento de DNS involucra a un atacante que envenena los registros DNS para engañar a un cliente DNS para que acepte una respuesta falsificada y hacer que un programa redirija la comunicación de la red a un punto final que controlan en lugar del correcto.
Mientras probaba un dispositivo IoT sin nombre, Palanca notó que los ID de transacción, uno de los dos bits secretos en la comunicación de consulta y respuesta, eran incrementales. Estos ID fueron generados por uClibc 0.9.33.2, que su mantenedor original lanzó en mayo de 2012.
«Para que se acepte una respuesta de DNS para una determinada solicitud de DNS, la tupla de 5 antes mencionada, la consulta y el ID de la transacción deben configurarse correctamente», explica Palanca en una publicación de blog.
VER: Google: Múltiples grupos de piratería están utilizando la guerra en Ucrania como señuelo en intentos de phishing
Él dice que, debido a que el protocolo es DNS, la información conocida públicamente incluye ese puerto de destino, la consulta es el objetivo que un atacante quiere comprometer, la dirección IP de origen es la máquina de destino y que la dirección IP de destino es la dirección del Servidor DNS en uso en una determinada red: las únicas incógnitas siguen siendo el puerto de origen y la identificación de la transacción.
“Es vital que estos dos parámetros sean lo más impredecibles posible, porque si no lo son, podría producirse un ataque de envenenamiento”, señala Palanca.
«Dado que la identificación de la transacción ahora es predecible, para explotar la vulnerabilidad, un atacante necesitaría crear una respuesta DNS que contenga el puerto de origen correcto, así como también ganar la carrera contra la respuesta DNS legítima proveniente del servidor DNS.
«La capacidad de explotación del problema depende exactamente de estos factores. Como la función no aplica ninguna aleatorización explícita del puerto de origen, es probable que el problema pueda explotarse fácilmente de manera confiable si el sistema operativo está configurado para usar una fuente fija o predecible. Puerto.»
Palanca señala que los kernels de Linux modernos permiten la aleatorización del puerto de origen a nivel del sistema operativo, lo que dificulta la explotación de los ataques de envenenamiento de DNS. Sin embargo, si un atacante tiene suficiente ancho de banda, es posible que pueda «forzar brutamente el valor del puerto de origen de 16 bits mediante el envío de múltiples respuestas de DNS, al mismo tiempo que gana la carrera contra la respuesta de DNS legítima».
