Feliz 2015

Esta es la última entrada del año 2014 que ha estado lleno de altibajos, carreras, emociones y estrés, así como también de tranquilidad, descanso y relax. Son 365 días que dan para mucho, aunque para mi, siempre se me hace corto y quiero más y más. Voy a intentar destacar y repasar lo sucedido este año 2014 para evaluarlo y así tratar de mejorar en el 2015.

Soy Ingeniero Informático pero desde que nací llevo de serie un extra, y es que soy persona, es inevitable y aunque muchos puedan pensar que los Informáticos sólo entendemos de ceros y unos, también tenemos que relacionarnos con las personas, y eso me encanta. Para un Ingeniero la parte técnica es importante, pero más importante aún son las relaciones personales, saber escuchar, hacerse entender, compartir, trabajar en equipo y realizar críticas constructivas y razonadas es algo que no se enseña en la carrera y que uno lo va aprendiendo con el paso de los años. Por eso, procurar proporcionar confianza, no fallar y defraudar a nadie, ser confiable y estar disponible siempre que nos necesiten es muy importante a nivel personal y profesional para tener calidad de vida, así como también para proporcionar calidad a los proyectos profesionales. Mi deseo por seguir creciendo como persona me llevó este verano a Turquía para trabajar como voluntario en un campo de trabajo, esto hizo que creciese personalmente al trabajar codo con codo con un equipo de personas compuesto por más de cinco nacionalidades distintas, cada uno con sus creencias, virtudes y defectos.

A nivel formativo en este año 2014 he obtenido la certificación CISA, que valida mis aptitudes como Auditor de Sistemas de Información, lo cual me llevó a presentarme al primer Reto ISACA para jóvenes profesionales, logrando un áccesit con la propuesta ¿estamos vendidos? desde donde intenté transmitir y reflejar la dependencia tecnológica que tiene actualmente España para proteger sus infraestructuras. En paralelo he continuado mis estudios con el idioma Inglés, consiguiendo el certificado B2, estando actualmente en el primer curso del nivel C1. Técnicamente me he re-certificado en la versión 5 de FCNSA que valida mis conocimientos para la instalación, mantenimiento y configuración de equipos de seguridad perimetral del fabricante Fortinet, así como también he recibido un curso de gestión de proyectos orientado a la certificación CAPM a través de Feval. Desde esta misma institución he tenido la oportunidad de impartir dos cursos de redes orientados a la certificación CCNA de Cisco, concretamente un curso de Introducción a Redes y otro de Fundamentos de Routing y Switching. Además a principios de año impartí otro curso de balanceadores de carga del fabricante F5. Mientras tanto, sigo aprendiendo nuevos conceptos, técnicas y tecnologías haciendo Webinars online, así como también leyendo libros como por ejemplo el último sobre la primera ciberarma digital de Kim Zetter.

A nivel profesional comencé el año en un proyecto de asesoramiento, instalación, configuración y soporte de balanceadores de carga Radware. Este año he vuelto a participar en un proyecto de reconfiguración de rutas BGP para la Red Científico-Tecnológica de Extremadura, instalando además un servidor de monitorización fuera de banda para medir la disponibilidad y controlar los recursos utilizados, también he tenido la oportunidad de colaborar en pruebas de continuidad para una compañía privada que consistía en desacoplar Peers BGP de su sistema autónomo. Además he intervenido en un proyecto de instalación y mantenimiento de una red inalámbrica para ofrecer servicios de Internet a ciudadanos en espacios públicos, así como en otros proyectos de instalación, sustitución, configuración y mantenimiento de sistemas de seguridad perimetrales y antispam. No todos los proyectos en los que he participado han sido de seguridad y redes, sino también de sistemas y almacenamiento, por ejemplo he participado en un proyecto de puesta en marcha de una plataforma de Cloud Computing basada en Open Nebula con equipamiento HP y Cisco, además de haber instalado y configurado cabinas de almacenamiento Netapp. En paralelo he ayudado a prestar los servicios que Ariadnex proporciona desde Ariolo Cloud Services, instalación y mantenimiento de sondas y sistemas SIEM, elaboración de auditorías de seguridad y redes, mantenimiento de las certificaciones ISO 27001 e ISO 20000, además de contribuir en la redacción de ofertas técnicas.

