Español | English
rss facebook linkedin Twitter

Stuxnet (II)

Mucho se ha contado de Stuxnet, y mucho queda aún por contar. Desde la publicación del artículo Stuxnet por mi compañero se han conocido más datos sobre el funcionamiento, origen y destino de este malware dirigido hacia el sector industrial.

El análisis minucioso del código de Stuxnet, llevado a cabo por muchas empresas, desvela que el malware no es una herramienta nueva, sino que utiliza componentes desarrollados hace tiempo o que formaban parte de otras herramientas de malware. Algunos de los ficheros que componen este malware están fechados a principios de año, lo que da la idea del tiempo de preparación que se han tomado los creadores de este malware.

Un tiempo de desarrollo tan amplio no sería útil en una red empresarial, siempre tratando de prevenirse contra todo en el menor tiempo posible, pero si es efectivo contra estructuras que apenas se parchean en toda su vida útil como son las infraestructuras de control.
El informe desarrollado por Eset sobre el malware Stuxnet, detalla el proceso de creación del malware, haciendo hincapié en la división del trabajo y la preparación previa del mismo. En este informe se añade una concordancia entre las fechas de los ficheros del malware y los certificados que se usaron en su firma. También se comenta sobre el robo de los certificados, curiosamente en empresas situadas en Taiwán y cercanas la una a la otra, incluyendo la posibilidad de un robo físico de los mismos.

Cuanto más se va conociendo y más se analiza la información del malware, los expertos se ponen más de acuerdo en que se trata de un ataque organizado contra un objetivo concreto, y, además, por una empresa con muchos recursos o incluso un estado. Lo que sí que parece obvio es la parte del objetivo concreto, sobre todo si tenemos en cuenta que más del 80% de los ataques se concentran en tres países, y que la mitad de todos se concentran en Irán, como ya se mencionó en el anterior post. Kevin Hogan, director de seguridad de Symantec, se refería así al ataque “No podemos descartar la posibilidad de que un Estado esté detrás de esto. Basándonos en los recursos necesarios para desarrollarlo, la organización y el conocimiento en profundidad en varios campos - incluido el conocimiento específico de instalaciones en Irán-, solamente un Estado o un actor no estatal con acceso a este tipo de sistemas estatales tiene la posibilidad de hacer algo así”.

Todos estos datos han llevado a los expertos a ponerle un nombre al objetivo: La central nuclear de Bushehr, en Irán, aunque el responsable en materia nuclear de Irán, Ali Akbar Salehi, aseguró que el sistema central de mando en la central nuclear no se vio afectado por Stuxnet. El programa nuclear implantado por el gobierno iraní no cuenta con el apoyo de los países occidentales, muchos de los cuales consideran los sabotajes como un buen modo para detener su programa nuclear.

La mayoría de los expertos mundiales que se han referido a Stuxnet coinciden en que se trata de una herramienta diferente, compleja y con un objetivo especifico. Algunos, más dramáticos, han llegado a comentar que estos ataques pueden ser considerados como nuevas armas para la guerra. Que a la guerra no se va con lanza ya lo sabemos, pero de ahí a que los informáticos conquisten países desde casa como jugando al Civilization me parece que todavía nos queda, aunque nunca se sabe…

Jairo Alonso
S21sec Labs





Zeus Mitmo: Man-in-the-mobile

Two-factor authentication will force criminals to modify their tactics, that's all. (Bruce Schneier. 2005)

Zeus es uno de los troyanos bancarios más extendidos, reciéntemente publicamos algunas novedades de la versión 2.x, pero en los últimos días hemos tenido acceso a muestras con un comportamiento totalmente inusual hasta ahora; solicitar el modelo y número de móvil, para luego mandar un sms con el fin de descargarse una aplicación maliciosa.

Esta aplicación maliciosa infecta el móvil para robar los SMS que envían diversas entidades bancarias para confirmar la transferencia, además de recibir otras órdenes.

Hemos podido comprobar que diversas entidades están siendo afectadas y posiblemente se vaya propagando. Actualmente estamos colaborando con compañías de telefonía móvil para intentar detectar más dispositivos infectados.

Toda la información detallada en el blog en inglés.


Emilio Casbas
S21sec e-crime





