31 octubre 2014

VUESTROS "ETHERNET EXPOSED" - XXVI

Seguimos recibiendo más y más fotos con vuestros ETHERNET EXPOSED, imágenes que realizáis a tomas ethernet que se encuentren expuestas en lugares curiosos, transitados, accesibles... y que posteriormente nos enviáis a nuestra dirección de contacto.

En la edición de hoy contamos con las contribuciones de Marc, David y un anónimo.

En primer lugar, esto es lo que nos envió Marc a nuestro correo de contacto. Una ubicación que es ya todo un clásico en nuestra sección:

Estas las hice en la oficina de expedición del DNIe de Girona cuando fui a renovar los certificados. No pude tirar mejores fotos por miedo a que me echaran ;)



No es un lugar muy apropiado ni cómodo para obviamente ponerse a jugar con las tomas de red de este tipo de lugares, pero aún así sería recomendable dejarlo menos accesible o no tan a la vista.

En segundo lugar, tenemos la contribución de David de Román, de Vigo, que se encontró lo siguiente en la tienda Kiwoko de su ciudad:


Seguramente esta ubicación estará preparada (o estuvo) para que fuese conectado un puesto de consulta, kiosco, etc. ¿Seguirá funcionando?

Y ya por último, un contribuidor que prefiere mantenerse anónimo nos envía lo siguiente traído recientemente desde la octava edición del ENISE (León). Una "infraestructura" de red inalámbrica que nos permite ver más allá del primer nivel (es decir, más allá del punto de acceso...)



Esto bien podría valer como 2x1, tenemos tanto los puntos dentro del router wifi como los del que parece ser un switch muy concurrido..

Como siempre os decimos, nuestra dirección de correo sigue abierta a todas aquellas contribuciones de ETHERNET EXPOSED que os encontréis, ¡muchas gracias a todos y hasta la próxima!

---------------



Leer más...

28 octubre 2014

6 herramientas para la identificación de redes wireless en OSX

Seguro que más de uno ya me lo ha oído decir antes: ¡¡¡no hagáis auditorías wireless sin estar seguros que el punto de acceso que vais a romper es propiedad del que os paga el proyecto!!!

No sería la primera vez que en unos resultados, ante la mirada atenta del cliente y todo su séquito, se muestran las claves de un AP que nada tiene que ver con el análisis. ¡¡Horror!!

En esa primera fase de análisis y obtención de activos siempre se usan herramientas que permitan poner nombre y apellidos a cada uno de ellos: conocer que cobertura tienen,  donde quedan físicamente, cifrados, canales y todos los datos adicionales que se puedan sacar y alguien pueda validar. Esto lo haría cualquier humano con Windows y una licencia de Acrylic, aunque en esta ocasión, las propuestas que cuento son para OSX.

Al tajo.

Wireless Diagnostics: la opción más rápida para buscar redes es usar el propio sistema operativo, para ello si se mantiene pulsado el botón ⌥ y se hace click sobre el icono de wireless del menú superior se obtendrá información de la red actual y una nueva opción "Open Wireless diagnostics", una vez se abre ese asistente (que también está disponible en la ruta /System/Library/CoreServices/Applications) permite hacer un análisis pulsando en el menú Window->Scan o las teclas ⌘+4

Menú wireless si se abre mientras se pulsa la tecla ⌥

Análisis de redes de Wireless Diagnostics (⌘+4)

aircrack-ng: otra opción sencilla y útil en nuestro mundo es instalar el imprescindible paquete MacPorts o brew para tener herramientas como la suite aircrack-ng, una vez instalado el pkg correspondiente y hecho el "sudo port install aircrack-ng", se puede invocar el conocido clon de airodump llamado airport. 

Herramienta airport de aircrack-ng

KisMac2: sin engañarnos más,  KisMac2 es la  segunda versión y continuación del abandonado (por problemas legales) KisMac y posiblemente el mejor clon de kismet, permite guardar tráfico, otros adaptadores de red wireless, GPS, inyectar tráfico (con tarjeta que lo soporte), mandar paquetes de deautenticación, gráficos y muchas otras opciones interesantes.

Ventana principal de KisMac2

NetSpot: la aplicación de descubrimiento wireless con propósito profesional.  Dispone de versión gratuita y limitada y versión pro (149$) y enterprise (499$). Su interfaz es cómodo y la versión free dispone de las suficientes características como para que sea interesante. Si pintáis mapas de cobertura, desde luego necesitareis licencia.

