CVE-2024-38063-

Explotando el Kernel de Forma Remota a Través de IPv6

CVE-2024-38063 - Explotando el Kernel de Forma Remota a Través de IPv6 Marcus Hutchins

Desde que el parche más reciente de Windows se lanzó el 13 de agosto, he estado inmerso en las profundidades de tcpip.sys (el controlador del kernel responsable de manejar los paquetes TCP/IP). Una vulnerabilidad con una puntuación CVSS de 9.8 en la parte más accesible del kernel de Windows era algo que simplemente no podía dejar pasar. Nunca antes había examinado IPv6 (ni los controladores encargados de analizarlo), así que sabía que intentar aplicar ingeniería inversa a esta vulnerabilidad sería extremadamente desafiante, pero una buena experiencia de aprendizaje.

En gran medida, tcpip.sys está en gran parte sin documentar. Pude encontrar un par de escritos de explotación para errores antiguos: aquí, aquí y aquí, pero poco más. Cuando el primer resultado de búsqueda de mi Google en inglés está escrito en chino, inmediatamente sé que estoy fuera de mi alcance y que me espera un mal rato, pero debemos aprender. A pesar de que Google Translate hace un trabajo mediocre, la publicación proporcionó una visión increíblemente detallada de cómo funciona la fragmentación de IPv6 y me dio una buena ventaja inicial.

Más tarde, mientras buscaba en Google algunos nombres de funciones, me topé con otro análisis de la misma vulnerabilidad de 2021, escrito por Axel Souchet (alias 0vercl0k), que profundizaba aún más en los internos de tcpip.sys y me dio suficiente información para definir varias estructuras no documentadas. El análisis de parche más fácil de la historia

Por lo general, incluso solo aplicar ingeniería inversa al parche para averiguar qué cambio de código corresponde a la vulnerabilidad puede llevar días o incluso semanas, pero en este caso fue instantáneo. De hecho, fue tan fácil que varias personas en las redes sociales me dijeron que me equivocaba y que el error estaba en otro lugar. ¿Les hice caso y perdí un día entero invirtiendo el controlador equivocado? Quizás nunca lo sepamos.

Hubo exactamente un cambio realizado en todo el archivo del controlador, que resultó ser el error después de todo.

Una vista general de bindiff de tcpip.sys antes y después de instalar el parche.

Solo una sola función en todo el controlador ha sido modificada. Normalmente, podría pasar un día entero revisando más de 20 cambios de funciones diferentes solo para averiguar cuál es la que debería estar examinando, pero esta vez no.

Ipv6pProcessOptions() antes del parche.

Ipv6pProcessOptions() después del parche.

No solo fue una sola función la que se cambió, sino una sola línea de código.

La función de nombre extremadamente largo Feature_2660322619__private_IsEnabledDeviceUsage_3() es algo que Microsoft a veces agrega para permitir reversiones parciales de parches. La llamada verifica la presencia de una bandera global o configuración de registro que, si está configurada, hará que la función devuelva false, lo que resultará en la ejecución del código original en lugar de la versión parcheada.

La razón por la que Microsoft hace esto es porque los parches de seguridad a veces rompen cosas sin querer, por lo que esta configuración permite a un administrador desparchear una sola vulnerabilidad, sin desinstalar todo el paquete de parches mensual y debilitar drásticamente la seguridad del sistema.

Teniendo esto en cuenta, está claro que todo lo que hace este parche es reemplazar una llamada a IppSendErrorList() con IppSendError(), dándonos una pista de que el problema está con algún tipo de lista. La diferencia de parche más fácil de la historia (o eso pensaba). Vulnerabilidades opcionales, explotación obligatoria

Aplicar ingeniería inversa al parche para encontrar el código alterado es solo la mitad del desafío (o en este caso, menos del 0.1%). El resto del proceso consiste en aplicar suficiente ingeniería inversa a la base de código para entender qué está pasando, averiguar qué tipo de vulnerabilidad fue parcheada, cómo elaborar una solicitud para alcanzar el código objetivo y qué estado resulta en una condición explotable.

