Esta semana en seguridad: NOMBRE: WRECK, Back Hacks, actualizaciones y más

NAME: WRECK es una colección de vulnerabilidades en implementaciones de DNS, descubiertas por Forescout y JSOF Research. Esta investigación se considera una continuación de Ripple20 y AMNESIA: 33, ya que crea una clase de vulnerabilidad descubierta en otras pilas de red, problemas con la compresión de mensajes DNS.

Su documento técnico en PDF contiene una breve introducción al formato de mensaje DNS, que es útil para comprender el problema. En un mensaje de este tipo, un nombre DNS se codifica mediante un esquema de valor largo, y cada nombre completo termina en un byte cero. Entonces, en Solicitud de DNS, la-tecnologia.com se representaría como [0x08]La-Tecnologia[0x03]com[0x00]. Los puntos se reemplazan por estos valores largos, lo que facilita un formato analizable.

Desde el principio se decidió que repetir continuamente los mismos nombres de host en un mensaje DNS desperdicia espacio, por lo que se creó un esquema de compresión. La compresión DNS utiliza la longitud máxima de host / dominio de 63 caracteres. Este tamaño máximo significa que la representación binaria de ese valor de longitud nunca contendrá un "1" en los dos primeros dígitos. Debido a que nunca se puede usar, los valores largos que comienzan con un "11" binario se usan para indicar un nombre de dominio que aparece anteriormente. Los 14 bits que siguen a este bit de dos bits se conocen como puntero de compresión y representan un desplazamiento de bytes desde el principio del mensaje. El analizador de mensajes DNS extrae el valor de destino de esa ubicación y luego continúa analizando.

Los problemas encontrados se basaron generalmente en una validación incorrecta. Por ejemplo, la pila NetX no comprueba si el puntero de compresión se muestra. Este escenario conduce a un ciclo sin fin estricto, un ataque DoS clásico. Otros sistemas no confirman correctamente la ubicación referenciada, provocando una copia de los datos más allá del búfer asignado, lo que lleva a la ejecución remota de código (RCE). FreeBSD tiene este problema, pero debido a que está vinculado a paquetes DHCP, la vulnerabilidad solo puede ser explotada por un dispositivo en la red local. Al buscar problemas de compresión de mensajes, también encontraron un puñado de vulnerabilidades en el análisis de la respuesta de DNS que no están directamente relacionadas con la compresión. Lo más notable aquí es RCE en la pila Nucleus Net de Seimens.

Actualizaciones del navegador

Ha llegado otra ronda de actualizaciones del navegador y hay algunas notas interesantes. Además de las correcciones de seguridad normales, Firefox optó por eliminar la compatibilidad con la apertura de conexiones FTP en el navegador. El razonamiento parece doble. Primero, un protocolo menos que admitir significa una superficie de ataque menos de la que preocuparse. La segunda razón declarada es que este movimiento permite que Firefox deje de admitir un protocolo no cifrado.

Google Chrome ha tenido unas semanas interesantes, con un par de errores anunciados en Twitter. De cualquier manera, los errores se llamaron días 0, pero eso no es exactamente cierto. Un día 0 es un error que se usa o se libera de manera salvaje antes de que el proveedor del programa se dé cuenta.

Lo que parece haber sucedido aquí es que los investigadores descubrieron los errores y los informaron en privado a Google. Google empujó las correcciones a su motor V8 y mostró muy buenas prácticas de seguridad, escribió un caso de prueba para cada uno y lo llevó a su conjunto de prueba. Su conjunto de pruebas públicas. Sí, el propio Google filtró estas vulnerabilidades antes de corregirlas en Chrome, escribiendo y publicando PoC. Ach.

WireGuard, FreeBSD y pfSense

Hubo un accidente de tren en movimiento lento que terminó hace aproximadamente un mes, pero lo recordé esta semana y vale la pena abordarlo. Ars trabajó muy bien en la historia. Primero, pfSense es un distribuidor popular basado en FreeBSD. Está patrocinado y respaldado por Netgate, que admite una excelente publicación comunitaria y también vende hardware con la versión comercial. Netgate también emplea al menos a uno de los desarrolladores de FreeBSD. Para ser claros, Netgate parece un gran traje, pero como veremos, algunas malas decisiones los llevaron a un problema.

Se decidió que Wireguard sería una gran adición a pfSense, y la mejor manera de lograr ese objetivo era contratar a un desarrollador para agregar un controlador Wireguard al kernel de FreeBSD. El esfuerzo se hizo a un lado de inmediato [Matthew Macy] comenzó, y rechazó la ayuda de [Jason Donefeld], que resultó ser el autor del protocolo WireGuard y el desarrollador principal de la implementación oficial. Empeoró cuando se construyó el puerto FreeBSD y se comprobó el código sin la revisión adecuada. Esto llamó la atención de Donefeld, quien echó un vistazo a la implementación y comenzó un sprint de código de 10 días junto con algunos otros desarrolladores, para tratar de resolver el peor problema antes de que FreeBSD lanzara su versión final 13.0. Si bien la atención adicional ciertamente mejoró el código, el kerfluffle atrajo la atención del equipo de seguridad de FreeBSD, quien pidió extraer el código antes de su lanzamiento, dando suficiente tiempo para arreglarlo por completo.

