Havex no es el nuevo Stuxnet (y la falta de profesionalidad)

lunes, 30 de junio de 2014

Desde que Stuxnet apareció (hace ya cuatro años) parece que se espera un sucesor. Al menos en el campo del espionaje industrial y ámbitos SCADA. Desde entonces, se han descubierto varios "hijos", "primos" y familiares en general, pero ninguno parecía estar a la altura. Havex tampoco, ni mucho menos. De hecho, a pesar de los titulares, no tiene mucho que ver.

Havex suena en los medios porque se ha descubierto atacando a sistemas industriales. Lo cierto es que Havex no es nuevo. Se trata de una herramienta de control remoto (RAT) genérica que quizás se esté usando desde 2011. Crowdstrike lleva ya tiempo asociando esta herramienta a ataques a grandes empresas energéticas europeas (una buena parte en España).

Este gráfico es de 2013, en realidad, cuando Havex fue usado para otros fines
Lo que ha ocurrido ahora es que el interés de esos atacantes parece haberse centrado en compañías industriales y sistemas SCADA, adaptando su "herramienta" a las nuevas necesidades.

Infraestructura y finalidad

Usaron sistemas legítimos comprometidos como C&C (servidores de control para el troyano). No es la mejor manera de conseguirlo puesto que vuelve "frágil" la infraestructura. Comprometer servidores de terceros eleva las posibilidades de que los legítimos dueños puedan recuperar el acceso a sus servidores (con la información robada en ellos) o que los atacantes lo pierdan en cualquier momento. Bastante poco profesional por parte de los atacantes.

En el código, se observan funciones específicas para obtener y recolectar información concreta de sistemas SCADA, además de la capacidad habitual de tomar el control de los sistemas infectados.

Métodos de infección

Esta es la parte interesante. Al parecer usaron métodos tradicionales de infección (exploits o correos) junto con ataques de tipo "watering-hole" más que curiosos.

Comprometieron al menos tres empresas, todas ellas involucradas en el negocio de sistemas industriales. Estas compañías (con sede en Suiza, Bélgica y Alemania) proporcionaban software y sistemas de control remoto para sistemas ICS, cámaras de alta precisión, etc., y permitían la descarga (como muchas otras) de drivers, instaladores y software. Los atacantes tuvieron acceso a estos repositorios (al parecer por fallos en su infraestructura web) y alteraron los programas legítimos para instalar un "troyano" a la vieja usanza, donde el programa troyanizado funciona correctamente pero permite también el control remoto a los atacantes entre bambalinas.

¿Quién descargaría y usaría ese software? Solo técnicos específicos de sistemas industriales. Así que el objetivo era muy específico para los atacantes. Uno de los archivos detectados en este ataque fue enviado a Virustotal en marzo. Ningún motor lo detectaba por firmas. El resto de DLLs utilizadas, no habían sido enviadas antes del 23 de junio de 2014, pero tampoco eran detectadas ese día. En pocas horas, la mayoría de los antivirus eran ya capaces de detectarla.

Tanto los proveedores de software como los que lo consumían, han cometido una serie de errores graves durante el proceso de infección.

  • Las páginas que proporcionan estos sistemas industriales han sido comprometidas y sus programas sustituidos sin que sus legítimos dueños lo hayan advertido a tiempo. Los errores de estas empresas, tanto reactivos como preventivos, son innumerables. No se han dado los nombres concretos de las compañías, pero no resulta muy difícil poder reducir el círculo de candidatas.
  • Los operarios o administradores han descargado este software y no han comprobado las firmas o integridad (si es que las compañías firmaban todo su software u ofrecían algún método de comprobación). Esto es quizás lo más preocupante. En entornos de este tipo, instalar un programa debe ser un proceso compuesto por varias fases, aunque haya sido descargado de una página oficial. En concreto comprobar firmas e integridad debería ser obligatorio en el procedimiento. También la ejecución en sandboxes que desvelen el comportamiento exacto del programa antes de pasar a producción. Por ejemplo, esta línea en un sistema de debug hubiera podido delatar el comportamiento anómalo.

Ejecución de una DLL en un programa legítimo de control SCADA. Fuente: F-Secure

  • Los sistemas en producción disponían de conexión directa a internet. Se deduce porque, tras instalar los componentes troyanizados, el malware concreto era descargado y actualizado sin contratiempos. Además de enviar la información robada. Parece que los sistemas industriales afectados no contaban con listas blancas de conexión a internet, IDS o cortafuegos... en definitiva, las nociones básicas de seguridad. 

No es Stuxnet

Los medios de comunicación tampoco se han mostrado muy certeros con esta comparación. Stuxnet estaba específicamente diseñado para atacar el producto SCADA WinCC de Siemens. Y hasta aquí las similitudes. Esta variedad de Havex, aunque con un objetivo claro, no parecía estar tan específicamente programada. Stuxnet contenía vulnerabilidades completamente desconocidas, operaba de forma mucho más inteligente, utilizaba certificados válidos... era una verdadera arma muy pensada y diseñada con un objetivo concreto (parece que las centrales nucleares iraníes).

Nadie duda de que esta operación con Havex se considere un ataque relevante, pero Stuxnet fue mucho más allá, y se podría decir que fue diseñada por un equipo muy potente y poderoso que desarrollaron su "producto" durante años. Con Havex lo que se ha realizado es un ataque concreto a sistemas SCADA, pero no se ha diseñado específicamente un arma contra ellos. Aunque resulte preocupante y haya causado en una infección alta, se queda casi en la anécdota si lo comparamos con Stuxnet, al menos por ahora sin más datos.

Las infecciones han sido variadas, sobre todo en Europa. Se diría que Havex ha infectado a compañías más modestas, aunque no por ello pequeñas. Por tanto no caben demasiadas comparaciones. Pero sí sirve para recordar, una vez más, que para realizar una campaña de infección medianamente eficaz a muchos sistemas críticos, quizás no haga falta una inversión tan alta.

Sergio de los Santos
ssantos@11paths.com

No hay comentarios:

Publicar un comentario