Como objetivos para el 2015 voy a seguir formándome en materia de seguridad y redes, presentándome a la certificación FCNSP de Fortinet, también tengo pensado comenzar a estudiar la certificación de seguridad CISSP, así como continuar perfeccionando el idioma Inglés, y sobre todo espero seguir creciendo personal y profesionalmente conociendo más y mejor a las personas y participando en proyectos ambiciosos que supongan retos profesionales. Nada más me queda deciros …

Felices Fiestas y Próspero Año Nuevo a todos.

Stuxnet: En busca de exploits 0-days

El origen de la misteriosa bomba de 500 KB aún está por desvelar, pero esta ciberarma digital nos ha mostrado, enseñado y aterrorizado que utilizando una serie de exploits 0-days se puede controlar una central nuclear y que en manos de algún desaprensivo puede llegar a provocar una catástrofe. Tras analizar el funcionamiento de Stuxnet vamos a ver que los atacantes no escatimaron en el uso de exploits para llegar a su destino, la central nuclear de Natanz.

La organización encargada de desarrollar el malware utilizó cuatro exploits 0-days para hacerse con el control del equipo que gestiona el sistema Siemens SCADA. Concretamente aprovecharon las siguientes vulnerabilidades:

1. Vulnerabilidad en los enlaces de acceso directo de Windows, o archivos .LNK, capaces de ejecutar archivos .DLL maliciosos.
2. Vulnerabilidad en la cola de impresión de Windows para compartir impresoras.
3. Vulnerabilidad en el planificador de tareas de Windows que permitía escalar privilegios.
4. Vulnerabilidad en un archivo del teclado de Windows que permitía escalar privilegios.

Encontrar vulnerabilidades y desarrollar sus exploits para infectar el sistema operativo de la víctima saltándose los permisos de administrador sin que el usuario se percate es una tarea ardua y difícil que no está al alcance de cualquiera. Sin embargo tras la publicación de Stuxnet, Microsoft detectó que la vulnerabilidad que aprovechaba los accesos directos .LNK ya había sido utilizada antes por el troyano Zlob, así como también se conocía la vulnerabilidad que aprovechaba la cola de impresión, ya que ésta había sido publicada en el 2009 por una revista de seguridad polaca. No obstante, Microsoft publicó sus parches tras el descubrimiento de Stuxnet, mientras tanto, estaban ahí fuera para el uso y disfrute de los malos.

En la primera versión de Stuxnet del 2009 el malware utilizaba la característica de Autorun para propagarse, es decir, el malware se ejecutaba automáticamente cuando se insertaba una memoria USB infectada. Posteriormente en la versión del 2010, los atacantes habían sustituido el Autorun por la vulnerabilidad de los accesos directos .LNK, además de firmar el malware con el certificado de la compañía RealTek. Este cambio en el método de propagación provocó que el número de máquinas infectadas ascendiese a 100000, de esta manera los atacantes llegarían antes a su objetivo.

Stuxnet es muy potente por la cantidad de exploits y métodos de propagación que dispone para pasar desapercibido. De los 8 métodos de propagación podemos destacar la manera de infectar archivos de proyecto del software Step 7 de Siemens, mediante la infección del fichero de proyecto, se puede infectar la base de datos de backend que comparten todos los programadores que trabajen en el proyecto, de esta manera al estar la base de datos infectada, se pueden infectar todos los trabajadores del proyecto.

Además de derrochar en exploits y utilizar cuantiosos métodos de propagación, Stuxnet era capaz de mantenerse actualizado utilizando un componente P2P que configuraba a las máquinas en modo cliente/servidor, así como también registraba en cada máquina mediante un log la IP, nombre de dominio y timestamp de los equipos infectados. Log que ayudó a los investigadores a concluir que el foco de la infección se encontraba en Irán.

En definitiva, estamos ante un despilfarro de exploits, métodos de propagación y técnicas de actualización muy bien pensadas y probadas para conseguir sabotear las centrifugadoras nucleares de Irán.