Gráfica y Discovery de NetSpot

iStumbler: esta utilidad es comercial de bajo coste (20$) aunque dispone de versión demo. Su principal ventaja es que también monitoriza bluetooth y Bonjour. Por lo demás, no sobresale en nada.

iStumbler

Wifi Explorer: por último, esta aplicación con un aspecto que me recuerda a la utilidad inssider, se puede comprar desde la App Store por tan solo 3.99$. No he podido descargar una demostración pero por sus características y pantallazos, parece una utilidad simple.

Wifi Explorer


Leer más...

27 octubre 2014

FrootVPN, VPN GRATIS para navegar de forma anónima y en todos los SO

Aparece un nuevo servicio de VPN a la palestra, de entre los muchísimos que hay, y que podréis consultar en este post de Yago en el que realiza una excelente recopilación de servicios VPN que se toman en serio la privacidad.

FrootVPN da un puñetazo en la mesa, y ofrece lo siguiente:

- Acceso por VPN mediante PPTP, L2TP y OpenVPN.
- Compatible con todos: Windows, Mac, Linux, iOS y Android
- Conexión desde varias ubicaciones, ideal para desbloqueo de contenido limitado por procedencia, como es el caso de Netflix, Skype, Youtube, Facebook, Spotify, Pandora y muchos más
- Anonimato y protección de identidad
- Sin límite de velocidad o uso, soporte 24x7, rapidez
- Completamente GRATIS

Tenéis toda la documentación disponible en el apartado de guías (Guides) dentro de su web, así como un Preguntas Frecuentes (FAQ) sobre el servicio y posibles problemáticas.

Por el momento no se sabe ningún desventaja, todo son buenas palabras y ha sido recomendado directamente desde el portal de ThePirateBay, el cual desde que apareció el anuncio, ha hecho que reciban más de 100.000 registros. 

Página principal de ThePirateBay en la que se promociona FrootVPN
¿Tendrá trampa? Esperemos que no...

Puedes registrarte a través del formulario que encontraréis nada más acceder a la web:

Formulario de registro al servicio FrootVPN


Disponen de twitter, facebook, y tenéis toda la información necesaria sobre este servicio en su página principal.
Leer más...

26 octubre 2014

Enlaces de la SECmana - 247

Leer más...

23 octubre 2014

Controla las conexiones de tu Mac con Little Snitch.


Little Snitch es una herramienta que permite controlar las conexiones que realiza tu Mac con otras redes. Esta aplicación, desarrollada por la compañía Objective Development, es un corta fuegos tradicional que crea sus reglas basadas en acciones que solicita al usuario cada vez que detecta un intento de acceso nuevo o no configurado. De esta forma, en un par de días tras su instalación, se obtiene una línea base que será afinada según las nuevas necesidades del día a día.

También es un monitor de conexiones que identifica el uso que hace de la red cada una de las aplicaciones, ancho de banda consumido y la velocidad de transferencia.

Monitor de red y conexiones por aplicación.
El monitor de red es histórico y sirve como herramienta para visualizar rápidamente horas con picos de tráfico y anchos de banda consumidos.

De esta herramienta destaca la facilidad de uso para que cualquier persona pueda usarla y aquellos más avanzados obtengan toda la información de conexión, aunque los primeros días puede ser un poco estresante con tanta pregunta.

Detalle del proceso TweetDeck y conexiones establecidas
El panel de preferencias es sencillo y configura opciones genéricas, como propiedades de visualización, arranque,  actualizaciones o la seguridad de acceso a la  propia aplicación.

Preferencias de configuración

El interfaz para editar reglas es muy completo. Demasiado para un usuario no experimentado, pero permite a los más avanzados crear reglas, proteger otras o eliminar aquellas que sean redundantes. Seguro que ideal para cualquier lector de este blog.

Otra opción curiosa, conocida como reglas de login, es la que permite que se acepte determinado tráfico cuando el sistema se enciende y antes de que el usuario se autentique.

Vista general del editor de reglas

A la hora de solicitar la aceptación o denegación de una nueva conexión y por lo tanto, la creación de una regla, nos obliga a que se haga basada en el puerto de destino, el dominio o la combinación de ambos: dominio y puerto, además la duración de esa regla, como por ejemplo "para siempre", "hasta que se cierre", "durante 1 hora", "durante 15 minutos", etc.