STUXNET



En el último mes y medio ha habido mucho revuelo por el gusano Stuxnet, o mejor dicho, por el primer rootkit conocido para sistemas de control, y en concreto para el sistema SCADA de Siemens WinCC. Ahora que ya tenemos bastante información sobre Stuxnet (Symantec, Kaspersky y otros investigadores a título personal lo han analizado a fondo), y justo antes de la cita con Robert Langner (que no Langdon, aunque bien podría serlo) en la "conference" ACS organizada por Joe Weiss (donde se descubrirá nueva información sobre el "bicho") voy a aprovechar para hacer un resumen de lo que se sabe hasta la fecha.

Para la explicación que viene a continuación nos hemos basado principalmente en el excelente trabajo realizado por Industrial Defender en su whitepaper sobre Stuxnet y en la información facilitada por Richar Langner en su página web.

Los antecedentes

Stuxnet es detectado por primera vez el 17 de junio de 2010 por la empresa antivirus bielorusa VirusBlokAda. Inicialmente se le considera un gusano ya que aprovecha ciertas vulnerabilidades para propagarse e infectar distintas máquinas. Más adelante Symantec anuncia que también cuenta con propiedades de rootkit (el primero orientado a los sistemas de control), ya que es capaz de modificar el comportamiento normal de distintos componentes del sistema de control y oculta su presencia para no ser detectado.

Existen dos variantes básicas de Stuxnet, la primera Stuxnet.A/B, que viene firmada con un certificado legítimo de RealTek. La segunda en cambio viene firmada por un certificado de JMicron, también legítimo. Los certificados hacen que sea posible su instalación de forma transparente para el usuario en máquinas Windows Vista y Windows 7. La primera variante, ha sido sin duda la más extendida, y de hecho la más estudiada.

Propagación de Stuxnet

La principal vía de infección es a través de llaves USB. Stuxnet aprovecha la ya famosa vulnerabilidad 0-day (actualmente existe ya un parche) en el manejo de ficheros .LNK, de la que ya avisamos en nuestro CERT, por la que con solo visualizar en Windows Explorer los ficheros de acceso directo contenidos en una llave USB, se ejecuta automáticamente código del fichero al que hace referencia dicho acceso directo, en concreto en el caso de Stuxnet unos ficheros .tmp que contienen los binarios de Stuxnet.

Otras vías de infección son a través de recursos de red compartidos (concretamente Admin$) en los que la máquina infectada tiene permisos de escritura, y a través de una vieja conocida, la vulnerabilidad de RPC usada por Conficker y otros gusanos, y de la que ya hablamos en nuestro blog.







Brasil

No cabe duda que Brasil es uno de los países más atractivos hoy en día. No sólo por la belleza de su extenso territorio, la amabilidad y dulzura de sus habitantes, o su estilo de vida. Brasil es, por derecho propio, una de las naciones con un futuro más prometedor debido al increíble crecimiento económico que está experimentando debido a su mayor apertura al resto del mundo.

Este crecimiento económico también conlleva una rápida adopción de nuevas tecnologías y unos deseos inmensos de hacer negocios, con lo que casi todo el resto del planeta (y particularmente muchas empresas españolas) estamos planificando muchos de nuestros proyectos a lo largo y ancho del país.

Durante esta semana se ha celebrado en Brasilia el congreso sobre pericia y crímenes cibernéticos, ICCyber, donde hemos estado presentes dando una charla, pero sobre todo conociendo de primera mano el estado de la seguridad en Brasil, ya que el crecimiento ecónomico que tiene, implica también un crecimiento en la frecuencia y complejidad de los delitos por Internet.

Realmente nos hemos encontrado muy sorprendidos de la buena salud de la seguridad, tanto por empresas privadas, como por parte de la polícia y del gobierno. Existen multitud de empresas que están desarrollando productos que no tienen nada que envidiar a los mayores creadores de productos de seguridad tradicionales como EEUU o Israel, así como la mayoría de las grandes empresas tienen sus propios equipos de seguridad altamente cualificados, que no sólo tienen un conocimiento experto sobre diferentes aspectos de la seguridad, sino que también cuentan con mucha experiencia.