¿Quién está detrás de todo esto? Parece ser que puede ser un problema de estados.

Un saludo amigos!

Stuxnet: Analizando su funcionamiento

La primera ciberarma digital que llegó a infectar a más de 300.000 equipos en más de 100 países distintos era una bomba de 500 KB desarrollada para ralentizar el enriquecimiento de uranio en la central nuclear de Natanz ubicada en Irán. Continuando con la serie de capítulos del libro Countdown to Zero Day de Kim Zetter veremos realmente cómo funcionaba esta obra de ingeniería.

Como cualquier otro malware, la primera ciberarma digital se puede dividir en dos partes. Por un lado, el payload que se encarga de propagar el virus por diferentes equipos, y por otro lado el payload que se encarga de robar información o hacer cualquier otra cosa, en este caso atacar sistemas PLC de Siemens.

Stuxnet, como así se llama la ciberarma, lo primero que hacía era comprobar si la máquina donde se iba a desplegar era de 32 o 64 bits, ya que este malware tan solo funcionaba sobre máquinas Windows de 32 bits. Después, comprobaba si la máquina ya estaba infectada, si era así, comprobaba si existía alguna actualización de Stuxnet para descargarse la última versión disponible. En cambio, si la máquina aún no estaba infectada procedía a determinar la mejor manera para infectarla.

Para infectar la máquina se pone en marcha un rootkit que esconde los archivos de Stuxnet al sistema operativo, de esta manera los nombres de los archivos de Stuxnet no podían ser vistos por los motores de antivirus y no eran analizados. Si un escáner de malware intentaba leer el contenido de la memoria USB que estaba infectando la máquina, el rootkit interceptaba los comandos y devolvía una lista modificada de los archivos que contenía la memoria USB, obviamente eliminando de la lista los nombres de los ficheros de Stuxnet para que no fuesen analizados. Sin embargo, Stuxnet no podía hacer un bypass de todos los motores de antivirus, así que para aquellos motores que no podía controlar la infección, Stuxnet se paraba y se terminaba la infección.

A continuación, si Stuxnet decidía proceder porque podía hacer un bypass del antivirus se activaba un segundo driver con dos tareas. La primera tarea consistía en infectar cualquier otra memoria USB que estuviera conectada. La segunda, y más importante, era descifrar y cargar la biblioteca .DLL, y varios de sus componentes, en memoria. A continuación descomprimía la DLL para obtener otras DLL más pequeñas. Una vez que todas las DLL estaban en memoria, Stuxnet buscaba otras máquinas para propagarse y después se ponía en contacto con el C&C. Obviamente, como todas las DLL estaban en memoria cada vez que el equipo se reiniciaba se borraban, así que el driver en cada reinicio tenía que volver a cargar las DLL a memoria.

Posteriormente el malware hacía un inventario del software instalado en la máquina y lo enviaba al C&C, si no encontraba ningún software de Siemens ni el WinCC, Stuxnet quedaba inactivo. Si por el contrario encontraba software de Siemens, concretamente Siemens Step 7, y/o el WinCC, buscaba las PLC S7-315 y S7-417 de Siemens. Sólo esta combinación de hardware y software hacían posible descifrar y lanzar el ataque.

A continuación podemos ver las fases del ataque:

 

Además de la manera de cómo evitar los antivirus y la forma de cargar los archivos en memoria, Stuxnet monitorizaba los recursos de la máquina infectada para comprobar si la ejecución del malware sobrecargaba la máquina. Si Stuxnet utilizaba demasiada CPU o memoria podría ser detectado. Stuxnet también eliminaba los archivos temporales que no necesitaba para pasar desapercibido.