En caso de que no sepamos cual es la aplicación que intenta generar la conexión, si se pulsa en la interrogación de la parte inferior, el propio Little Snitch comprueba la firma y origen del binario. Esta característica tiene como propósito identificar procesos sospechosos o malware.

Ventana solicitando acción para Permitir o Denegar una conexión (netcat) y comprobación del binario
Aunque es curioso el ejemplo de la captura anterior, ya que la aplicación iTerm es solo el terminal que invoca el ejecutable "nc" y pese a que en el título de la ventana de dialogo se identifica como "nc" la firma se realiza sobre el propio iTerm.

Dejo para el final una buena sorpresa que me he llevado haciendo uso de ella, con un par de clicks es posible capturar el tráfico generado por una aplicación cualquiera en un fichero PCAP. Personalmente, me ha solventado problemas con otras herramientas rapidísimamente.

Capacidades de registro en fichero PCAP de las conexiones de un proceso.

El único punto negativo de Little Snitch es que es un producto comercial y en su versión para un único usuario tiene un precio de 30€. Para adquirirlo hay que ir a la propia tienda del fabricante. 


Leer más...

22 octubre 2014

VI Jornadas sobre Ciberamenazas y Ciberdefensa


Mañana 23 de octubre se celebra en la Universidad Europea de Madrid las VI Jornadas sobre ciberamenazas y ciberfensa de forma gratuita para todo aquel que quiera asistir.

El programa tiene una estructura similar a la de otros años, en el que después de unas interesantes ponencias de distintos miembros relevantes en la Estrategia Española de Seguridad se hará una demostración práctica de técnicas de ciberamenzas. En este caso, de la mano de Raúl Siles.

Copio el programa que se ha publicado en la página de la UEM.
  

16:00 Apertura y Bienvenida 


Dr. D. Miguel Gómez Navarro, Director de la Escuela Politécnica de la Universidad Europea de Madrid 
Dr. D. Luis de Salvador Carrasco, Director de la Jornada 


16:30 Estrategia Española de Seguridad (EES)


Introducción a la Estrategia Española de Ciberdefensa - D. David Ramírez Morán – Analista del Instituto Español de Estudios Estratégicos


La Guardia Civil Frente a las Ciberamenazas - T.Col. D. Juan Salom Clotet – Responsable de Seguridad de la Información de la Guardia Civil Desarrollo de software para Defensa: un deporte de riesgo - D. Pedro Bernad Silva – Jefe del Centro de Obtención y Mantenimiento de Sistemas de Información (CCOMSI) del Ministerio de Defensa


18:30 Demostraciónes


Demostración de ataques sobre dispositivos móviles mediante redes Wi-Fi empresariales - Raúl Siles - Fundador y analista de seguridad de DinoSec



20:00 Clausura de la jornada 

Dr. Dña. Maite Villalba de Benito, Directora Académica del Master en Seguridad TIC - Universidad Europea de Madrid


Dr. D. Luis de Salvador Carrasco, Director de la Jornada



Lugar de Celebración: Universidad Europea de Madrid, Auditorio. Edificio B. Campus de Villaviciosa de Odón, c/ Tajo, s/n.

Más información: Coordinación Académica (victoria.pascual@uem.es) Esta actividad ha recibido una subvención de la Secretaría General de Política de Defensa del Ministerio de Defensa


Esta actividad ha recibido una subvención de la Secretaría General de Política de Defensa del Ministerio de Defensa
Leer más...

21 octubre 2014

Evadiendo implementaciones de certificate pinning en Android

Pongamos la siguiente situación: estamos realizando el análisis de una aplicación en la que nos interesa ver las comunicaciones HTTP/S que realiza, para ello disponemos de un dispositivo Android rooteado en el que redirigimos el tráfico de estos protocolos a un web proxy del que tenemos instalado su certificado en el dispositivo.

Todo está configurado correctamente pero algo falla, la aplicación nos indica que no puede establecer comunicación con el servidor de destino y confirmamos que sin redirigir al web proxy la aplicación funciona perfectamente. Puede que nos hayamos encontrado con una implementación de certificate pinning, pero esto no nos va a detener.

Llevemos a la práctica un método de evasión sobre un ejemplo real cogido de Google Play.

La aplicación de ejemplo, eTools


Figura 1

eTools se presenta como una herramienta orientada a realizar búsquedas en la web utilizando los motores más conocidos de manera segura y totalmente privada, implementando entre otros mecanismos de seguridad un certificate pinning.

