Se ha descubierto una vulnerabilidad (CVE aún no emitido) en uClibc y uClibc-ng bibliotecas estándar C. Estas bibliotecas se utilizan ampliamente en dispositivos de iot. La vulnerabilidad recién descubierta permite colocar datos falsificados en la caché de DNS, permitiendo establecer una dirección IP arbitraria en ese caché con el posterior redireccionamiento de todas las consultas dirigidas al dominio a los malhechores’ servidor.
La falla afecta al firmware de Linux utilizado en varios enrutadores, Puntos calientes, y otros dispositivos de IoT. También afecta a las distribuciones de Linux para sistemas operativos integrados como Embedded Gentoo y OpenWRT.. La vulnerabilidad se revela en muchos dispositivos diferentes.. Por ejemplo, Linksys, netgear, y Axis usan bibliotecas uClibc. Dado que la vulnerabilidad aún no se ha solucionado en uClibc y uClibc-ng, Los detalles sobre dispositivos específicos y fabricantes en cuyos productos ocurre el problema aún no se han hecho públicos..
El mecanismo de vulnerabilidad
La vulnerabilidad proviene del uso de identificadores de transacciones predecibles en las solicitudes DNS generadas por la biblioteca. Los ID de solicitud de DNS se forman mediante un simple incremento del contador sin ninguna aleatorización adicional de los números de puerto.. este mecanismo, a su vez, permitió el envenenamiento de la caché de DNS mediante el envío proactivo de un paquete UDP con una respuesta falsificada. La falsificación se aceptará si presenta un ID de solicitud correcto y llega antes de la respuesta del servidor genuino.. A diferencia del método Kaminsky propuesto en 2008, el enfoque actual ni siquiera requiere conjeturas ya que el ID de la transacción es inicialmente predecible. El valor inicial (1) se incrementa con cada consulta, no elegido al azar.
Las recomendaciones de seguridad contra la ruptura de ID incluyen números aleatorios de puertos de red de origen desde donde se realiza la solicitud de DNS.. Esta medida debe compensar la corta longitud del identificador.. Si la aleatorización está activada, la falsificación de una identificación de 16 bits no es suficiente – Los piratas informáticos tendrían que forzar adicionalmente el número de puerto de la red.. En uClibc y uClibc-ng, el puerto UDP de origen aleatorio no se mostró durante la solicitud de vinculación. Por lo tanto, el el aleatorizador se apagó, y su aplicación requirió cambiar la configuración en el sistema operativo.
Con la aleatorización desactivada, el problema de adivinar un ID de solicitud incrementado se vuelve trivial. Pero incluso si se aplicara la aleatorización, los atacantes sólo necesitarían elegir un número de puerto entre 32768 y 60999 (Linux usa tal.) Podrían haber utilizado un envío simultáneo masivo de respuestas falsas a diferentes puertos de red para ganarle a la respuesta DNS legítima..
Historia de la consulta
El problema ha sido confirmado en todas las versiones funcionales de uClibc y uClibc-ng, incluyendo el último uClibc 0.9.33.2 y uClibc-ing 1.0.40. En septiembre 2021, La información sobre la vulnerabilidad fue enviada a CERT/CC para la preparación coordinada de arreglos. Además, En Enero 2022, los datos fueron entregados a más de 200 fabricantes que trabajan con CERT/CC. En marzo, hubo comunicación con el soporte del proyecto uClibc-ng. Admitieron que no podían solucionar la vulnerabilidad por sí mismos y recomendaron revelar la información a la comunidad para que pudiera ayudar con el desarrollo de la solución.. Redes Nozomi, la empresa que detectó la falla, llevó la información al público en un informe exhaustivo en mayo 2, 2022. Mientras tanto, Netgear ha anunciado una actualización en la que prometen abordar la vulnerabilidad..
