La seguridad en los dispositivos wearables

Este articulo es la transcripción al blog de un powerpoint que cree para hacerme a la idea de los desafio desde el punto de vista de seguridad que representan los wearables a dia de hoy (Diciembre 2014). Al final de la entrada adjunto dicho PPT [18].

Por si alguien no sabe lo que son, los wearables se pueden definir como “el conjunto de aparatos y dispositivos electrónicos que se incorporan en alguna parte de nuestro cuerpo interactuando continuamente con el usuario y con otros dispositivos con la finalidad de realizar alguna función específica” [1]. Los wearable se basan en el paradigma de wearable computing [2], dicho paradigma ha evolucionado en torno a tres factores:

• La minimización del tamaño de los ordenadores
• El incremento de su potencia computacional
• La cada vez mayor movilidad de las personas y su conectividad global
• La cada vez mayor personalizacion de los dispositivos

Con esta definición podemos encontrar en el mercado los siguientes tipos de wearables:

• Relojes para hacer fitness:
  
• Relojes inteligentes:
  
• Gafas inteligentes:
  
• Gadgets de todo tipo:
  
• Smart clothing:
  
• Wearables para la salud:
  

Casos concretos

Apple iWatch

A la venta en 2015. Se conoce muy poco del dispositivo, pero presumiblemente vendrá con iOS 8.1.1, versión de iOS ya Jailbreakeada. Y con vulnerabilidades aún por arreglar [17].

Android Wear

Usado por los relojes LG G y Samsung Gear Live (Ya rooteados) [10].

Una característica importante que tiene es que no hay WebViews en Android Wear y esto significa que nos libramos de problemas como los Cross Site Scripting (XSS) o Cross Site Request Forgery (CSRF). La navegación se realiza a través del telefono Android, lo que quiere decir que los dispositivos wearables android se basan fuertemente en la comunicación con el teléfono Android. Un ataque MITM supondría el control total del dispositivo wearable.

Samsung Gear 2

Samsung Galaxy Gear 2 está diseñado para emitir un ruido fuerte cuando se está haciendo una foto. Tras el rooting y utilizando ODIN, herramienta de software de Samsung, es posible habilitar Galaxy Gear 2 para hacer fotos con la cámara integrada pero en silencio. Esto abre la puerta a escenarios para violar la privacidad de otras personas”.

Algunas aplicaciones de Galaxy Gear 2 se cargan en el dispositivo con la ayuda de Gear Manager, una aplicación especial de Samsung diseñada para transmitir una app desde el smartphone al smartwatch. Cuando la aplicación se instala en el sistema operativo del reloj no se muestra ninguna notificación en la pantalla del reloj. Esto hace que los ataques dirigidos que implican la instalación de aplicaciones en silencio sea posible”.

Google Glass

Las Google Glass tienen dos formas distintas de conectarse a internet: O bien uniendo el dispositivo vía Bluetooth con el dispositivo móvil con el que comparte su conexión, o directamente uniendose a una red por wifi.

La primera opción puede llevar a ataques de bluejacking, bluesnarfing, etc. La segunda opción no requiere de otro dispositivo móvil para navegar, pero puede provocar ataques MITM.

De hecho es sabido que no todo el tráfico que se intercambia entre el dispositivo y el hotspot esta cifrado. En particular, es posible saber que sitios web esta visitando el usuario de las gafas y llevar a cabo una tarea de perfiles, una forma sencilla de vigilancia [11]. Otra vulnerabilidad conocida es la de la navegación automática de códigos QR [16].

Las características comunes de todos ellos son pocas o ninguna, cada fabricante fabrica sus productos con características y funcionalidades completamente dispares. En la actualidad no existen estandares asentados en el mercado que permitan unificar tanto las comunicaciones como la programación de estos dispositivos [3] [7]. Únicamente los fabricante que tienen distintos wearables, permiten cierta interconexión entre los mismos.

Como decía no existe una API común para el desarrollo de Apps para dispositivos wearables (con la honrosa excepción de Android Wear [8]). Además las apps y los propios dispositivos wearables han tenido un bajo nivel de testaje (desde el punto de de vista de la seguridad).

Históricamente las características comunes de los wearables han sido:

• Bajo consumo (necesidad de baterías pequeñas)
• Interfaces de usuario simples
• Bajo nivel de comunicación
• Bajo nivel de seguridad
• Poco peso requerido

Desde el punto de vista de seguridad se pueden mencionar los siguientes retos que es necesario afrontar:

• Autenticación
• Cifrado de contenidos
• Securización de sus comunicaciones
• Ataques remotos

Autenticación

Los dispositivos wearables requieren interfaces de usuario cada vez más complejas. Ya no basta un botón y una interfaz de usuario monocroma que muestre el modo del menu en el que se encuentra. Cada vez viene siendo más importante que el uso sea gráfico con gestos como los que usamos en tabletas y móviles. Y esto requiere una mayor complejidad tanto hardware como software, con un sistema operativo debajo y apps que se puedan descargar para satisfacer las necesidad del usuario final. Por supuesto, a nivel de hardware esto supone mayor necesidad de potencia computacional y una mayor necesidad de baterías potentes pero a la vez pequeñas. Un verdadero reto a todos los niveles: software y hardware.

Desde el punto de vista de autenticación, al almacenar información privada en los dispositivos, es necesaria, al igual que ocurre en los móviles algún tipo de autenticación para que, en caso de extravío el dispositivo wearable no pueda ser utilizado ni la información almacenada en el mismo accedida. Es por ello que cada vez es más común que estos dispositivos disponga de un formulario donde introducir una contraseña con la que poder acceder a todas las funcionalidades del wearable. El proceso de autenticación y el almacenamiento de esta contraseña requiere de la utilización de funciones de hashing (MD5, SHA1...) que son computacionalmente muy intensivas, al tiempo que la experiencia de usuario requiere que el tiempo de autenticación sea corto. Esto hace que cada vez sean necesarias mejores circuitería para satisfacer las necesidades de seguridad de estos dispositivos.

Cifrado de los contenidos

Otro de los frentes abiertos en el área de la seguridad de los wearables es la protección de los "contenidos" que almacenan. En mayor o menor medida todos los wearables tiene cierta capacidad de almacenar datos que podría ser muy utiles a atacantes maliciosos. Se hace necesario que estos contenidos esten cifrados para casos como la pérdida o sustracción del dispositivo.