Preparamos el escenario que hemos descrito anteriormente (dispositivo rooteado + Proxydroid +  Burp + certificado Burp instalado en dispositivo), probamos a realizar una búsqueda utilizando la aplicación y confirmamos como el certificate pinning entra en juego y no nos permite realizar la búsqueda bajo estas condiciones:

Figura 2

Evasión por parcheo de código

Para saltarnos esta restricción el proceso que vamos a seguir se resume en descargar el APK y analizar su código, anular las llamadas que comprobarán el certificate pinning, re-empaquetar la aplicación y reinstalar.

Vamos con ello:

1. Descargamos el APK del dispositivo

Figura 3

2. Buscamos cadenas que apunten al uso de la clase TrustManager

Utilizando dex2jar podemos extraer el JAR del APK y utilizando JD-GUI podremos ver el código Java. Ya desde JD-GUI podemos comenzar nuestras búsqueda por el código:

Figura 4

Como vamos viendo, el código se encuentra ofuscado y puede llegar a complicarnos el análisis, aunque veremos que en este caso tenemos suerte ya que si abrimos la clase "a" encontraremos claramente que es la implementación de la interfaz X509TrustManager:

Figura 5

El código anterior nos deja ver la clave pública contra la que se validará cuando se realice la petición HTTPS. Tenéis información más detallada sobre esta implementación en la web de OWASP.

Por otro lado si miramos el otro resultado de la búsqueda en JD-GUI, la clase "c", encontraremos en ella el método que se encarga de realizar la petición por HTTPS:

Figura 6
He remarcado las partes más relevantes:
  • El primer bloque declara y asigna un array compuesto por la implementación de X509TrustManager. Este array se pasa como parámetro al objeto SSLContext que se utilizará para crear la conexión HTTPS.
  • En el segundo bloque se define que se utilizará la implementación X509TrustManager para la verificación.

En este punto la situación es clara, hay que anular en el método de la Figura 6 todo rastro de uso de la clase "a" si queremos evadir el certificate pinning implementado.

3. Modificamos el código

Tendremos que desensamblar el código Jasmin del APK para modificarlo, así que podéis seguir el paso a paso desde la documentación de dex2jar ModifyApkWithDexTool o utilizar el script modify.py que os comentaba en el artículo sobre inyección de Meterpreter en aplicaciones.

Si optáis por el script, saltaremos el primer paso ya que no necesitamos tocar nada en el AndroidManifest.xml y nos pararemos a modificar el código en el segundo paso:

Figura 7

Respecto a la modificación de código vamos atacar al punto más débil, la clase "c" en su método "a" encargado de gestionar la conexión por HTTPS.

Figura 8


Si recordamos la figura 6, en la línea de código "localSSLContext.init(...)" se pasaban dos valores nulos y el array de TrustManager. En nuestro caso para anularlo vamos a pasar en lugar del array otro valor null, de modo que sustituiremos el valor de la línea 469 por aconst_null .

También en la figura 6 veíamos como se definía el uso de la clase "a" para verificar el hostname, en este caso lo que haremos será eliminar las líneas 484, 485 y 486 para anular esa parte del código.

Finalmente nos debería quedar algo así:

Figura 9

Ya tenemos preparado el código modificado, sólo queda re-empaquetar y firmar el APK. Si estabais usando el script modify.py sólo tendréis que guardar el código modificar y dar a enter.

4. Probamos nuestra obra

Reinstalamos la aplicación:

Figura 10
Activamos Proxydroid, abrimos la aplicación y realizamos una búsqueda:

Figura 11

Perfecto, ya estamos capturando las comunicaciones:

Figura 12


Conclusiones

Realizar certificate pinning en nuestras aplicaciones puede aportarnos una capa más de seguridad, pero debemos entenderlo como una capa más y no delegar en esta técnica la seguridad de nuestras comunicaciones ya que como hemos visto no la hace inmune a su análisis.

Desde el punto de vista del ataque realizado, podría haberse complicado el escenario si hubiéramos encontrado una ofuscación más fuerte o si se hubiera incluido algún método de validación de código en tiempo de ejecución que debidamente ofuscado nos llevara a dedicar más tiempo de reversing (aunque incluso ante estas contra-medidas quedaría la posibilidad de aplicar otras técnicas de hooking y debugging).

Artículo cortesía de Miguel Ángel García
Leer más...

20 octubre 2014

Deshabilita el envío de tus búsquedas en Spotlight a Apple

