Regin: ICMP cover channel

Una de las cosas que más me llamó ayer la atención sobre Regin cuando leía ayer el informe de Symantec fue los métodos de comunicación que usaba para conectarse con su red de comando y control, específicamente el uso de ICMP. ¿En seis años nadie había detectado ninguna anomalía de tráfico de este tipo?. Si uno se va al análisis, a la página que habla sobre el control del troyano, vemos que tiene varias formas de comunicarse con su centro de control

• ICMP: Payload information can be encoded and embedded in lieu of legitimate ICMP/ping data. The string ‘shit’ is scattered in the packet for data validation. In addition, CRC checks use the seed ‘31337’.
• UDP: Raw UDP payload.
• TCP: Raw TCP payload.
• HTTP: Payload information can be encoded and embedded within cookie data under the names SESSID, SMSWAP, TW, WINKER, TIMESET, LASTVISIT, AST.NET_SessionId, PHPSESSID, or phpAds_d. This information can be combined with another cookie for validation under the names USERIDTK, UID, GRID, UID=PREF=ID, TM, __utma, LM, TMARK, VERSION, or CURRENT

Además, según el informe de Kaspersky el troyano es capaz de establecer una red P2P entre nodos infectados para tener más posibilidades de conectar con su centro de control. Un ejemplo de redundancia para evitar ser anulado.

Si se administra una red donde tenemos una gestión de seguridad más o menos razonable, sabremos que puestos y qué sistemas operativos se ejecutan en cada nodo de la misma, ya sea por procedimiento manuales, ya sea usando algún tipo de software que nos permita inventariar la misma, ya sea porque tenemos desplegados en puntos estratégicos software como prads que nos permita una detección pasiva de equipos en la red. Es decir, si somos un poco cuidadosos tendremos una visión más o menos actualizada de los equipos para poder incrementar nuestra situation awareness. Es más, es probable que tengamos algún software que nos esté recogiendo y consolidando eventos de seguridad de la red, y lo más importante que debería de ser capaz de avisarnos de las anomalías que se producen en dicha red.

Hoy he estado mirando los paquetes ICMP que genera tanto Linux como MacOS X (Mavericks) cuando utilizan el comando ping, en especial el campo de datos. Decir que esta utilidad genera un paquete (echo request) con un campo de datos, que si llega a la máquina destino y está configurada para responder, lo hace con un paquete de echo reply. El paquete echo request lleva un campo de datos que nos va a aparecer en el paquete de vuelta echo replay. Lo interesante es que este campo de datos, es, precisamente lo que podría estar usando para pasar información de control el troyano. Pero es que también hay que decir, que este campo de dato es fijo en la configuración por defecto de OS X y en Linux, al menos en la versión que he probado, sólo cambian los 4 primeros bytes de los 48 que utiliza el paquete de datos.

¿Cómo es que ningún software de correlación vio esta clara anomalía?, máxime cuando parece ser que hasta ahora, las direcciones IP de los centros de comando y control, como puede verse aquí son cuatros?. Mirando las últimas reglas de Snort, se puede ver que ha añadido al fichero malware-cnc.rules varias reglas para detectar estos centros de control.

En realidad, ¿de verdad los SIEM están preparados para detectar este tipo de amenazas?. ¿Qué tenemos que información tenemos que integrar aquí y cómo?

• ¿Qué sistemas se ejecuta en cada nodo de la red?
• Tráfico ilegítimo ICMP asociado a esos sistemas, ya sea por patrones que no son estándar ya sea por una cantidad de tráfico que no está dentro de los parámetros normales.