Encontrar evidencias suficientes para conocer el origen del malware es algo muy complicado a no ser que los propios desarrolladores dejen alguna "pista". Algunos desarrolladores utilizan técnicas para que sus propios equipos no se infecten con su propio malware, para ello antes de infectar un equipo el malware realiza una serie de comprobaciones para conocer si la máquina que va a infectar pertenece al desarrollador. Stuxnet parece que tenía algo parecido, antes de infectar la máquina comprobaba un registro de Windows y si dentro de ese registro se encontraba la cadena 0x19790509, la máquina no era infectada. Inmediatamente los investigadores se pusieron a investigar qué podría significar esta cadena. Una hipótesis dice que la cadena pertenece a una fecha, concretamente el 9 de Mayo de 1979, fecha que coincide con la ejecución de Habib Elghanian, un importante hombre de negocios de la comunidad judía en Irán. Tras su muerte muchos judíos migraron hacia Israel.

Otra evidencia que se encontró en el código de Stuxnet que hace pensar que Israel está detrás de su desarrollo fue que el compilador del malware dejó rastro del path donde se encontraba el proyecto. Concretamente la cadena b:\myrtus\src\objfre_w2k_x86\i386\guava.pdb que nos indica que el nombre de usuario de la máquina es myrtus, que coincide con el nombre hebreo de la reina judía que evitó una masacre de judíos en el imperio persa.

Otra hipótesis del significado de myrtus puede significar My RTUs, haciendo referencia a Unidades de Terminal Remoto que son componentes usados para monitorizar y operar equipamiento industrial.

Sea cual sea la verdad, la especulación de quién está detrás de este sofisticado ataque está abierta para todos los investigadores.

Stuxnet: Una bomba de 500 KB

En la anterior entrada hablé sobre el descubrimiento por parte de VirusBlockAda de la primera ciberarma digital, Stuxnet, que utiliza certificados digitales robados y aprovecha una vulnerabilidad de los ficheros .LNK en los sistemas operativos Windows. Todo ello extraído de la historia que cuenta el libro Countdown to Zero Day de Kim Zetter.

Aunque normalmente un malware ocupa entre 10 y 15 KB de memoria, Stuxnet es un arma que está muy por encima de la media con 500 KB, que tras descomprimirlo ocupa 1,18 MB. Sólo el tamaño ya nos indica la potencia de esta ciberarma por la cantidad de módulos y configuraciones que tienen cabida en algo más de 1 MB de código.

Si analizamos tan solo las primeras líneas del código del malware nos daremos cuenta enseguida que las técnicas empleadas van más allá de lo normal, utiliza técnicas de ocultación y propagación que ningún otro malware jamás ha utilizado. Es un malware muy pensado y muy trabajado, un malware profesional que no se conforma con lo mínimo para no ser detectado.

Stuxnet es un malware preparado para ser desplegado mediante una memoria USB, está compuesto por un fichero .DLL cifrado que contiene tres docenas de ficheros .DLL dentro del .DLL principal. Además incorpora ficheros de configuración listos para realizar cambios desde el C&C. Una vez infectada la máquina, el malware no guardaba las bibliotecas DLL en disco, sino que para eludir los antivirus las guardaba directamente en memoria y era capaz de controlar la API de Windows para decirle a los antivirus que allí no había nada que “mirar”.

Una memoria USB con Stuxnet tan solo podía desplegar el malware en tres equipos distintos, es decir, una vez infectadas tres máquinas, el malware se auto-destruía. Stuxnet lo primero que hacía era realizar un inventario del software instalado en la máquina infectada, posteriormente realizaba una búsqueda de software de Siemens, si la máquina víctima no tenía software Siemens se propagaba a otra máquina y el malware se apagaba, si en cambio tenía software Siemens instalado, enviaba la lista del software instalado al servidor de C&C donde los atacantes podría comprobar si se trataba de la máquina que buscaban. Además de la lista de software instalado también enviaba el nombre de la máquina, dominio, IP interna y versión de Windows.

Según los análisis realizados por Symantec, los servidores de C&C se encontraban en los dominios mypremierfutbol.com y todaysfutbol.com, registrados con nombre y tarjetas faltas en Dinamarca y Malasia. Una vez que Symantec se hizo con el control de los dos dominios del C&C detectó unas 38000 infecciones con un ratio de crecimiento de 9000 infecciones al día, aunque al final se detectaron más de 300.000 infecciones en más de 100 países, de las 38000 infecciones detectadas inicialmente, 22000 procedían de Irán y 217 tenían software Siemens instalado, por lo que estaba claro que el origen del foco de infección procedía de Oriente Medio, precisamente de Irán.