Ya ha llegado Yosemite, el último sistema operativo de Apple que incluye increíbles y asombrosos cambios(tm). Entre ellos, las nuevas funcionalidades de su panel de búsqueda "Spotlight" que también permite lanzar aplicaciones y decenas de cosas más

El problema de esta asombrosa herramienta es que entre sus nuevas "características" han añadido el envío de las búsquedas que se hagan en ella a la compañía de la manzana. Y esto lo hace de forma automática si expresamente no se modifica esta configuración.

En las preferencias de la aplicación, si se pulsa sobre "About Spotlight Suggestions & Privacy", se puede observar el siguiente texto.
Ventana de información de "Privacy" de las preferencias de Spotlight. Fuente: Fix-MacOSX.com

Para deshabilitar el envío de esta información hay que abrir las preferencias de Spotlight y desmarcar los cuadros de selección de "Spotlight suggestions" y "Bing Web Searches".

Preferencias de configuración de Spotlight

Si somos de consola, gracias a la página web Fix-MacOSX.com, es posible hacerlo con un par de comandos dentro de una terminal:

$ curl -O https://fix-macosx.com/fix-macosx.py
$  /usr/bin/python fix-macosx.py

Leer más...

19 octubre 2014

Enlaces de la SECmana - 246

Leer más...

17 octubre 2014

Diversos usos de las cámaras térmicas


Leo en la lista de SecurityByDefault un artículo relativo al uso de las imágenes térmicas en vigilancia digital.

Como introducción decir que Wikipedia define la radiación infrarroja como “un tipo de radiación electromagnética y térmica, de mayor longitud de onda que la luz visible”, lo que significa que no puede ser vista por el ojo humano. Esto puede ser aprovechado, con la debida tecnología, para detectar algo a través de la refracción de ésta sobre los diferentes objetos que nos rodean.

Un ejemplo muy extendido de ésta característica electromagnética es aplicado en seguridad para la detección de personas mediante sensores volumétricos. La variación de temperatura en un punto o zona determinada puede ser interpretada como que una persona está accediendo por un lugar no permitido, activándose la alarma.

Pero el artículo de hoy se refiere al uso de las cámaras térmicas.

Se pueden encontrar diferentes tipos de cámaras:
  1. En función del tipo de detector
    1. Detectores criogenizados: El detector está al vacío y a muy baja temperatura. Más sensible y preciso.
    2. Detectores ambiente: Más barato y menor sensibilidad.
  2. En función del origen de la radiación
    1. Activas: Emiten un haz infrarrojo y analizan su exposición.
    2. Pasivas: Analizan la exposición de la emisión natural del cuerpo en cuestión.
  3. En función de su representación
    1. Monocromáticas: Muestran la diferencia de calor entre un cuerpo y su entorno
    2. Policromáticas: Representa mediante colores escogidos arbitrariamente un rango mayor de diferentes temperaturas.

Siguiendo con sus usos, todos conocéis su utilización en entornos de militares y policiales. Además de proyectar imágenes en entornos poco luminosos pueden ayudar a unidades de emergencia a detectar personas en extensiones amplias, como náufragos en el mar o también se utilizan en la lucha contra la inmigración ilegal o el contrabando.

En entornos industriales pueden detectar piezas deformadas o susceptibles de fallo o rotura, ya que la pieza o parte de ella puede mostrar un contraste de calor (y color) producido, por ejemplo, por un desgaste de la misma. Ayudan a descubrir fuga de gases en gaseoductos, oleoductos, plantas, etc.. También pueden controlar la eficiencia energética de un edificio, descubriendo zonas de escape de calor.

En medicina pueden detectar patologías, disfunciones o trastornos, cánceres, etc. Sin entrar en detalle, algunos cánceres manifiestan una zona de mayor calor por diversas razones. Ahora que está muy en boga, sirven para comprobar la temperatura de personas en aduanas y fronteras y así detectar posibles casos de enfermedades contagiosas, como en el caso de Ébola (eso sí una vez manifestadas la enfermedad, gracias al mecanismo de la fiebre).

Son muchos usos los que se les puede dar a este tipo de herramientas.

El artículo, base de este otro, para quienes no lo hayan leído es muy sencillo muestra imágenes de objetos inanimados cuyo espectro de calor cambia en función de su uso.

Por ejemplo, gafas con cámara incorporada. La imagen muestra como la temperatura es claramente diferente ahí donde se localiza el dispositivo. Para los grupos mafioso es una buena herramienta. 

