Un ping de la muerte es un tipo de ataque a un sistema informático que implica el envío de un ping mal formado o malicioso a una computadora.
Un paquete de ping correctamente formado suele tener un tamaño de 56 bytes , o 64 bytes cuando se considera el encabezado ICMP , y 84 incluido el encabezado del Protocolo de Internet versión 4. Sin embargo, cualquier paquete IPv4 (incluidos los pings) puede tener un tamaño de hasta 65 535 bytes. Algunos sistemas informáticos nunca fueron diseñados para manejar adecuadamente un paquete de ping más grande que el tamaño máximo de paquete porque viola el Protocolo de Internet documentado en RFC 791. [1] Al igual que otros paquetes grandes pero bien formados, un ping de la muerte se fragmenta en grupos de 8 octetos antes de la transmisión. Sin embargo, cuando la computadora de destino vuelve a ensamblar el paquete con formato incorrecto, puede ocurrir un desbordamiento del búfer , lo quebloqueo del sistema y potencialmente permitiendo la inyección de código malicioso .
En las primeras implementaciones de TCP / IP , este error es fácil de explotar y puede afectar a una amplia variedad de sistemas, incluidos Unix , Linux , Mac , Windows y dispositivos periféricos. A medida que los sistemas comenzaron a filtrar los pings de muerte a través de firewalls y otros métodos de detección, más tarde apareció un tipo diferente de ataque de ping conocido como inundación de ping , que inunda a la víctima con tantas solicitudes de ping que el tráfico normal no llega al sistema (una negación básica: ataque de servicio ).
Información detallada
Como se define en RFC 791, la longitud máxima de un paquete IPv4, incluido el encabezado IP, es 65,535 (2 16 - 1) bytes, una limitación presentada por el uso de un campo de encabezado IP de 16 bits de ancho que describe la longitud total del paquete.
La capa de enlace de datos subyacente casi siempre impone límites al tamaño máximo de trama (consulte MTU ). En Ethernet , esto suele ser de 1500 bytes. En tal caso, un paquete de IP grande se divide en varios paquetes de IP (también conocidos como fragmentos de IP), de modo que cada fragmento de IP coincidirá con el límite impuesto. El receptor de los fragmentos de IP los volverá a ensamblar en el paquete de IP completo y continuará procesándolo como de costumbre.
Cuando la fragmentación se lleva a cabo, las necesidades de cada fragmento IP para transportar información sobre qué parte del paquete IP original que contiene. Esta información se guarda en el campo Desplazamiento de fragmentos, en el encabezado IP. El campo tiene 13 bits de longitud y contiene el desplazamiento de los datos en el fragmento IP actual, en el paquete IP original. El desplazamiento se da en unidades de 8 bytes. Esto permite un desplazamiento máximo de 65,528 ((2 13 -1) * 8). Luego, al agregar 20 bytes de encabezado IP, el máximo será 65,548 bytes, lo que excede el tamaño máximo de trama. Esto significa que un fragmento de IP con el desplazamiento máximo debe tener datos no mayores de 7 bytes, o de lo contrario excedería el límite de la longitud máxima del paquete. Un usuario malintencionado puede enviar un fragmento de IP con el desplazamiento máximo y con muchos más datos de 8 bytes (tan grande como lo permita la capa física).
Cuando el receptor reúne todos los fragmentos de IP, terminará con un paquete de IP de más de 65.535 bytes. Esto posiblemente puede desbordar los búferes de memoria que el receptor asignó para el paquete y puede causar varios problemas.
Como se desprende de la descripción anterior, el problema no tiene nada que ver con ICMP , que se usa solo como carga útil, lo suficientemente grande como para explotar el problema. Es un problema en el proceso de reensamblaje de fragmentos de IP, que pueden contener cualquier tipo de protocolo ( TCP , UDP , IGMP , etc.).
La corrección del problema es agregar cheques en el proceso de reensamblaje. La verificación de cada fragmento de IP entrante asegura que la suma de los campos "Desplazamiento de fragmento" y "Longitud total" en el encabezado de IP de cada fragmento de IP sea menor o igual a 65.535. Si la suma es mayor, el paquete no es válido y el fragmento de IP se ignora. Algunos cortafuegos realizan esta comprobación para proteger los hosts que no tienen el error corregido. Otra solución al problema es utilizar un búfer de memoria de más de 65 535 bytes para el reensamblaje del paquete. (Esto es esencialmente una ruptura de la especificación, ya que agrega soporte para paquetes más grandes que los permitidos).
Ping de muerte en IPv6
En 2013, se descubrió una versión IPv6 de la vulnerabilidad ping of death en Microsoft Windows . La pila TCP / IP de Windows no manejaba la asignación de memoria correctamente al procesar los paquetes ICMPv6 mal formados entrantes , lo que podría causar una denegación de servicio remota. Esta vulnerabilidad se corrigió en MS13-065 en agosto de 2013. [2] [3] El CVE-ID para esta vulnerabilidad es CVE - 2013-3183 . [4] En 2020, se encontró otro error (CVE-2020-16898) en ICMPv6 alrededor de la publicidad de enrutador , que incluso podría conducir a la ejecución remota de código . [5]
Ver también
Referencias
- ^ Erickson, Jon (2008). HACKING el arte de la explotación (2ª ed.). San Francisco: NoStarch Press. pag. 256 . ISBN 1-59327-144-1.
- ^ "Boletín de seguridad de Microsoft MS13-065 - Importante" . Microsoft. 13 de agosto de 2013 . Consultado el 25 de febrero de 2017 .
- ^ Jackson, Joab (13 de agosto de 2013). "Microsoft Patch Tuesday: The Ping of Death regresa, estilo IPv6" . Consultado el 25 de febrero de 2017 .
- ^ "CVE - CVE-2013-3183" . La Corporación MITRE . Consultado el 25 de febrero de 2017 .
- ^ "CVE-2020-16898 - Vulnerabilidad de ejecución remota de código TCP / IP de Windows" . Microsoft. 13 de octubre de 2020 . Consultado el 14 de octubre de 2020 .
enlaces externos
- La página de Ping o 'Death en la Wayback Machine (archivada el 6 de diciembre de 1998)
- Ping de la muerte en Insecure.Org