Irán nunca ha sido el principal objetivo del malware, siempre ha tenido bajas infecciones. Sin embargo, esta ciberarma digital se saltaba las estadísticas y patrones, ya que estaba claro que Stuxnet no había sido desarrollado para robar fórmulas secretas de laboratorios farmacéuticos ni de entornos industriales, sino de infraestructuras críticas procedentes de Irán.

Tan solo nos queda plantearnos algunas preguntas, ¿se han metido las compañías de antivirus en un problema de estados? ¿han saboteado los planes de algún estado?

Stuxnet: La primera ciberarma digital

Este mes de Noviembre ha sido el lanzamiento del libro Countdown to Zero Day de Kim Zetter donde se explica desde el inicio el descubrimiento de la primera ciberarma usada para ralentizar el enriquecimiento de uranio de la central nuclear de Natanz en Irán. Stuxnet, como así lo apodó Microsoft, tenía un objetivo muy claro, sabotear el enriquecimiento de uranio para prevenir que el presidente Mahmoud Ahmadinejad construyera una bomba nuclear.

Todo comenzó en Junio del 2010, cuando una pequeña compañía de Bielorrusia llamada VirusBlockAda detectó comportamientos anómalos en un equipo de uno de sus clientes ubicado en Irán. Al parecer la máquina se reiniciaba sola, la “limpiaron” y continuaba comportándose de forma irregular. Inicialmente su antivirus no detectaba ningún tipo de malware pero tras un análisis exhaustivo realizado por los expertos de la compañía pudieron detectar un ataque zero day que afectaba a todos los equipos Windows, incluso aquellos actualizados a la última versión. Se trataba de ficheros .LNK que los sistemas operativos Windows analizan para mostrar los iconos de los ejecutables. Inmediatamente, VirusBlockAda desarrolló su propia firma para que su antivirus detectara el zero day, sin embargo esta pequeña compañía ubicada en Bielorrusia no fue tenida en cuenta por los grandes fabricantes hasta que publicaron su descubrimiento en su página web y en foros de seguridad.

Una vez que el zero day estuvo en manos de Microsoft, además de otras compañías de antivirus acostumbradas a analizar códigos complejos como Kaspersky, se detectó que el malware podía vivir perfectamente en el kernel del sistema operativo junto con los principales software de antivirus sin ser detectado. Sin embargo, el malware no podía coexistir con el antivirus desarrollado por la pequeña compañía VirusBlockAda, los equipos infectados que tenían su software antivirus producían un crash del sistema operativo, y este fue el principal motivo de su detección. Conforme se siguió en la investigación del malware, el siguiente paso fue descubrir que el driver instalado por Stuxnet estaba firmado digitalmente por la compañía Taiwanesa Realtek Semiconductor y esta fue la principal causa por el cual los equipos Windows permitían instalar el driver infectado, es decir, confiaban en el driver porque estaba firmado digitalmente por una compañía confiable.

Una vez revocado el certificado digital de Realtek y desarrollada las firmas para los antivirus, el 17 de Julio la empresa de antivirus ESET detectó una variación de Stuxnet que utilizaba otro certificado digital para compilar el malware, esta vez de otra compañía Taiwanesa llamada JMicron Technology, que casualmente sus oficinas se encuentran en el mismo edificio que las de Realtek. La fecha de compilación del binario tan solo era de dos días posterior a la primera publicación oficial de Stuxnet. ¿Qué pretendían los atacantes? ¿Cómo habían robado los certificados?

En cualquier caso, estamos ante un ataque muy profesional, posiblemente desarrollado por una docena de expertos en seguridad con el apoyo de algún gobierno, ya que Stuxnet no estaba preparado para robar credenciales bancarias, sino para modificar un sistema de control industrial diseñado para trabajar con PLC de Siemens.

Animo a todos aquellos apasionados por la seguridad a leer este interesante libro, que iré recapitulando en futuras entradas.

Un saludo amigos!