Sin embargo el cifrado de contenidos es un arma de doble filo. Por un lado porque reduce el rendimiento computacional del dispositivo, requiere mayor capacidad de baterías y requiere mejores procesadores. Se podría usar un cifrado más ligero, una especia de cifrado CESAR de transposición, pero esto, por supuesto supondrá un menor nivel de seguridad [5]. Es necesario llegar a un equilibrio para conseguir un buen nivel de cifrado a un coste computacional, de rendimiento y de experiencia de usuario mejores.

Seguridad en comunicaciones

Otro de los aspectos claves en los que incidir es la securización de las comunicaciones entre dispositivos y entre los dispositivos y sus "bases", entendiendo éstos los equipos que les permiten actualizarse y/o comunicarse con internet (móviles, portátiles, routers, etc).

Estas comunicaciones requieren autenticación y cifrado (lo que implica un incremento del grado de computación). En caso de que se utilizaran métodos de cifrado/securización “non-consuming” éstos serían poco seguros (Por ejemplo la utilización de tecnologías como Bluetooth o Zigbee supone una deficiente implementación de la seguridad por carecer estos protocolos de características adecuadas de cifrado). Las tecnologías actualmente más utilizadas (Wifi con WPA2, UMTS, etc) provocan un mayor consumo energético.

Ataques contra wearables

Actualmente no hay evidencias que hagan pensar que los wearables están en el punto de mira de los ciberdelincuentes, es probable que en el futuro se conviertan en objetivo si llegan a ser son adoptadas ampliamente por los consumidores. [12]

No hay que olvidar que los wearables no son mas que otra "thing" más del Internet Of Things (IoT). Actualmente ya se esta hablando de botnets de things (thingbots) [13][14][15], por lo que es asumible pensar que en el futuro un wearable pudiera formar parte de una botnet.

Además hay que tener en cuenta el caracter personal de los wearables. Estos dispositivos pueden ser una fuente de problemas de privacidad en caso de que un atacante remoto pudiera conseguir acceder a ellos.

Publicaciones existentes en cuanto a seguridad en wearables