Escaneando al poli encubierto, se pueden descubrir micro cámaras y micrófonos escondidos. Adiós a desabrochar camisas en busca de micros… es de muy mal gusto.

Me atrae especialmente cuando muestra el típico teclado de control de acceso, donde se observa el uso de las teclas que han sido recientemente presionadas. No se sabe la combinación pero se acota a un número determinado de dígitos.

Otro ejemplo más ilustrativo son las cámaras de circuito cerrado de televisión (CCTV). El artículo muestra cómo se podría llegar a deducir si están en uso o no mediante la irradiación del calor que desprenden.


Hay muchas cámaras en el mundo, cuyo objetivo es más disuadir que monitorizar. Por ejemplo, metro de Madrid cuenta con 4500 cámaras, se podría deducir que no todas están operativas. Así que si alguien tiene los recursos necesarios (cámaras térmicas, tiempo, ganas, etc.) puede pasearse por sus 292 estaciones haciendo una estadística de cuales están en uso así como el posible algoritmo de utilización }:D.


Para las empresas de seguridad que realizan seguimientos también les resultará útil el artículo. Ya no será necesario posar la mano sobre el capó para saber si el coche ha sido recientemente utilizado. La tecnología les puede echar una "mano" en este caso y hacerlo de forma remota.

Como bien dice el artículo, este tipo de análisis está sujeto a las condiciones climatológicas y no todos los dispositivos disipan el calor del mismo modo. Para evitar esto existen tejidos y materiales que mitigan o no reflejan los infrarrojos con lo que se podría llegar a camuflar (contramedida).

Llegados a este punto el lector puede pensar que todo esto está muy bien pero es difícil hacerse con una… pues no!. Si tienes un iPhone también puedes tener tu cámara térmica de bolsillo ;).

Contribución por Ricardo Ramos
Leer más...

15 octubre 2014

Vulnerabilidad CRÍTICA en SSL (POODLE)

Desde el punto de vista de la seguridad informática, esta semana está siendo muy pero que muy movidita en cuanto a fallos y vulnerabilidades publicadas.

Hoy, desde Google, tres investigadores: Bodo Möller, Thai Duong and Krzysztof Kotowicz han publicado los detalles de un nuevo fallo que, definitivamente, va a llevar a la tumba al protocolo SSL v3 (con 15 años de antigüedad ...) y parece que va a ser el espaldarazo definitivo para que *todo* sea TLS.

Los detalles de la vulnerabilidad se pueden leer en este PDF y que (en una lectura muy preliminar aun) deduzco que combina dos ataques, por un lado llevar al cliente a un 'downgrade', es decir a un terreno menos seguro (SSL 3.0) y una vez ahí, es donde se produce el ataque que permite acceder a datos cifrados bajo una sesión SSL.

Como recomendación obvia para mitigar este ataque se propone deshabilitar SSL v3 y también activar TLS_FALLBACK_SCSV lo que mitigaría la parte del downgrade.

La primera reacción a POODLE llega desde Mozilla que ya anuncia el abandono de SSL v3 en futuras versiones del navegador.

Cabe señalar que esto no supone, per se, que alguien pueda acceder directamente al tráfico SSL de un PC contra una web, es necesario un escenario de tipo MitM para poder acceder a los datos.
Leer más...

13 octubre 2014

El malware que no se podía desinfectar


Imaginad una empresa española, con un edificio central y diferentes plantas de producción de energía nuclear, aisladas del edificio central, situadas incluso en países diferentes. La crisis ha pegado fuerte, por lo que a lo largo de estos últimos años, el nuevo cuerpo de altos directivos de la empresa han tenido que tomar decisiones de alto impacto económico y social. Despidos masivos, recortes en los presupuestos destinados a mantenimiento, beneficios sociales para los empleados, no renovación de licencias antivirus ni de infraestructura de seguridad, etc,...

Desde una de las centrales, comunican al departamento de sistemas que tienen un par de ordenadores portátiles, propiedad de la empresa, infectados con un tipo de malware que ningún antivirus conocido hasta el momento, ha sido capaz de desinfectar. Que otros portátiles que han tenido ese malware (los síntomas eran un sobrecalentamiento de la CPU, fallo de diferentes drivers y elementos críticos del kernel, fallos de hardware, etc,…) han terminado afectando a la BIOS y el firmware de los dispositivos, inutilizando la placa base del ordenador, haciendo imposible instalar otro sistema operativo, teniendo que ser sustituido por otro portátil. Dicho malware se contagia por contacto directo y físico, ya sea mediante comunicaciones de red, como por compartir dispositivos de almacenamiento externo entre ordenadores, etc… Cierto es que hay un 10% de ordenadores en los que, por configuración interna, son capaces de combatir el malware y eliminarlo completamente. 