Una posible teoría que justifica la existencia de tantas empresas creadoras de productos de seguridad, es que hasta hace pocos años dependían mucho de productos procedentes de EEUU, pero a la vez, se sentían también un poco marginados y con poco apoyo o soporte de los mismos. Por lo tanto, decidieron crear sus propios productos: hemos visto productos de malware, SIEM, interceptación, análisis forense, auditorias, etc.

Independientemente de si la teoría es válida o no, la realidad es que resulta muy fructificante establecer relaciones con Brasil, puesto que es un soplo de aire fresco en la forma de entender la seguridad, tal como la conocemos en Europa.

Además, Brasil cuenta con varios grupos dedicados a la creación de malware 'local', aunque ya es tema para otra ocasión.

David Barroso
S21sec e-crime





ZeuS: El eslabón perdido

Es un hecho que dentro de la familia ZeuS la versión 2 se está imponiendo, pero últimamente nos hemos encontrado alguna versión que continúa con la rama 1.x, con ciertas características a caballo entre las 1.x y las 2.x, incluso alguna no vista en ninguna versión conocida.

Las versiones concretas de estas muestras, según su propio fichero de configuración son 1.3.7.0 y 1.4.1.3. Veamos las diferencias funcionales más importantes, emparejando cada una con las versiones más conocidas:

- Nombres fijos, como en las 1.x, pero se esconden en %windir%, no en %system%. Los nombres utilizados para el exe, fichero de configuración y fichero de datos son:
  1. c:\windows\host32.exe
  2. c:\windows\jh87uhnoe3\ewf32.nls
  3. c:\windows\jh87uhnoe3\ewfrvbb.nls
  1. c:\windows\svhost32.exe
  2. c:\windows\efee3f32f\brrve.nls
  3. c:\windows\efee3f32f\wrfsf.nls

- La ruta de arranque con el sistema se trata de la misma utilizada por las ramas 1.x (Winlogon), pero es continuamente machacada (como en la 2.x), por lo que para desinfectar la máquina no basta con borrarla y reiniciar la máquina.


- Los ficheros permanecen ocultos (igual a la versión 1.x), imposibilitando el borrado del mismo como sistema de desinfección.

- Como se aprecia en la captura anterior, su nueva casa es services.exe, no winlogon.exe (v1.x)

- El pipe es: "_FISIDISI223122347_"

- Conexión cifrada. Tanto la descarga del fichero de configuración como el acceso al panel de control se realiza bajo conexión SSL. Esto es nuevo, ya que tanto la 1.x como la 2.x realizan una conexión HTTP en claro (enviando los datos cifrados con sus respectivos algoritmos).

- Cambio de cifrado. El cifrado utilizado es el RC4 visto hasta ahora, pero con un pequeño cambio, simplemente modificando el "step". No se utiliza la capa de xor utilizada en las 2.x.


Nos encontramos, por tanto, ante una versión con bastantes cambios respecto a la habitual 1.x. ¿Se seguirá desarrollando la misma o definitivamente todo el mundo optará por la versión 2?

Para terminar, comentar que si alguno se encuentra con una muestra como la descrita, el paso más sencillo para desinfectar la máquina puede ser descargarse alguna herramienta anti-rootkit como gmer, localizar el fichero, realizar un "kill" sobre él para dejarlo inútil, y reiniciar el ordenador. Tras esto las entradas de registro y ficheros podrán ser borradas sin problema alguno.

Mikel Gastesi
S21sec e-crime






Windows DLL Hijacking

Durante los últimos días, la avalancha de nuevos advisories que se refieren a esta vulnerabilidad está causando bastante revuelo. Ya hay contabilizadas más de 100 aplicaciones vulnerables y la lista parece que continúa creciendo. ¿Realmente es para tanto? Veamos:

La nota detonante ha sido este documento en el cual se reporta una vulnerabilidad que afecta a la aplicación iTunes. Básicamente el problema consiste en la posibilidad de ejecutar código de forma remota, "invitando" a un usuario a abrir con iTunes un archivo inofensivo, ya sea desde una unidad local, una carpeta compartida o una unidad usb. Este archivo se acompaña de una librería específica requerida por la aplicación vulnerable. Cuando la aplicación procede a la apertura del archivo realiza la carga en memoria de esta librería en lugar de la original. ¿Cómo es esto posible?