Hablamos con Donefeld esta semana en FLOSS Weekly, y surgió esta historia. Consulte el enlace y vaya a 37:40 para ver sus comentarios sobre el asunto. Parece que la situación se ha convertido en una guerra territorial, y aunque exactamente lo mismo se hizo en el propio kernel de FreeBSD, parece que pfSense ha enviado una edición con el código roto y vulnerable. Al menos, esta es una lección sobre cómo la mejor intención puede volverse muy mala sin una revisión y supervisión suficientes. Asegúrese de consultar la respuesta oficial de Netgate para escuchar el otro lado de la historia.

Hacking de señales del hacker

Hay algunas personalidades que, cuando se menciona su nombre, sabes que será una buena historia. Entre personas como Cliff Stoll y Kevin Mitnick, sugiero que Moxie Marlinspike haga esa lista. Ha estado involucrado en la seguridad durante años y recientemente ha sido conocido por su trabajo en Signal. Signal es, por supuesto, una completa aplicación de mensajería encriptada que ha seguido mucho a lo largo de los años. Es utilizado por periodistas, investigadores, disidentes políticos y delincuentes.

Con una base de usuarios tan interesante, puedes imaginar cuántas personas están interesadas en intentar romper la seguridad de Signal. Una de esas empresas es Cellebrite, una empresa de seguridad que se especializa en seguridad forense y ofensiva para el gobierno y las fuerzas del orden. Si bien Cellebrite no puede leer los mensajes de Signal a través de la red, sí produce un conjunto de herramientas forenses que puede extraer mensajes de un teléfono, con acceso físico a él. Mediante métodos supuestamente astutos, Moxie obtuvo uno de sus kits e hizo un análisis completo del dispositivo. No sé exactamente cómo lo consiguió, pero la explicación menos creíble (y la que no se toma en serio) es que "se cayó de un camión".

Por una coincidencia realmente increíble, estaba caminando cuando vi un pequeño paquete caer de un camión frente a mí. A medida que me acercaba, la aburrida fuente corporativa se centró lentamente: Cellebrite.

Moxie encontró algunas cosas particularmente interesantes en el software incluido, como bibliotecas obsoletas hace muchos años, sin mencionar las bibliotecas de Apple que probablemente se distribuyeron ilegalmente. Estas bibliotecas anticuadas contienen una gran colección de vulnerabilidades, y en la publicación de Moxie se incluye una demostración del software Cellebrite explotado al intentar leer un archivo telefónico. La publicación termina con una advertencia muy irónica y poco velada de archivos "poco interesantes" que Signal almacenará y cambiará con el tiempo. La promesa no expresada es que estos archivos son trampas y lanzarán exploits en cualquier máquina que use el programa Cellebrite, que intenta extraer datos de señales de un teléfono.

Esta amenaza no solo molesta a Cellebrite, sino que deshabilita cualquier dato de señal recuperado por las herramientas de Cellebrite. Si se sabe que Cellebrite es vulnerable a este tipo de compromiso, todos los datos que recupere serán automáticamente sospechosos y posiblemente inaceptables en una demanda. Es una estrategia inteligente y el tiempo dirá si da los frutos esperados.

Cambios en las reglas de Project Zero

Project Zero de Google se ha hecho famoso por dos cosas: primero, hacen una investigación de seguridad asombrosa. En segundo lugar, le dicen cuándo publicarán los detalles vulnerables al público, y lo apoyan pase lo que pase.

Es por eso que cuando anuncian un cambio en esa política, es una especie de sorpresa de noticias. Ahora, para ser justos, no fue un gran cambio. La política anterior era de 90 días, con un posible período de gracia de 14 días si llegaba una solución. Los detalles vulnerables se publicaron en un plazo de 90 días, a menos que estuviera en juego el período de gracia, en cuyo caso los detalles se publicaron después del lanzamiento de la solución. La nueva política agrega un período de adopción de 30 días. Ahora, si se lanza una reparación dentro de la ventana de 90 (o 104) días, la liberación de la vulnerabilidad ocurre 30 días después, por lo que un máximo posible de 134 días después de una divulgación privada.

  • José dice:

    Cliff Stoll es un gran narrador de historias, recomiendo encarecidamente su libro, Cuckoo Egg!

Alejandro Vargas
Alejandro Vargas

Deja una respuesta

Tu dirección de correo electrónico no será publicada.