Los altos directivos de la empresa, se enteran de que esto ocurre, y confiando que las infraestructuras, recursos, profesionales y protocolos serán mil veces mejores en la central española que en las instalaciones de las plantas nucleares, deciden traerse los dos portátiles a la central, tomando (más o menos), buenas medidas de seguridad, para que en el viaje hasta el laboratorio del departamento de sistemas, el malware no se propague.

Varios expertos en malware, seguridad y ayudantes de estos, aislan los portátiles contaminados de la red de producción de la empresa, y se centran en ver si pueden aprender qué hace ese malware, cómo se contagia, y confiar que ejecutando diferentes antimalware de última generación, con capacidades heurísticas y algunos aún en beta, puedan ser efectivos y se salve el hardware, el software y los datos de ambos ordenadores. 

Durante el tiempo que duró el trabajo, todos los intentos fueron inútiles. Diferentes expertos y ayudantes, estuvieron tratando los portátiles. Estaban aislados, por lo que los del departamento de seguridad y sistemas, instalaban y ejecutaban los antimalware mediante pendrives USBs y dispositivos externos, que eran suministrados por la empresa y que no se sacaban de allí. 

Sin embargo, Teresa, una investigadora de la empresa, se presentó voluntaria para trabajar en ese proyecto. Al no disponer la empresa de más pendrives USB en ese momento, y aun sabiendo el riesgo que corría, decidió utilizar su portátil personal. En principio, tomó ciertas precauciones, mediante antivirus actualizado en el PC, con firmas para todo el malware conocido en el momento y con firewall para conexiones entrantes. Se conectó con un cable cruzado, configuró direccionamiento IP de la misma red, copió un antimalware y lo instaló. Estuvo trasteando con el portátil, e incluso hizo algún tcpdump para ver qué conexiones salientes intentaba ejecutar el malware, si hacía una llamada al C&C o poder identificar qué hacía.  

No se llegó a ninguna conclusión puesto que los portátiles infectados de las centrales, no sobrevivieron. El hardware ya venía muy deteriorado y ciertos periféricos daban ya errores y no se podía ejecutar ciertas herramientas. 

La trabajadora que conectó su ordenador portátil se fue a su casa. Tras el trabajo realizado, pidió unos días de vacaciones. Estando en casa, se dio cuenta, que cuando estaba haciendo el tcpdump, había tenido que deshabilitar el firewall personal, y habilitar el routing en su máquina para ver si había cambio de comportamiento en el tráfico de red que enviaba el PC infectado. Bueno, dijo,…. no creo que haya pasado nada por esto. Desde su casa se conectó a la red Wifi, enchufó varios USBs personales, y durante varios días se comunicó con diferentes personas, intercambiando ficheros por USB, e incluso se conectó a varias redes inalámbricas públicas. 

A los pocos días, su portátil empezó a dar fallos. Pantallazos azules, sobrecalentamiento de CPU, errores de disco… algo no iba bien. Llamó a su empresa, e indicó a otros expertos, que había participado en la investigación de los portátiles contaminados. Sus compañeros le dijeron que arrancase en modo a prueba de fallos, reinstalase el Windows, y que si no se arreglaba, llevase el portátil a una tienda de informática de su barrio y que allí se lo arreglasen. 

Y así lo hizo, fue a la tienda más conocida de su barrio y allí el ordenador tuvo contacto con los de otros pacientes que se encontraban en la misma red, así como con varios operarios y profesionales de la misma tienda, que se conectaron con un cable cruzado contra el de ella para hacer un diagnóstico. 

Pero aquello cada vez iba a peor. No había forma de volver a un punto de restauración anterior, y cada vez se calentaba más. Su pareja, incluso llamó preocupado a la oficina de Teresa, puesto que había leido en twitter, y medios digitales, sobre lo devastador del malware que estaba afectando a otras empresas en algunas plantas nucleares, y claro, él era conocedor que su pareja había usado su ordenador personal para su trabajo, y tenía miedo por otros ordenadores de casa, que pudieran haberse infectado. 