A.- Wearable Computers, 2002 (ISWC 2002). Blasko, G. and Feiner S. Security challenges for wearable computing. A case study. (IFAWC 2007). Lindström J. (https://pure.ltu.se/portal/files/2508129/security_challenges_for_wearable_computing.pdf)

B.- Secure wearable and implantable body sensor networks in hazardous environments (DCNET 2010). Wearable Computing. Challenges and opportunities for privacy protection. Office of the privacy commisioner of Canada. (https://www.priv.gc.ca/information/research-recherche/2014/wc_201401_e.pdf)

Ventajas e inconvenientes de la investigación en este campo

Ventajas

• Poco investigado
• Mucho interés potencial por parte de la sociedad (Previsión de 171 millones de wearables en 2016) [6]

Inconvenientes

• Económico: Puede requerir la adquisición de dispositivos
• Mercado: Muchos fabricantes, poca estandarización
• Investigación privada (fabricantes)

---

[1] - http://www.quees.info/que-es-wearable.html
[2] - Security challenges for wearable computing. A case of study.
[3] - Open Wearable Computing Group
[4] - Wearable Computing Challenges (2011)
[5] - Secure wearable and implantable body sensor networks in hazardous environments, Hamdi, M. ; Boudriga, N. ; Abie, Habtamu ; Denko, Mieso; Communications Networks and Security Research Lab., Ariana, Tunisia
[6] - 3 World Market for Wearable Technology – A Quantitative Market Assessment – 2012, IMS Research, August 2012
[7] - http://www.ce.org/i3/Features/2014/January-February/Getting-Wearables-Right.aspx
[8] - https://developer.android.com/wear/index.html
[9] - http://blog.nvisium.com/2014/07/getting-started-with-android-wear.html
[10] http://www.eteknix.com/galaxy-gear-gets-custom-rom-third-party-app-web-browsing-support/ , http://www.androidcentral.com/hacking-android-wear
[11]- http://www.baquia.com/tecnologia-y-negocios/entry/emprendedores/kaspersky-lab-advierte-de-los-riesgos-de-seguridad-de-los-dispositivos-wearables
[12] - http://cso.computerworld.es/seguridad-movil/wearables-una-amenaza-para-la-privacidad
[13] - http://whatis.techtarget.com/definition/IoT-botnet-Internet-of-Things-botnet
[14] - http://www.proofpoint.com/about-us/press-releases/01162014.php
[15] - http://securityaffairs.co/wordpress/28642/cyber-crime/spike-botnet-runs-ddos.html
[16] - http://usa.kaspersky.com/internet-security-center/internet-safety/google-glass-security
[17] - http://www.zdziarski.com/blog
[18] - Powerpoint Wearable Security

El negocio de los Drive-by-downloads

La creciente concienciación de los usuarios con respecto a las buenas prácticas de seguridad en la navegación por internet provocó, hace un par de años, la aparición de nuevas técnicas, por parte de los ciberdelincuentes que permitían la infección del ordenador del usuario sin la intervención de éste.

Entre esas técnicas apareció lo que se ha venido a llamar técnicas drive-by-download. Esta técnica se basa en aprovechar vulnerabilidades del software de navegación de la víctima (ya sean Internet Explorer, Mozilla Firefox, Google Chrome, Opera, Safari, o cualquiera de la miríada de navegadores que se existen por internet) para infectar el equipo del usuario, en el mismo momento y por el simple hecho de que la víctima visite una página web maliciosa o legítima pero comprometida.

Para facilitar esta técnica existen lo que se llaman exploit-kits que se venden en el mundo underground (por precios tan reducidos como 100$ por licencia). Hay un gran numero de estos exploit-kits, como BlackHole (tal vez el más conocido, aunque ya en desuso), Phoenix, eCore, Eleonore, Incognito, Angler, CottonCastle, JustExploit, Cool EK... pero el numero total de ExploitKits existente desde la aparición del primero (MPack en 2006) supera el centenar.

Un exploit kit puede constar de uno o dos componentes principales. Por una parte, un script, generalmente escrito en PHP o Javascript ofuscado que se instala en una página legítima comprometida, que tiene como única tarea la redirección de la victima hacia un servidor de explotación. En ocasiones este script no existe y es el propio servidor comprometido el que actúa como servidor de explotación. El servidor de explotación contiene un "bundle" o paquete de exploits que son los que se intentan instalar en el equipo de la víctima.

Se encuentran en el mercado negro exploit kits (EK) "inteligentes" y "tontos". Un EK "tonto" simplemente intenta ejecutar todos los exploits que vienen en el paquete contra el navegador de la víctima independientemente de cual sea éste y cuales sean sus características. Los EK inteligentes en cambio comprueban cuales son las versiones del navegador, cuales son las extensiones instaladas y otras características e intentan ejecutar solo unos pocos exploits contra ese navegador. Por supuesto, los EK inteligentes son más caros que los tontos en el mercado negro⁵.

Pero los exploit kits ya no solo se aprovechan de las vulnerabilidades en los navegadores si no de todas las extensiones que llevan instaladas y de los programas que utilizan para mostrar las páginas web cada vez más complejas que encontramos en nuestra navegación diaria. Actualmente todos los exploit kits se aprovechan de vulnerabilidades en los lectores de PDF, Flash y por supuesto, de Java).

El funcionamiento de estos exploit-kits es casi siempre igual. Lo primero de todo es necesario conseguir tráfico (es decir visitas) hacia el servidor donde esté instalado el exploit-kit. Para ello existen dos opciones:

• O bien comprometer un servidor legítimo e inyectarle código para que, además de mostrar la página web legítima nos redirija hacia nuestro servidor malicioso.
• O bien conseguir visitas directamente hacia un servidor malicioso, cosa mas complicada de conseguir.

La primera opción generalmente se consigue inyectando código en la pagina web legítima, generalmente código JavaScript o PHP, que lo que hace es abrir una nueva ventana de nuestro navegador, generalmente oculta (invisible) y/o con un tamaño de página de un pixel. Esa ventana tan pequeña cargará una web maliciosa controlada por el atacante que comprobará el tipo y la versión del navegador para buscar una vulnerabilidad y explotarla. De esta forma, sin que el usuario se haya dado cuenta, con el simple hecho de visitar una página web legítima (pero que haya sido comprometida) el equipo del usuario habrá sido también comprometido. De esta manera, el ultimo paso consiste en la instalación de un malware en nuestro equipo aprovechando cualquiera de las vulnerabilidades antes mencionadas.

Existe, por supuesto una tercera opción consistente en la compra de tráfico en el mercado negro. Este tráfico procede de sitios legítimos comprometidos. Lo que se nos vende en estos servicios es la modificación del script de redirección de manera que cuando una victima visite esta web comprometida redirija hacia nuestro servidor de explotación. Estos servicios se vende por precios tan reducidos como 40 dólares por 1000 visitas redirigidas⁶.

En la siguiente imagen se puede ver el código fuente de una página web de un servicio de transferencia de dinero que fue comprometido en 2012. Como se puede ver el código javascript, que aparece abajo desofuscado, simplemente abre un iframe de 10x10, oculto, y carga una la web de un servidor de explotación donde el navegador de la victima será atacado en busca de un agujero de seguridad:

En 2011 la web de mysql.com fue comprometida y se le instaló un exploit kit que provocó que entre el 9 y el 14% de los visitantes posteriores quedaran infectados. Dado el volumen de tráfico de este dominio, un alcance del 14% supuso miles de equipos infectados. El acceso a estos equipos infectados fue posteriormente vendido en el mercado negro aportando grandes beneficios para los atacantes⁶.

El mundo del malware se ha convertido en un negocio, con margenes de beneficio incluso mayores que el mercado de la droga³ y que esta forma tan fácil de comprometer equipos es todo un negocio. En concreto el mercado underground ruso se ha especializado en este negocio⁵, en la venta de tráfico legítimo redirigido, exploit kits, servicios Pay-Per_install...

Existen tres formas diferentes, en dichos mercados, de contratar un licencia de un exploit-kit. La más sencilla y que menos conocimientos técnicos requiere es la de contratar un servidor de explotación (un exploit-server) ya instalado, con su exploit-kit ya instalado y con su tráfico de entrada (procedente de un servidor comprometido). Vamos, te lo dan todo hecho. Tu sólo tienes que ir viendo, en el panel de control como van creciendo los equipos comprometidos a los que tienes acceso.

La segunda forma de contratación es alquilando un servidor de explotación con el exploit-kit ya instalado, pero sin el tráfico de entrada. En este caso tu te tienes que currar el comprometer una página web legítima y que redirija el tráfico hacia esta plataforma maliciosa. Esto tampoco es mucho problema, porque sólo será necesario comprar, en el mercado negro, el acceso a una web legítima que haya sido comprometida y redirigirla hacia nuestra plataforma maliciosa.

Estas dos primeras opciones son conocidas como EaaS (Exploitation-as-a-service) y son todo un negocio en auge.

La tercera opción (que es más bien un "do-it-yourself"), consiste simplemente en alquilar el software del exploit-kit para que te lo instales en tu propio servidor y consigas por tu cuenta el tráfico entrante. Esta opción requiere algo mas de conocimientos técnicos pero tampoco especialmente profundos. Es poco menos que un siguiente-siguiente-siguiente.

Como vemos, siempre se habla de alquilar y no de comprar. La razón es que los exploit-kits deben permanecer siempre actualizados, puesto que las vulnerabilidades que aprovechan son constantemente parcheadas en los ordenadores. Los clientes de exploit-kits obtienen actualizaciones automáticas durante el tiempo que tienen contratado el exploit-kit.

Panel de control del Exploit kit Blackhole

Como muestra, un botón. En un estudio¹ se comentaba que cuando salió la versión 2.0 de Blackhole, en tan solo 19 días todos los servidores de explotación conocidos se habían actualizado a dicha versión.

Como vemos los servidores de explotación generalmente son servidores dedicados, es decir, específicamente dedicados a este fin, en vez de servidores comprometidos como podría pensarse.

Esto puede hacer creer que sean fácilmente detectables y cancelables. Sin embargo un estudio¹ detectó que más del 60% de los servidores de explotación pertenecen a servicios de hosting en la nube. Aprovechando el boom de servicios de hosting cloud realmente baratos, con servidores virtuales privados desde 6-8€ al mes y con servidores físicos dedicados desde 50€ al mes, el mercado de los exploit-servers no dudó en migrar hacia la nube. Además, en muchos casos, estos servicios en la nube eran fáciles de contratar, simplemente aportando un tarjeta de crédito, que, de nuevo, es fácilmente comprable a través del mercado negro.

Además, y para acabar de rematar la faena, estos servidores en la nube, permiten la contratación por periodos de tiempo reducidos (a veces hasta de un sólo día), resultando así en cargos menores en la tarjetas (y por tanto más difícilmente detectables) y en mayor movilidad de los servidores de explotación y por tanto mayor dificultad de detección.

El hecho de conocer tan bien este modelo de negocio podría hacer pensar que es fácil de denunciar y parar. Sin embargo son muchas las técnicas que utilizan los ciberdelincuentes para evitar ser detectados.

Otro estudio² revela que la vida media de los servidores de explotación simples (después de su puesta en funcionamiento) es de apenas 16 horas y los dominios que redirigen a estos servidores de explotación tienen una vida media de apenas 2.5 horas. Un típico ejemplo de fast-flux en DNS.

Esto hace que sea virtualmente imposible mover tan rápidamente la maquinaria para la detención de las personas que montan esos servidores y contratan esos dominios. Además, según un estudio ¹ el 60% de los informes de abuso presentados reportando servidores de explotación nunca recibieron respuesta y los que fueron cerrados tardaron una media de 4.3 días ser cerrados.

Además, la utilización de servicios en la nube fácilmente contratables con una simple tarjeta de crédito hacen que sea muy simple utilizar una tarjeta de crédito robada para contratarlos. Cierto es que el exploit server manager debe conectarse a este servidor y debe tener una IP que debe quedar registrada en por los proveedores de servicios en la nube. Sin embargo el uso de redes privadas virtuales, servicios de anonimización y el hecho de que la gran mayoría de las veces estas IPs provengan de oscuros ISPs de países del Este (Rusia, Ucrania, China) hacen poco menos que imposible el arresto de estos ciberdelincuentes.

Por otra parte, generalmente no es una única persona la que monta todo esta infraestructura maliciosa. Hay cuatro actores principales que interactúan en este modelo de negocio. Por una parte la víctima que casi siempre desconoce que esta siendo utilizada. Puede no perder (ni ganar) un céntimo en todo este negocio pero notará que el ordenador va lento, hace cosas raras y recibe correos extraños. El segundo actor es el proveedor de servicios PPI (Pay-per-install). Su tarea es el desarrollo de un programa (exploit kit) que se aprovecha de una serie de vulnerabilidades para poder tomar el control remoto de un ordenador. También son los encargados de proveer de una infraestructura de tráfico y de servidores de explotación. Persona o grupo de personas con conocimientos técnicos muy profundos que, no son delincuentes en sí, pero digamos que son "relajados" desde un punto de vista ético, ya que saben para qué serán utilizados sus programas y servicios.

El tercer actor es el cliente de servicios PPI. Esta persona u organización contrata los servicios (servidor de explotación) y programas (exploit kits) a los proveedores de servicio, infecta a las victimas finales y obtiene beneficios por métodos que luego mencionaremos. Y por ultimo estan los "afiliados", contratados por los proveedores de servicios para tareas concretas (empaquetado, cifrado, distribución de malware, por ejemplo)⁴.

Como decimos, todo este mundo es un gran mercado. No es dificil encontrar sitios (Sellmeyourtraffic, trafficadventure...) donde se compran/venden visitas a sitios maliciosos por precios tan ridiculos como 1 dolar por 1000 visitas. Posteriormente, una vez que los ciberdelincuentes han conseguido infectar una maquina tienen muchas maneras de sacarle partido a esa infección (por la que han pagado su dinero), Spamming, Robo de información, suplantación de personalidad, Clickfraud, reconversión del equipo en un proxy remoto y malware como falsos antivirus, etc.

En resumen y como lecciones aprendidas podemos decir:

• NO estamos seguros navegando por Internet. En cualquier momento una web conocida puede resultar comprometida, dar la casualidad de que pasemos por ahí en ese mismo instante y quedar nosotros infectados sin saber cómo ni por qué.
• La mejor manera de evitar ser infectados es mantener nuestro equipo actualizado. Los exploit kits se aprovechan de todas las vulnerabilidades conocidas que son publicadas. Los fabricantes actualizan constantemente su software para solucionar esas vulnerabilidades. Si tenemos nuestro software actualizado, aunque caigamos en una web comprometida, el exploit kit no podra encontrar ningún agujero en nuestro navegador y nunca resultaremos infectados.
• El mundo del fraude underground es todo un negocio. Mueve mas de 400 millones de euros anuales y es un negocio al alza.

---

Para saber mas:

¹ "Measuring Pay-per-Install: The Commoditization of Malware Distribution". Juan Caballero, Chris Grier, Christian Kreibich, Vern Paxson . USENIX Security Symposium, 2011

² "Manufacturing Compromise: The Emergence of Exploit-as-a-Service". Chris Grier, Lucas Ballard, Juan Caballero, Neha Chachra, Christian J. Dietrich, Kirill Levchenko, Panayiotis Mavrommatis, Damon McCoy, Antonio Nappa, Andreas Pitsillidis, Niels Provos, M. Zubair Rafique, Moheeb Abu Rajab, Christian Rossow, Kurt Thomas, Vern Paxson, Stefan Savage, Geoffrey M. Voelke. ACM CCS, 2012

³ "Markets for Cybercrime Tools and Stolen Data", Hackers' Bazaar, Lilian Ablon, Martin C. Libicki, Andrea Golay, RAND 2014

⁴ "Measuring Pay-per-Install: The commoditization of malware Distribution". Juan Caballero, Chris Grier, Christian Kreibich, Vern Paxson. 2011

⁵ "Russian Underground revisited". Max Goncharov. Trendmicro

⁶ http://www.v3.co.uk/v3-uk/news/2112292/mysql-site-hit-drive-attack

Challenge from Coursera's Malicious Software course

En el curso de Coursera de Malicious Software and its Underground Economy (https://class.coursera.org/malsoftware-002) que estoy siguiendo estos días nos pusieron un reto de un "crackme" donde había que ejecutar un programa e intentar introducir la palabra clave secreta correcta por teclado.

El ejecutable se puede encontrar aqui.

La pregunta era simple, e incluso traía pista, cosa que a mi al final me dio mas problemas que ayudas, ya que como veremos la pregunta no esta muy bien hecha (Hacer click para aumentar las imágenes):

Lo primero, pues era probar el ejecutable, que resultó ser un ejecutable ELF de Linux:

Como vemos a veces devolvía "Maybe" y a veces se quedaba bloqueado. Un "strings" también daba información interesante.

Así que el siguiente paso fue abrirlo en el IDA Pro, que nos descubrió un total de 5 funciones interesantes. Todas ellas sin nombres reales, solo mis amigas Sub_80489E3, Sub_8048776... vamos, muy agradable todo. No tardamos en encontrar una subrutina que tenia todo el aspecto de ser un main, el sub_8048A24 y que además contenía la parte donde se nos pide la cadena de texto:

...donde a grandes rasgos, se llamaba a una funciona anti-debugging, nos mostraba un texto, nos pedía el código y comprobaba si el primer carácter eran una C, una A o una N y en función de la letra que fuera, llamaba a una subrutina diferente.

La subrutina de anti-debug (la sub_80489E3) es bastante simple:

...y la sorteé modificando el ejecutable y sustituyendo el JNZ loc_8048A21 por un JMP 0x8048A21.

La subrutina de la "C", como yo la llamé, es decir la que se ejecuta cuando el texto introducido comienza por "C", básicamente no hacía nada. Creaba un fichero temporal en el que escribía "Woot!":

La subrutina de la "A" era más compleja, pero después de un rato me di cuenta que lo unico que hacia era conectarse con una IP y un puerto y hacer un netcat al mismo. Luego veremos por qué. Esta subrutina no tocaba para nada la cadena introducida por teclado.

Así que el meollo tenía que estar en la rutina "N", como yo la llamé o sub_8048743 como lo hizo mi amigo IDA. Sin embargo esta rutina es muy simple. Liosa, pero simple:

No tenía mucho sentido... hasta que me fijé en la linea roja del final de la función. Resulta que cuando IDA Pro detecta algún tipo de error en la instrucción RET, la pone en rojo. ¿A ver si es que no la va a ejecutar... y no vuelve a la funcion main?. ¿Y que hay despues de la funcion "N"?. Pues esto:

Al instante me llamó la atención la cadena "@EHJ@DZEL" de la ultima línea. Tras un rato de desensamblaje y con la ayuda del GDB (ya que parece que IDA no deja debuggear ejecutables en ELF, o al menos yo no se) descubre que ese trozo de código del centro lo que hace es sumar uno a cada caracter introducido y hacerle un XOR con 02Ah. Y claro, luego se compara con ese "@EHJ@DZEL" para sacar un texto u otro. Dos minutos más y sacamos el codigo descifrado: "ina_Simone". Siempre con la "N" delante, claro. Lo probamos en nuestro Linux y Eureka:

De ahi lo de hacer el netcat a esa IP y puerto.

Ahora ya sólo tenemos que escribir la respuesta (ina_Simone) en el "examen". Pues no, resulto que lo de "it's part of the input you provide and it is not the output the program produces" no era exactamente así. La respuesta correcta es "NiXx_SimXxe" (Lo haré publico cuando termine el periodo de evaluación) que es la entrada completa (no parte de ella) y la salida del programa también. En fin, a veces dar pistas lleva a mas confusión que ayuda.

Y esto es to, y esto es to, y esto es todo amigos!!

Presentación para convencer al Consejo de Administración de la necesidad de un plan de seguridad

Como comentaba en el anterior post, estoy asistiendo a un curso de Ciberseguridad industrial con Samuel Linares y Nacho Paredes, del CCI. Por cierto que el curso merece la pena. El pasado Sábado se nos pidió defender ante un consejo de Administración la necesidad de implantar un plan de seguridad integral en la industria. Una práctica muy útil que puede ocurrirnos alguna vez a lo largo de nuestra carrera.

La presentación que tenía yo preparada no fue escogida por mi equipo como la final, básicamente por no ser una industria, la eléctrica que conociéramos, cosa que es verdad. Pero como ya la tengo hecha, pues al menos la voy a colgar del blog, que igual a alguien le interesa o parece interesante.

La idea de la presentación es que somos una industria electrica, ElectroACME Corp., empresa de 5000 trabajadores que ha sido declarada recientemente una infraestructura crítica por el gobierno español. A partir de ahí, nos presentaríamos ante el consejo de administración y tendríamos siete minutos para defender la necesidad de un plan de seguridad para la industria.

Mi Powerpoint hubiera sido este.

Cabe mencionar que este powerpoint era una idea inicial que hubiera sido necesario mejorar a lo largo de los 30 minutos que se nos dejó para ello. En todo caso, la idea era dar un mensaje rápido, llamativo y convincente que concienciara al consejo de administración del problema al que se enfrenta su empresa. Por otra parte, debo decir que me alegro de no haber salido yo a defenderlo... ¡¡porque allí volaban los cuchillos!!.

Ciberseguridad industrial desde el punto de vista del acceso fisico a las instalaciones

Ahora que estoy asistiendo a un curso de Ciberseguridad industrial con Samuel Linares y Nacho Paredes, del CCI, me doy cuenta de la problemática existente de seguridad en el ámbito industrial, no solo en España sino en todo el mundo.

También he descubierto que el problema en la industria no son solo los SCADAs, idea que flotaba en el ambiente desde el archiconocido caso de Stuxnet. La seguridad es un problema que afecta a todos los ámbitos, desde el físico, el tecnológico, el personal y hasta a la dirección.

Escribo esta entrada un poco para aclarar ideas tras haber leido algunos documentos. No pretendo presentar nada novedoso.

INTECO realizó en 2013 una guía de seguridad del puesto de operador de un SCADA, que no deja de ser un resumen de buenas prácticas que también podrían aplicarse a cualquier puesto de trabajo de oficina. De la concienciación de los trabajadores mucho se ha hablado, pero hay un entorno que es igual de importante y que es el gran olvidado a la hora de hablar de sus riesgos y de su seguridad. Se trata del entorno de las infraestructuras físicas de las industrias.

Por supuesto que la industria se toma muy en serio su seguridad física y en la práctica totalidad de recintos existen guardias de seguridad que velan por la integridad física de los recintos. ¿Pero es suficiente?. Estos recintos suelen ser vastas extensiones sólo separadas del exterior por una simple valla y en la inmensa mayoría de los casos el contingente de control se reduce a uno o dos guardas de seguridad.

Cada día se producen a nivel nacional varias intrusiones físicas en infraestructuras críticas, algunas nunca son descubiertas y otras son consideradas vulgares accesos en busca de herramientas, cobre... pero estos accesos, ¿podrían ser ciberataques?. La respuesta es que sí. Muy pocos accesos físicos a infraestructuras críticas y plantas industriales son tratados como ciberataques.

Sin embargo, muchos componentes de sistemas de control industriales (ICS) pueden ser encontrados "en el campo" o "en planta". Y cuando digo "en el campo" me refiero a que muchas estaciones se encuentran en lugares remotos a muchos kilometros de cualquier pueblo cercano.

Estación extractora de gas natural

El acceso no autorizado a casetas de control es frecuente, pero este tipo de accesos han sido siempre considerados como crímenes contra la propiedad únicamente. En el mundo actual, cada vez mas interconectado, este tipo de accesos podrían adquirir otra dimensión.

Hay que darse cuenta que para facilitar su interconexión y el trabajo de los operadores, los ICS ya no disponen de sistemas operativos propietarios, sino que muchas veces utilizan sistemas operativos como Microsoft Windows o distribuciones Linux que no se actualizan tan a menudo como debieran.

ICS de una caldera de vapor

El acceso físico a estos sistemas de control industrial podría implicar acciones tales como cambios en ficheros de configuración, la instalación de hardware no autorizado, realizar reconocimientos (esnifado) de red o simplemente el robo de información (de criticidad variable).

Por poner un ejemplo, la instalación en los sistemas de control de campo, de dispositivos USB que permitieran un acceso remoto a dichos dispositivos mediante un enlace wireless. Esto proporcionaría una ruta para futuros ataques y un control remoto de una parte de la estación. Además, Una vez instalados estos dispositivos son dificilmente detectables. Por ultimo si se conectan a dispositivos que estén conectados a internet, desde estos dispositivos se podría llegar a conseguir acceso a otros sistemas dentro de la compañía.

Keylogger con capacidad de conexión a redes inalámbricas

Esto era solo un ejemplo, también se podría realizar acciones tales como:

• La instalación de troyanos.
• La instalación de aparatos o software de espionaje de red.
• La instalación de Keyloggers, videologgers, etc.
• La instalación de PLCs o cualquier otro tipo de dispositivo.

Como posibles vías de ataque, no estamos hablando solo de cortar un trozo de alambrada y meternos dentro del recinto, también podríamos hablar de:

• Ataques a través de Redes Wifi
• Conexiones a internet
• Personal poco concienciado (El típico ataque del USB)
• Dispositivos móviles conectados a la red
• Dispositivos de calibración comprometidos

Recientemente se ha hablado mucho de PLCPwn, un PLC usado para realizar ataques de cualquier tipo en la infraestructura de red. Este PLC podría ser implantado con cierta facilidad durante un acceso físico no autorizado a una planta industrial. Incluye un modulo GSM que le permitiría recibir instrucciones en remoto y un interfaz wireless para crear y conectarse con un red inalámbrica que pueda ser utilizada para ataques remotos.

PLCPwn oculto entre otros PLCs legítimos

El responsable de seguridad del centro nos dirá que este escenario que planteamos aquí es muy improbable ya que existe un equipo de personas encargado de velar por la seguridad de la planta y que existen cámaras de seguridad. Sin embargo ya se ha demostrado que un equipo de guardias de seguridad no siempre es suficiente para mantener la seguridad física y lógica del recinto.

Cuando quien está detrás de estos accesos son terroristas o industrias rivales, es muy posible que un equipo de seguridad de una o dos personas no sea suficiente.

Además estos grupos profesionales habrán hecho su trabajo y encontrado posibles puntos débiles estudiando:

• las rutinas diarias.
• las acciones de respuesta ante anteriores intrusiones.
• la complacencia de los trabajadores.
• fallos en la comunicación entre los diferentes grupos.

Los encargados de seguridad de una planta buscaran las típicas pistas que puedan indicar que se haya producido una intrusión:

• Puertas abiertas.
• Alarmas desconectadas.
• Personal no autorizado a través de videocámaras.
• Candados que ya no abren.
• Daños o señales de forzado de puertas o vallas.

...pero si quien accede son profesionales, ¿dejarían estas pistas?. Y si se detectan estos accesos, ¿como podemos saber que no ha habido un acceso a la infraestructura de red o no se ha instalado algún dispositivo para un futuro acceso remoto?

Aparte de las anteriores indicaciones, es necesario mantener un equipo que vele por la ciberseguridad del recinto y detecte cosas como:

• Pérdidas de conectividad o un comportamiento extraño en la red.
• Conexiones sin explicación aparente entre componente de campo.
• Un comportamiento inexplicable de sistemas de control.
• Elementos que falten o que hayan aparecido inexplicablemente y no estuvieran en el inventario.
• Un aumento de facturas de tarificación de datos en las comunicaciones de la estación.
• Nuevas redes Wifi o de radiofrecuencia.

Para evitar que estas intrusiones no se conviertan en ciberataques, la solución no es (solo) aumentar el contingente de seguridad. De hecho, muchas veces el mayor atacante lo tenemos dentro: nuestros propios trabajadores.

Hay que realizar una serie de acciones tales como:

• Tareas de concienciación de los trabajadores.
• Preparar un plan de seguridad integral de las instalaciones que englobe los aspectos físicos y lógicos.
• Realizar simulaciones de ataques físicos.
• Realizar un inventario de los equipos y su infraestructura, manteniendo en el mismo un soporte gráfico del estado en que se encuentran.

Durante la revisión ocular del recinto es necesario preguntarse cosas como ¿adonde podría yo acceder una vez que haya ganado acceso físico al recinto?. ¿Se puede acceder a la red de control o de dirección desde allí?. Si es así, un atacante también podría. Si manipulo alguno de estos componentes, ¿puede este cambio impactar en el rendimiento de la infraestructura?

Si la respuesta a alguna de estas preguntas es que sí, debemos escalarlo al responsable porque se hace necesario una revisión del recinto y de su seguridad y preparar un plan para minimizar el impacto ante este tipo de intrusiones.

La revisión del recinto deberá realizarse con el encargado de seguridad

Durante la revisión del recinto será necesario conectarse a cada dispositivo y comprobar (en base a un inventario previamente realizado):

• los logs
• el "uptime", es decir el tiempo que lleva funcionando, cada dispositivo. Un reinicio de varios dispositivos simultaneamente podría indicar un acceso no autorizado
• nuevas cuentas de usuario o cambios en el sistema
• nuevos dispositivos removibles conectados (USBs, etc)
• la configuración del dispositivos
• comprobar las fechas de modificación de los ficheros de configuración
• comprobar la versión del firmware del dispositivo
• realizar un escaneo de malware en el dispositivo
• en caso de que todo este aparentemente bien, actualizar el inventario.

Y por supuesto, si encontramos algo raro. Informar al encargado.

Revisiting Winrar "0-day"

Tras leer este blog, me decidi a probar esta "vulnerabilidad" en el winrar que tenía en casa (que resultó ser la v5.01 y que es la descarga recomendada a día de hoy).

Lo primero que comprobé es que es cierto que aparecen dos veces los nombres de los ficheros, uno de ellos (el "primer nombre") al principio del fichero y otro (el "segundo nombre") justo al final. Sin embargo en la versión 5.01 el comportamiento es diferente al explicado en el blog antes mencionado.

En el caso de la version 5.01 de Winrar el "primer nombre" del que se habla en an7isec no se utiliza para nada, hasta el punto de que si se borra por completo, el fichero ZIP sigue siendo perfectamente válido.

Esto quiere decir que tanto para la previsualización como para la extracción final del fichero se utiliza el "segundo nombre".

Se puede modificar este segundo nombre, por supuesto, pero si por ejemplo a un ejecutable le ponemos una extensión PNG, el sistema operativo intentará abrir el ejecutable con el visor de imágenes resultando inútil el cambio realizado. Es igual que si le cambiáramos la extensión o el nombre ANTES de comprimir el fichero.

Y como muestra, un botón:

Como no tenía un malware a mano, hice la prueba con el socorrido putty.exe. Tras crear un fichero ZIP con Winrar de dicho ejecutable, al abrirlo con un editor hexadecimal vemos que, ciertamente tiene un primer nombre:

...y un segundo nombre:

Comprobamos que, si eliminamos por completo el primer nombre:

...no pasa nada:

...y si le cambiamos la extensión al ejecutable "malicioso":

...nos lo intentará abrir con el visualizador por defecto para esa extensión:

Con lo cual podemos sugerir que con las versiones actuales de Winrar podemos estar tranquilos.

Vulnerabilidad 0-day en Microsoft Word

Microsoft publicó hoy un comunicado avisando de una vulnerabilidad 0-day que afecta a Microsoft Word. El problema podría comprometer a todas las versiones de Microsoft Word 2003 a Microsoft Word 2010. La vulnerabilidad parece no existir en Microsoft Word 2013 debido a que en esta versión se fuerza el uso de ASLR.

La vulnerabilidad se puede propagar (y de hecho ya se esta aprovechando) mediante correo electrónico utilizando un fichero RTF modificado que incluye un payload que descarga un troyano desde un sitio remoto de forma inadvertida para el usuario. No es necesario siquiera abrir dicho documento RTF y bastaría con previsualizarlo con Microsoft Outlook, ya que éste usa Microsoft Word como visor de correo.

Microsoft proporciona un Fix-It para resolver de forma temporal el problema. Este Fix-It se puede instalar desde aquí.

Por otra parte, se ha visto que el tener instalado EMET evita la ejecución del payload del RTF.

Aparentemente la funcionalidad de descarga del troyano dejará de funcionar el 8 de Abril de 2014. El troyano descargado es un fichero llamado svchost.exe que aloja un malware genérico escrito en Visual BASIC que se conecta por https con la IP 185.12.44.51 (alojado en Suiza) para descargarse scripts VBS y ficheros MSI que instalará en el equipo comprometido.

Para mas información se pueden leer estas noticias:

• Segu-Info: Vulnerabilidad 0-day en Microsoft Word permitiría (permite) ejecución de código
• http://blogs.technet.com/b/srd/archive/2014/03/24/security-advisory-2953095-recommendation-to-stay-protected-and-for-detections.aspx
• Microsoft: 0Day Exploit Targeting Word, Outlook

Probando el DVWA (Parte I)

Hoy me decidí a instalar DVWA para hacer pruebas de conocimientos de sql injection y demás. DVWA es la Damn Vulnerable Web Application y su nombre lo dice todo. Básicamente se trata de una XAMPP con PHP y MySQL.

Tras instalarla, el primer problema que encuentro (aparte de un error de MySQL que habia que cambiar la contraseña del usuario root) es que me aparece la página de login y no tengo ni idea de qué usuario y contraseña utilizar:

Por suerte lo tengo instalado en local y puedo ver el fuente de login.php, que tira de la base de datos de MySQL 'dvwa' y dentro, de la tabla 'users'. Dicha tabla es algo asi:

Esas contraseñas parecen un MD5... vamos a intentar descifrarlas. Vamos a alguna de las multiples páginas que hacen resolucion inversa de MD5, por ejemplo gromweb y le damos:

Ok, pues para el usuario admin, la contraseña es password. Vamos a ver el resto.... Para el usuario gordonb es abc123, para el usuario 1337 es charley y para el usuario pablo es letmein.

Una vez dentro me sale esta página principal:

Command Execution

Pruebo a comenzar con la ejecución de comandos. Me sale esta pantalla donde se supone que introduciendo una IP, me hará ping a dicha IP. De hecho funciona. Pero hay algo más, seguro. Tras unas cuantas pruebas:

...me empiezo a escamar y miro el código fuente... hasta que me doy cuenta de que estoy en modo NO-VULNERABLE, opción que se puede modificar en el fichero config.inc.php:

Según la documentación, el modo de seguridad 'high' es seguro contra contra todas las vulnerabilidades y además nos muestra buenas prácticas de programación.

En este modo la herramienta del ping "con vulnerabilidad de ejecución de comandos" esta escrita asi:

Es decir, se "explota" la IP por el simbolo punto y luego se comprueba si cada parte es numerica con la funcion is_numeric de PHP. Tras investigar un poco, no hay forma de saltarse esta comprobación.

Así pues, pasemos al modo 'medium' (Tampoco es plan de ir a lo facil).

Ahora si. Simplemente poniendo un simbolo "pipe" nos permite ejecutar cualquier comando linux:

En este modo, se filtran los codigos '&&' y ';', pero todo lo demás, lo deja ejecutar.

File Upload

Pruebo a continuación la opción de subida de ficheros (Upload). Para ello voy a escribir un script PHP que me haga un simple ls. Algo así:

Al subirlo me da un error muy explicativo:

Your image was not uploaded. O sea que esta esperando una imagen. ¿Y si le ponemos una extension jpg al php?. A ver... ¡¡Vaya, y nos pone la ruta completa!!:

Entiendo que ahora solo hay que ejecutar ese jpg... Vaya... ¡pues no!:

Ah! pero para eso tenemos la ejecución de comandos que probamos antes. Si vamos a Command Execution y le pedimos que nos haga ping a:

8.8.8.8|mv ../../hackable/uploads/prueba.jpg ../../hackable/uploads/prueba.php

...ahora ya podremos ejecutar dicho PHP:

Y hasta aquí por ahora. Esta wapo este DVWA, permite probar conceptos y aprender como se debe programar en PHP de forma segura.

Pasos seguidos para la limpieza de las VMs del curso de INTECO "Ingeniería social y analisis de sospechas"

En el último curso impartido por INTECO desde el pasado Martes hasta hoy hemos hablado de ingeniería y "analisis de sospechas", curioso nombre cuando de lo que se trata es de detección y limpieza de troyanos.

Como parte práctica nos han dado cuatro máquinas virtuales infectadas que había que limpiar "a mano", sin herramientas de limpieza automática (léase cualquier tipo de antimalware). En esta entrada describiré los pasos que seguimos (los de mi grupo) para la limpieza de dichas máquinas virtuales.

Resolución maquina virtual VM02

Se arranca la maquina y se comprueba el problema:

No se encuentra ningún ejecutable en las carpetas de arranque . Tampoco aparece ninguna entrada de registro que indique que se ejecuta algo al arranque.

Se reinicia con una distribución Kali de Linux. Para ello se descarga la ISO de la distribución y se coloca como CD de arranque en VirtualBox.

Se monta el disco duro de la maquina virtual:

mount /dev/sda1 /mnt/HD

cd HD

Se busca el listado de fichero creados los días 20 y 21 de Febrero (Sabemos que es cuando se infectaron las máquinas). No se encuentra ningun exe, ningun lnk ni nada interesante.

Encontramos dos ficheros interesantes:

• Una carpeta setup
• Un fichero llamado At1.job, que es una tarea programada.
• LockScren.AO.lnk

La carpeta setup resulta ser c:\windows\system32\oobe\setup\setup.exe

Al mirar los contenidos del fichero At1.job vemos que se ejecuta el fichero setup.exe de la ruta anterior.

Probamos a mover ese fichero setup.exe a otra ruta. Rearrancamos Windows, y ya no aparece el Ransomware.

Restauramos una versión anterior de Windows.

Buscamos las entradas del registro que llamen a este setup.exe y aparecen las siguientes:

HKCU/Software/Microsoft/Windows/ShellNoRoam/MUICache=”C:\windows\system32\oobe\setup\setup.exe”

HKU/1-5-21..../Software/Microsoft/Windows NT/CurrentVersion/Winlogon/Shell=”C:\windows\system32\oobe\setup\setup.exe”

Las borramos. También borramos el fichero setup.exe.

El fichero lnk es un enlace al ejecutable que infectó la máquina, por lo que sabemos de que virus se trata (con enviar el fichero setup.exe también nos habria valido).

Buscamos por internet LockScren.AO y encontramos esta página:

http://www.microsoft.com/security/portal/threat/encyclopedia/entry.aspx?Name=Trojan:Win32/LockScreen.AO#tab=2

Resolucion VM03

Al arrancar la máquina, aparece este error de la ejecución de “other.res”:

Se busca ese fichero y aparece en

c:\Documents and Settings/aula2/Application Data/other.res

La pantalla de error tiene un icono muy pixelado que claramente pretende engañar.

El other.res también aparece en el administrador de tareas.

Se arranca la maquina y se comprueba el problema. No se encuentra ningún ejecutable en las carpetas de arranque . Tampoco aparece ninguna entrada de registro que indique que se ejecuta algo al arranque.

Se reinicia con una distribución Kali de Linux. Para ello se descarga la ISO de la distribución y se coloca como CD de arranque en VirtualBox.

Se monta el disco duro de la maquina virtual:

mount /dev/sda1 /mnt/HD
cd HD

Se busca el listado de fichero creados los días 21 de Febrero (sabemos que las maquinas fueron infectadas en esa fecha).

Se encuentra un fichero Flash7.ocx.exe que suena raro:

En los momentos después de la ejecución del troyano se ven ficheros temporales de internet y la instalacion de Flash.

Volvemos a Windows.

Vemos que el Flash7.ocx (realmente Flash7.ocx.exe) tiene exactamente el mismo icono que el error. Lo mandamos a Virustotal.

Virustotal nos dice que es un virus y lo detectan 38 de 47 antivirus y que se llama urausy.

Mientras tanto se busca other.res en el registro de Windows:

Tambien se encuentra esta entrada:

HKCU\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\Shell=explorer.exe, C:\Documents and Settings\aula2\Application Data\Other.res

Lo borramos y matamos el proceso. Tambien borramos el fichero.

Buscamos Flash7.ocx.exe en el registro. Aparece la siguiente entrada:

La ruta es HKCU/Software/Microsoft/Windows/ShellNoRoam/MUICache/

La borramos.

Borramos la carpeta completa Flash. No deja borrarla. Rearrancamos Windows en modo a prueba de fallos, tampoco la conseguimos borrar, por lo que entramos desde Linux y nos la cargamos.

Se borra tambien BRNDLOG.BAK en %UserProfile%/aula2/AppData/Microsoft/Iexplorer

Resolución maquina virtual VM04

Se arranca la maquina y se comprueba el problema.

No se encuentra ningún ejecutable en las carpetas de arranque . Tampoco aparece ninguna entrada de registro que indique que se ejecuta algo al arranque.

Se reinicia con una distribución Kali de Linux. Para ello se descarga la ISO de la distribución y se coloca como CD de arranque en VirtualBox.

Se monta el disco duro de la maquina virtual:

mount /dev/sda1 /mnt/HD
cd HD

Se busca el listado de fichero creados el día 21 de Febrero (Sabemos que el bicho se instaló ese día en la máquina). No se encuentra ningun exe, ningun lnk ni nada interesante.

Buscamos por internet y encontramos un virus parecido llamado gpcode.ak, y una entrada de un blog( http://www.securelist.com/en/weblog?weblogid=208187531) donde indica que la única solucion es recuperar los ficheros usando photorec, ya que despues de encriptarlos, el virus los borra y los ficheros borrados, si no se a tocado demasiado el sistema, se pueden recuperar.

Nos ponemos a ello y recuperamos un montón de ficheros:

Eliminamos el fichero Bliss.bmp, que es el fondo de pantalla con la calavera.

Este es el resultado:

Resolución VM05

Se arranca la máquina y se comprueba el problema. No se encuentra ningún ejecutable en las carpetas de arranque. Tampoco aparece ninguna entrada de registro que indique que se ejecuta algo al arranque.

Se reincia con una distribución Kali de Linux. Para ello se descarga la ISO de la distribución y se coloca como CD de arranque en VirtualBox.

Se monta el disco duro de la maquina virtual:

mount /dev/sda1 /mnt/HD
cd HD

Se busca el listado de fichero creados el día 21 de Febrero (Fecha de instalación del troyano). Encontramos tres ficheros interesantes:

• Un fichero setup.exe
• Un fichero sdrive64.exe
• Un fichero Skomaz.lnk

Buscamos dicho Skomaz en internet y encontramos esta páginas http://www.spywarelib.com/remove--Trojan-spy-skomaz.html.

...donde habla del fichero sdrive64.exe. Y esta:

https://www.virustotal.com/es/file/e7fa7e304b3ab56c695a51d8caf832b79563969465b388420381ac13ac8b550b/analysis/

Donde habla de que el virus tiene 1165824 bytes.

Buscamos ficheros de ese tamaño y casualmente encontramos que hay uno llamado setup.exe (el de antes).

Los borramos y arrancamos. Ya no aparece la pantalla de rescate pero Windows no funciona.

Es porque en vez de lanzar explorer.exe en alguna entrada del registro esta lanzando sdrive64.exe

Lo encontramos en HKCU/Microsoft/Windows NT/Winlogon/Shell=C:\Documents and settings\aula2\Local Settings\Temp\sdrive64.exe

Voila!