La primera parte es bastante fácil. El cambio está en Ipv6pProcessOptions(), lo que nos dice que es IPv6 e implica el procesamiento de opciones. Entonces, una rápida llamada a la RFC nos dice exactamente qué es una opción de IPv6 y dónde podemos encontrar una.

El diseño del encabezado de opciones de destino de Wikipedia.

Bien, genial. Lo que estamos buscando parece ser el encabezado de opciones de destino, que se encuentra justo después del encabezado principal de IPv6. Usemos la biblioteca de Python 'scapy' para construir un paquete IPv6 de prueba.

Nota: Para mitigar ataques DDoS usando direcciones IP falsificadas, Windows restringe la capacidad de construir paquetes IP sin procesar. Por esta razón, opté por usar Linux para desarrollar mi prueba de concepto. Si bien Linux permite a los usuarios construir y enviar paquetes de capa 2 y capa 3 sin procesar, requiere que el script de Python se ejecute como root.

import sys
import struct
from scapy.all import *


def send_ipv6_option_packet(dest_ip):
	ethernet_header = Ether()
	ip_header = IPv6(dst=dest_ip)
	options_header = IPv6ExtHdrDestOpt()
	sendp(ethernet_header / ip_header / options_header)
	
	
if len(sys.argv) < 2:
	print('Use: python3 script.py <target_ipv6_address>')
	exit(-1)

send_ipv6_option_packet(sys.argv[1])

Después de establecer un punto de interrupción en tcpip!Ipv6pProcessOptions, luego ejecutar el script, quedó claro que todo lo necesario para llegar a la función vulnerable era enviar un paquete IPv6 con una estructura de opciones vacía. Luego intenté agregar algunas opciones inválidas a la estructura para ver si podía alcanzar la llamada a IppSendErrorList().

Una breve revisión del código indicó que casi cualquier formato de opción inválido podría desencadenar la llamada a IppSendErrorList. Así que decidí usar la opción de paquete Jumbo con una longitud inválida (menos de 65535 bytes).

options_header = IPv6ExtHdrDestOpt(options=[Jumbo(jumboplen=0x1337)])

Entonces, ¿qué hace realmente IppSendErrorList()? Bueno, el código es bastante simple.

La función completa de IppSendErrorList.

El código itera una lista enlazada y llama a IppSendError() en cada elemento de la lista. Nuevamente, los astros se han alineado y las cosas han sido fáciles hasta ahora. Si IppSendErrorList simplemente llama a IppSendError para cada elemento de una lista, y el parche reemplaza la llamada a IppSendErrorList con IppSendError, entonces el problema ocurre cuando se llama a IppSendError en un elemento de la lista que no sea el primero.

Entonces, ¿qué es esta lista y cómo hacemos una? Está haciendo una lista, la está revisando…52,567 veces

Aquí es donde las cosas pasaron de obvias a anormalmente difíciles, aunque creo que gran parte de esto se debió a que una de mis dos células cerebrales disponibles estaba ocupada luchando contra una mala infección de covid. Perdí un par de días entendiendo partes del código, quedándome dormido y luego olvidando lo que había descubierto. Todo el proceso requirió más de una semana de ingeniería inversa de partes de tcpip.sys para averiguar qué estaba pasando. Pero la publicación del blog de Axel fue extremadamente útil.

Al observar las funciones y estructuras que Axel invirtió, y a qué otras funciones se pasan, está claro que el único argumento pasado a Ipv6pProcessOptions() es la misma estructura packet_t definida en el artículo. Esencialmente, el puntero pasado a Ipv6pProcessOptions, e iterado por IppSendErrorList, es una lista enlazada de paquetes.

Entonces, establecí un punto de interrupción en Ipv6pProcessOptions() e inspeccioné la lista.

La entrada list->Next es NULL.