La explicación técnica es bastante sencilla. Cuando una aplicación de Windows carga de forma dinámica una librería sin especificar la ruta completa, Windows busca esta librería siguiendo un orden específico. Las funciones encargadas de realizar la carga de la librería son LoadLibrary y LoadLibraryEx. Este es el orden de búsqueda del archivo DLL de estas dos funciones:

1. El directorio desde el que se cargó la aplicación
2. El directorio del sistema
3. El directorio del sistema de 16 bits
4. El directorio de Windows
5. El directorio de trabajo actual
6. Los directorios enumerados en la variable de entorno PATH

Si consultamos la documentación oficial de Microsoft vemos que se recomienda no utilizar la función SearchPath para obtener la ruta completa al archivo DLL al utilizarla posteriormente para llamar a LoadLibrary. Esta recomendación se basa en el hecho de que la función SearchPath usa un orden de búsqueda diferente de los archivos, comenzando por el directorio de trabajo. La forma más sencilla de evitar este problema es llamar previamente a la función SetDllDirectory pasándole como parámetro una ruta en blanco, eliminando así el directorio actual del orden de búsqueda por defecto de los archivos DLL.


Verificando la vulnerabilidad.

Unas pruebas rápidas en un entorno controlado son suficientes para comprobar cómo es bastante fácil encontrar aplicaciones vulnerables y cómo explotar esta vulnerabilidad.
Nuestro conejillo de indias será el archivo GRPCONV.EXE incluido en Windows XP, esta aplicación es el conversor de grupos para el Administrador de programas de Windows.

La siguiente es una captura de pantalla de Windbg (debugger) en la cual se aprecia la carga de la librería imm.dll desde el directorio de trabajo en el cual se abre un archivo grp.



La librería imm.dll original que carga la aplicación, se ha sustituido por otra que en realidad es un exploit a medida, el cual proporciona una shell a otro equipo de pruebas con dirección IP 172.17.1.89.



¿Cual ha sido la respuesta de Microsoft?

La siguiente actualización de seguridad proporciona una nueva entrada del registro de Windows CWDIllegalInDllSearch, que permite a los administradores controlar la ruta de búsqueda de las dlls cargadas por las aplicaciones. Mediante esta nueva entrada es posible definir lo siguiente, ya sea para cada aplicación o para todo el sistema:

- Quitar el directorio de trabajo actual de la ruta de búsqueda de la biblioteca.
- Impedir que una aplicación cargue una biblioteca desde una ubicación de WebDAV.
- Impedir que una aplicación cargue una biblioteca desde un WebDAV o desde una ubicación UNC remota.

Es curioso cómo una vulnerabilidad que fue descubierta por Georgi Guninski en el año 2000, y que en su momento (2001) fue activamente explotada por el gusano Nimbda, vuelve a ponerse de actualidad. Pues sí, me temo que no se trata de algo nuevo. Esta era precisamente una de las técnicas que utilizaba Nimbda para propagarse mediante la copia de la supuesta librería riched20.dll en directorios con archivos .doc.

Daniel Peláez.
Dpto. Auditoría.

Referencias:
Nimda (Detalles técnicos)
Microsoft Hotfix kb2264107





S21sec analiza la seguridad de Tofino


Recientemente Byressecurity y S21sec labs han anunciado que están trabajando conjuntamente en la evaluación de seguridad de Tofino, un firewall específico para entornos de control industrial (SCADA). El trabajo está enmarcado dentro de las evaluaciones que S21sec labs realiza en el laboratorio SCADA de Pamplona para el análisis de las características de seguridad de los productos SCADA.


Tofino Industrial Security solution es una tecnología de firewall SCADA de la que ya se realizó una introducción en este blog hace unos meses y que recientemente ha recibido un galardón de la consultora Frost&Sullivan como mejor producto de seguridad industrial en 2010. Tofino va a lanzar en breve una nueva versión con nuevas características de seguridad basadas en parte en este estudio.


Daniel Chavarri & Iñaki Lopez

S21sec labs






(+34 902 222 521)


24 horas / 7 días a la semana



© Copyright S21sec 2012 - Todos los derechos reservados


login