Al final, la empresa envió una furgoneta del departamento de informática a buscar el ordenador de Teresa a su casa. La furgoneta tenía red wifi, y el ordenador de Teresa estuvo conectado a ella. Según dejaron el ordenador de Teresa en la empresa, utilizaron la furgoneta y su red wireless para transportar otros ordenadores pertenecientes a otros departamentos. 

A los pocos días, llevaron el ordenador de Teresa a su empresa, y decidieron aislarlo: Estaba infectado. La noticia se filtró a la prensa. Una de las empresas más importantes del país, que trajo un potente malware sin cura a España, ha tenido algún fallo, y ahora el malware puede estar en cualquier parte. A partir de ahí, los directivos de su empresa, empezaron a dar palos de ciego, a convocar ruedas de prensa en medios de prensa, e intentar calmar a la población. En medios de prensa y  redes sociales no se habla de otra cosa, se pide la destitución de la responsable de seguridad de la empresa, llamada “Janna Formateo", que sin tener conocimientos técnicos respecto lo que podía llegar a pasar, empezando por haber dejado sin recursos ni presupuesto para disponer de más pendrives USB de empresa, licencias de antimalware corporativo, etc… tomó la decisión de intentar salvar los dos portátiles infectados en la planta nuclear, trayéndolos a la central en España, confiando en los cuidados de sus expertos. A los pocos días, nuevos portátiles personales fueron llevados al laboratorio de la empresa, para tenerlos en observación. Se provisionó una sala, destinada originalmente a formación,  para poder atender nuevos portátiles y dipositivos. La responsable de seguridad tomó la drástica decisión de destruir un iPad de la trabajadora, que puede que se hubiese conectado a la misma red Wifi que el ordenador infectado. En ese Ipad, Teresa guardaba fotos, datos personales e innumerables recuerdos, de los que no es posible hacer un backup. En las redes sociales, la gente se organizaba, hacía campañas para que no destruyesen el Ipad de Teresa, que posiblemente al tener un sistema operativo diferente, el virus no sería igual de dañino y que incluso si afectaba al Ipad, se podría aprender de él. Pedían que no lo destruyesen, que lo tuvieran en observación, en un sitio especializado en malware para ipads, y en el que pudiesen intentar delimitar la forma de propagación y el efecto en ese sistema operativo, para poder generar una firma válida o un patrón heurístico para poder bloquear la acción del malware. Finalmente, el ipad fue destruido, y con él, un montón de recuerdos de Teresa y de su pareja.

En TV no se habla de otra cosa, el responsable de RRHH de la empresa, le echa la culpa a Teresa, por haber conectado su portátil al ordenador infectado, y por no haber avisado al técnico de la tienda de ordenadores de su barrio, que había estado analizando un malware peligroso desde su portátil. La responsable de seguridad, se lava las manos con el tema y apenas da explicaciones sobre el plan a seguir para controlar una infección de la que se desconoce el alcance. Finalmente, la dirección general de la empresa, que dieron su aprobación para traer a España los dos portátiles infectados de la planta nuclear, y que tiene descontento a una grandísima mayoría de los trabajadores de la empresa, debido a su política de recortes de presupuestos, despidos, condiciones de trabajo infrahumanas y haberse visto envueltos en desafortunados escándalos de corrupción, en vista de la inutilidad manifiesta de la responsable de seguridad, decide darle el mando a la subdirectora para que tome las riendas del caso.   

¿Os suena todo esto verdad?

He querido relatar como si de un incidente de seguridad se tratase, lo que sin duda ha sido algo completamente trágico. Ya no sólo por traer a España un virus aún incurable, introduciendo un riesgo, a mi modo de ver innecesario, sino por la desafortunada y patética gestión de todo lo que se ha ido haciendo. Echarle la culpa a la auxiliar de enfermería, de lo que sin duda ha sido un error grave por su parte, posiblemente por la desinformación y por la falta de protocolo inicial, unido al aire chulesco de determinados consejeros regionales, así como la incapacidad manifiesta de otros, merece sin duda que rueden las cabezas en la cúpula de “la empresa”.


Desde aquí, todo mi apoyo a Teresa Romero, la auxiliar de enfermería que por acción del virus del Ébola, aún sin tratamiento que garantice su curación, que fue traído a España sin que ella ni nadie lo pidiésemos, y que por arriesgar su vida dando cuidados a los dos pacientes infectados, ahora se debate entre la vida y la muerte. Ojalá se salve, y se acoten el resto de los casos lo mejor posible, sin que se genere una pandemia.
Leer más...