Ocasionalmente, mi trabajo en manejo de intrusiones y análisis forense no deja de producir anécdotas inolvidables. Lamentablemente, muchas no pueden ser compartidas por este medio por estar bajo acuerdos de confidencialidad y/o para proteger a los inocentes. Sin embargo, hace unos días recibí una alerta de mi sistema de detección de intrusiones, altamente entonado para hacer investigación de las amenzas del tráfico público de Internet. Esta alerta describía un paquete poco interesante pero de una fuente un poco inusual.
La razón de SNORT (¿Cuál otro IDS podría ser? SNORT rules!) para alertar sobre este evento es entendible. Se trata de un paquete ICMP con un payload de 0 bytes. Esta firma de paquetes es generalmente asociada al PING ICMP de nmap. Nmap es una herramienta muy popular en distintos estratos desde el profesional de la seguridad informática hasta el delincuente del crimen informático organizado, pasando por supuesto por los "script kiddies/junkies" que la abusan sin realmente entender muy bien lo que hacen.
Por lo tanto, usualmente este tipo de eventos es ignorado completamente en mi análisis rutinario. Éste hubiera sido también el caso para este evento de no haber sido por el detalle que la dirección IP de origen pertenece a la subred de servidores de infraestructura de mi proveedor de servicios de Internet (ISP). Uno de los paquetes transgresores se puede ver aquí:
Como es de esperarse de un paquete con un payload de 0 bytes, su tamaño es más pequeño de lo usual. El encabezado ICMP termina en la secuencia 0800 013f d4bf 2201. Si recordamos un poquito la decodificación del protocolo ICMP:
0800 -> Type 8, Code 0 -> ICMP Echo (solicitud de ping)
013f -> Checksum.
d4df -> Identificador del paquete ICMP.
2201 -> Numero de secuencia.
Esto ocupa los 8 bytes de payload del paquete IP creando en efecto un paquete ICMP de 0 bytes de payload. La pregunta inmediata es: ¿A que corresponden esos bytes despues de nuestro encabezado ICMP? Estos bytes estan ocupando la posición que normalmente ocuparia el payload de un ping normal. Un paquete ping normal se ve como sigue:
La diferencia que debe resaltar inmediatamente es la secuencia de simbolos y numeros crecientes del payload del paquete ICMP normal. Esta es una secuencia fija muy distinta a la secuencia con apariencia aleatoria del paquete anterior. En consecuencia decidí analizar el resto de paquete capturados por mi sensor de detección de intrusiones con la esperanza de hallar un patrón:
La falta de patrón no sólo es evidente sino que también la explicación es ahora muy sencilla de elaborar. Primeramente, la razón por la cual hay bytes extras en estos paquetes ICMP ECHO de 0 bytes se debe a que los frames ethernet son de mínimo 64 bytes. Como se puede ver, los paquetes IP fabricados por mi ISP son todos de una longitud de 28 bytes (0x001c), esto es 20 bytes de encabezado IP y 8 bytes de paquete ICMP sin payload. Si además sumamos los 14 bytes del encabezado ethernet y los 4 bytes del trailer ethernet, nos llega la cuenta a 46 bytes. Para llegar a 64 bytes hace falta que el sistema operativo rellene los 18 bytes faltantes. Estos 18 bytes de relleno son los que vemos en nuestros paquetes ICMP misteriosos.
Finalmente, al ver los strings parciales de algunos paquetes: "MENE", "feight", etc la hipótesis que cobra fuerza es una descrita aquí. En resumen, el sistema de mi ISP que esta creando paquetes ICMP con payload de 0 bytes puede estar ex-filtrando (presumimos que no intencionalmente) información al resto de Internet sobre su memoria interna. Esto sucede cuando los drivers de la tarjeta de red fallan en limpiar la memoria antes de rellenar los frames ethernet de tamaño inferior al mínimo permitido. Con suficiente recopilación de paquetes podriamos empezar a hacer profiling de su memoria, y poco a poco recuperar cadenas de caracteres con passwords, nombres de usuario, y todo tipo de información confidencial.
Una vez más el atacante no entrenado termina atacandose a sí mismo.
