Forense en Babia. Parte 2

Publicado el Por Manuel Guerra

Si en el artículo anterior: “Forense en Babia. Parte 1” os contaba solamente la parte teórica de los sistema de computación en la nube, en esta segunda y tercera parte nos meteremos hasta la cabeza en el barro y pasaremos a la parte práctica del análisis forense en la nube. Como ya os imaginareis, cada vez son más las infraestructuras informáticas que operan en la nube, es decir, en un tercer lugar fuera del alcance físico de los administradores de sistemas y también de los analistas forenses informáticos, lo que implica que tanto para unos como para otro, su labor diaria cambie drasticamente. Los administradores de sistemas ganaran en tranquilidad al no tener que estar preocupados por fallos de hardware, ya que de estos fallos se encargan otro, los “dueños” de la nube. Pero para los analistas forenses la cosa cambia, la costumbre ancestral de todo lo que se “volcaba”, “clonaba” y “analizaba”lo podíamos ver y tocar con nuestras manos cambiará con el análisis forense en la nube, ya que la nubes no se tocan, solo se huelen 😉 .Para este cambio de paradigma tendremos que disponer de una mente abierta que nos permita adaptarnos a estas nuevas técnicas y modalidades de análisis, aunque si bien es cierto que los protocolos se basan en las técnicas tradicionales que llevamos años y años ejecutando, habrás ciertas peculiaridades como las que hoy os voy a contar, que harán que este tipo análisis sea un poco mas complejo.

Vamos al lío, en esta ocasión nos tocará analizar una instancia de un Ubuntu 16.04 de 64bits, sin interfaz gráfico, la cual está desplegada en los servidores de Irlanda de Amazon Web Services (AWS), la cual ha sufrido un ciber ataque, en el que alguien ha podido tomar el control remoto de esta instancia, para desplegar una servidor oculto en la Dark Web para vender droga a través de TOR, lógicamente, todo ello sin el permiso de los dueños de la instancia de AWS.

El primer paso, será acceder al panel de administración de la instancia afectada para de este modo poder determinar las características técnicas de la misma. En la siguiente imagen podremos ver toda esta información, como por ejemplo: Nombre de la Instancia (VPS IRLANDA); Dominio público con el que está operando (ec2-34-244-248-204.eu-west-1.compute.amazonaws.com) ; Tipo de Instancia (t2.micro); Zona de operación (eu-west-1c); Estado (Running / Stopped..); Identificador único de la instancia (i-09d357…); Grupos de Seguridad y las IP publicas y privadas de la instancia (172.31.21.174 y 34.244.248.204). Toda esta información la deberemos registrar debidamente.

 

Fig 1 Panel con las características de una Instancia AWS

 

También deberemos anotar las Keypass asociadas a la instancia (NambCORE), esto es la “key” que nos permite establecer una conexión remota segura a través de SSH con la instancia en cuestión, es decir, para poder administrar la instancia deberemos tener acceso a este fichero, si sospechamos que alguien se ha podido conectar de forma fraudulenta a nuestra instancia, significará o que han tenido acceso a nuestra “key” secreta, o que nos han generado una nueva para establecer una nueva conexión, por eso es importante listar todas las keypass generadas para una misma instancia. En esta ventana también podremos ver que tipo de instancia se trata (ubuntu-xenial-16.04-amd64-server-20170811 ); las tarjetas de red habilitadas (eth0); el tiempo que la máquina lleva encendida (51 horas) o los volúmenes de almacenamiento disponibles (/dev/sda1).

 

Fig 2 Características técnicas de la instancia 

 

Otra comprobación rutinaria, pero no menos importante será comprobar la configuración de las reglas del firewall que han sido habilitadas, en este caso, nada relativamente sospechoso (Un 80 y un 22).

 

Fig 3 Reglas Firewall

 

Llegados a este punto deberemos tomar una decisión muy importante: mitigar el ciber ataque cortando por lo sano, apagando la máquina afectada o “desconectándola” de Internet, o dejándola lanzada para analizar todas las comunicaciones que establece. En todo caso no hay una respuesta concreta, todo ello dependerá de cada caso y de la importancia del recursos afectado, así como de la información que contenga o de la disponibilidad que necesite. No hay que olvidar que ahora mismo el principal problema que tenemos, es la falta de control absoluto sobre la totalidad de los elementos afectados, en realidad solo tenemos un acceso web y en el mejor de los casos una conexión SSH a una máquina física que se encuentra a miles de kilómetros de nosotros y en la que verdaderamente está ocurriendo el ciber ataque. No podemos desconectar cables, no podemos conectarnos a una pantalla del Hypervisor, no podemos tirar del enchufe, no podemos sacar los discos duros… – ¿Y que podemos hacer?. – Vamos a verlo.

Lo primordial será salvaguardar la evidencia, para ellos crearemos un snapshot de la instancia afectada:

 

Fig. 4 Proceso de creación del Snapshot 

 

Fig. 5 Snapshot terminado

 

Ahora con el snapshot que acabamos de crear, generamos un volumen lógico del mismo.

 

Fig. 6 Creación de un Volumen desde un Snapshot 

 

En este momento ya disponemos una “copia forense” del disco duro del servidor afectado, pero tenemos un pequeño problema, la “la copia forense” se encuentra a varios miles de kilómetros de distancia de nosotros, y lo que es peor, de nuestro laboratorio forense. Por desgracia AWS, no dispone de un sistema 100% que nos permita “descargar” o “traernos” esa copia forense de una forma sencilla. Por eso que si la montaña no va a Mahoma, tendrá que ser Mahoma quien vaya a la montaña. – ¿Y como va a ir Mahoma a esa montaña?, o lo que es lo mismo: – ¿Como vamos a llevar un laboratorio forense a los servidores de Amazon Web Service de Irlanda?. – Muy fácil, ¡llevándolo!.

Tranquilos, no tendréis que comenzar desconectar vuestras pantallas de 40 pulgadas ni vuestros equipos forenses del laboratorio para llevarlo todo a Irlanda, esta vez será un poco mas fácil. Básicamente la idea es levantar una nueva instancia de Ubuntu en la misma zona de AWS (eu-west-1a), instalar las herramientas forenses de SIFT – Sans para así convertir el Ubuntu en una máquina forense y después asignarle el volumen lógico (disco duro) que hemos creado sobre la maquina afectada, y así poder analizarlo todo ello en remoto. Para ellos seguiremos los siguientes pasos:

Generamos una nuevo usuario “administrador” a nuestro AWS.

 

Fig 7 Generación de usuario 

 

Descargamos el fichero .pem para poder establecer la conexión remota SSH a nuestra máquina forense.

 

Fig. 8 Descarga del fichero 

 

Creamos una nueva instancia, la cual se convertirá en nuestra máquina forense. Aunque en un principio podrá ser perfectamente un Windows, veremos en las próxima parte de este artículo, que si levantamos una instancia exactamente igual a la afectada, podremos matar dos pájaros de un tiro y así ser un poco mas eficientes a la hora de realizar el análisis.

 

Fig. 9 Levantamos un Ubuntu 16.04

 

Como ya dije anteriormente, nuestra nueva instancia forense, deberá estar obligatoriamente en la misma zona de AWS (eu-west-1a) que el volumen que hemos generado anteriormente (no en la misma zona que la instancia afectada), ya que si no, no podremos “conectar” ambos elementos.

Seguir leyendo

Forense en Babia. Parte 1

Publicado el Por Manuel Guerra

Como hoy he estado en el Cybersecurity Summer BootCamp, evento organizado por INCIBE en la ciudad de León y en el que he tenido el honor de ser el profesor del taller de tratamiento de evidencias digitales a jueces, aprovecho para escribir este nuevo artículo de GLIDER.es sobre Forense en Babia. Para los que no lo sepáis, Babia es una comarca con encanto situada en la provincia de León ;), así que hoy os voy a hablar de eso, de Forense en Babia, o lo que es lo mismo: Forense en las nubes (Cloud Forensic para los pro). Hace no muchos años, si a cualquier analista forense informático, o solo informático, le hablásemos de la nube, lo primero que haría es mirar al cielo por si llueve, yo incluido. Pero los tiempos cambian, y en informática más todavía. Actualmente estamos en el año 2018, posiblemente ahora mismo estés leyendo este artículo desde tu smartphone con pantalla HD de 5 pulgadas, o quizás lo estés leyendo en tu tablet último modelo. Otros quizás lo estéis leyendo en vuestro portátil ultraslim con una duración estimada de la batería de 8 horas. Pero de lo que estoy seguro es que ninguno de vosotros lo está leyendo en un Windows 98 con un Intel Pentium II y 512Mb de RAM. ¿Acaso me equivoco?, yo creo que no.

Fig. 1 Nubes de tormenta.

 

De un Windows 98 al actual Windows 10 solamente han pasado 17 años. Fijaros todo lo que ha cambiado la tecnología en tan poco tiempo. Entrando un poco más en el mundo de la informática forense, para quien se acuerde, allá por el año 2000 existían unos sistemas de almacenamiento llamados disquetes de 3 1/2. Unos prodigios de la tecnología que eran capaces de almacenar 1,44Mb en una superficie de menos de 8 centímetros cuadrados. Actualmente en esa misma superficie podemos disponer de discos duros que pueden llegar a almacenar 6Tb de información, lo que vienen siendo unos cuatro millones de disquetes de tres y medio. Así de rápido avanza la tecnología y así de rápido tiene que avanzar la informática forense. Nos guste o no, un analista forense se tiene que adaptar a los tiempos y sobre todo a las tecnologías. Imaginaros un analista que allá por 1998, cuando salió el primer Windows 98, dedicó dos años de su vida a especializarse en análisis de disquetes de 3 1/2 y artefactos forenses de Windows 98. ¿Alguien cree que si hoy en día ese analista no se ha actualizado a las nuevas técnicas forenses y tecnológicas podrá realizar su trabajo correctamente?. Lógicamente la respuesta es no.

Fig. 2 Diskette de 3 1/2

 

¿Entonces que futuro tendrá un analista forense que solamente sepa extraer la información que se encuentra físicamente almacenada en un disco duro, en un teléfono móvil, en una tablet, pero no sabe “analizar la nube”? Como ya os imaginareis, no mucho. La tendencia actual es que la información no se almacene en los dispositivos, si no que todo se suba a la nube, al cloud, y es trabajo del analista estar suficientemente entrenado y actualizado para poder llegar a obtener esa información de la forma adecuada. Por desgracia, esta no es precisamente una tarea fácil, pero si que es una tarea necesaria, ya que es hacía donde nos está llevando la tecnología, y como ya dije antes, el analista tiene que estar donde está la tecnología.

Fig. 3 Amazon Web Services

 

Seguir leyendo

TeamViewer bajo la lupa Forense.

Publicado el Por Manuel Guerra

TeamViewer es un programa que permite a los usuarios controlar remotamente otro ordenador sin necesidad de grandes conocimientos informáticos. Tan solo es necesario introducir un identificador y un PIN para de este modo tomar el control de cualquier ordenador, así de fácil, desde cualquier parte del mundo podremos controlar un ordenador con la única condición de que disponga de una conexión a Internet y el programa Teamviewer instalado. Lógicamente este es un programa totalmente lícito, que está pensando para administrar o reparar remotamente ordenadores sin la necesidad de estar físicamente delante de ellos.

 

Fig. 1 Hack Teamviewer

 

Pero, si este software está diseñado para ahorrar costes y facilitar el trabajo a los administradores de sistemas. – ¿Qué hago escribiendo sobre TeamViewer en GLIDER.es?. – La realidad nos indica que muchos “ciber ataques“, normalmente sufridos en pequeñas y medianas empresas, no son producto de APTs (Advanced Persistent Threat), ni tampoco de ataques avanzados mediante el uso malware tipo 0 Day cuyo código no es todavía conocido. Siguiendo la premisa del principio de economía de la Navaja de Ockham: en igualdad de condiciones, la explicación más sencilla suele ser la más probable. Así que si nos tenemos que enfrentar a un ataque que ha sufrido una empresa, por el cual le han borrado toda la base de datos de clientes o facturación. – ¿Por dónde comenzaríamos el análisis?, ¿buscaríamos trazas de malware o analizaríamos los logs de acceso de la máquina comprometida para ver y determinar lo que ha ocurrido?. Si disponemos de un equipo lo suficientemente grande, podemos comenzar a estudiar varias hipótesis al mismo tiempo, pero en condiciones normales, iremos una por una, siguiéndola hasta que la podamos descartar o nos lleve a unos indicios suficientemente robustos que identifiquen la causa del incidente de seguridad. Hoy, como tantas otras veces, el origen del ataque provine de algo tan antiguo como es el ego, la venganza o la ira, más concretamente de un hipotético empleado que fue despedido de una empresa y como venganza decidió conectarse a los servidores de su antiguo trabajo para hacer todo cuanto daño esté a su alcance.

Ahí es donde entra TeamViewer, si conjugamos una empresa con una política de credenciales laxa, que no elimina las cuentas de usuario de un empleado despedido, con un empleado/delincuente, con mucho ego, mucha ira, mucha ansía de venganza y poco sentido común y auto control, que aprovechándose del programa que utilizó durante años para conectarse de forma remota a su empresa y poder trabajar desde fuera de la sede de la misma, obtenemos un nuevo artículo para GLIDER.es. Un nuevo artículo en el que TeamViewer será la fuente de Evidencia Digital a estudiar.

 

Fig. 3 Una fuente de evidencia digital

 

Tampoco hay que olvidar que no siempre todo va a ser culpa de un empleado al que han despedido y decide conectarse de forma remota a su anterior empresa para eliminar o robar información importante. En otras ocasiones el ataque podrá ser fruto de una mala configuración del sistema, por ejemplo al exponer de forma pública e involuntaria las credenciales de acceso al sistema remoto de TeamViewer, credenciales que alguien con no muy buenas intenciones puede utilizar para hacer el mal.

 

Fig. 4 Leak TeamViewer en un establecimiento hostelero

 

Seguir leyendo

Todo lo que WhatsApp sabe sobre ti.

Publicado el Por Manuel Guerra

“Todo lo que WhatsApp sabe sobre ti”, en el mundo en el que vivimos, de noticias sensacionalistas y normalmente faltas de rigor, este sería el título ideal para este artículo, con el que seguro que cosecharía muchas más visitas que con el título que elegí, pero como ya sabéis, no soy muy fan de las noticias tipo “clickbait” para atraer seguidores, prefiero la objetividad y el realismo, por eso que el artículo de hoy se llama: “Todo lo que WhatsApp sabe sobre ti”. 😉

Como seguro que ya sabréis, el próximo 25 de mayo de 2018, comenzará a aplicarse en España y en el resto de Europa, el Reglamento General de Protección de Datos (RGPD), que sustituirá a la actual normativa vigente. Aunque realmente este reglamento ya entró el vigor hace años, sin embargo se dio una moratoria de dos años para que las Instituciones, empresas y organizaciones que tratan datos fueran preparándose y adaptándose para el momento en que este Reglamento se comenzase a aplicar.

 

Fig. 1 Menú para solicitar información de WhatsApp

 

Lógicamente, yo no soy experto en Protección de Datos, por eso no voy a entrar a comentar este Reglamento, sin embargo para el post que hoy me ocupa, sí que me gustaría hablar del artículo 59 de dicho Reglamento, en el que dice que se deben facilitar al interesado los datos personales que obren en una base de datos sobre su persona, para que esta puede rectificar u oponerse a los mismos. – ¿Y esto que tiene que ver con la informática forense?. – Pues que las distintas redes sociales, plataformas de correo… Etc deben permitir ver a sus usuarios todos los datos que tengan sobre ellos. WhatsApp, como es lógico, no queda fuera de esta ley, es por ello, que desde la versión 2.18.132 de WhatsApp, ya se ofrece a los usuarios de esta red social la posibilidad de generar un informe con todos los datos que esta aplicación conoce sobre sus clientes/usuarios. Esto es exactamente de lo que voy hablar en este artículo: cómo lograr obtener este informe y mostrar la información que contiene, información que no solo va a tener una importancia legal,  en el contexto de un análisis forense informático, será una valiosa fuente de datos. Vamos a ello:

 

Fig. 2 Artículo 59 RGPD

 

Seguir leyendo

Solución Final al Forensic CyberSecurity Challenge. Parte 2/2

Publicado el Por Manuel Guerra

Ya ha pasado casi un mes de la celebración de ForoCiber en la ciudad de Badajoz, como ya os conté en el artículo: “Solución al Forensic CyberSecurity Challenge. Parte 1”, fui uno de los retadores del CTF (Capture the Flag), de la cátedra ViewNext-UEx sobre “Seguridad y Auditoría en Sistemas de Software” que se llevó a cabo en ForoCiber, mas concretamente me encargué del diseño del reto forense.

Como ya sabéis, GLIDER.es, simplemente es un sitio web dónde cuando me apetece y tengo el suficiente tiempo, escribo unas cuentas lineas sobre temas relacionados con la informática forense, hacking o cualquier otro tipo de aventura. La finalidad de esta web, ni es obtener dinero, ni llegar a situar a GLIDER.es como referente en webs de este tipo. Los que me conocéis, sabéis que esto es simplemente un hobbie que terminará cuando ya no me motive escribir este tipo artículos, eso sí: ¡Espero que todavía quede mucho para que llegue ese día!. Os estaréis preguntando para que os cuento todo esto ahora, el motivo es sencillo, últimamente no dispongo de todo el tiempo que me gustaría para escribir artículos en GLIDER.es, y tengo claro que escribir aquí nunca se convertirá en una obligación, como ya dije, es un simple entretenimiento.

Durante este mes habéis sido muchos los que me escribisteis para preguntar cuando publicaría la segunda parte del artículo: “Solución al Forensic CyberSecurity Challenge”. Os agradezco enormemente vuestro interés por los temas que aquí público, y sobre todo por los ánimos que me dais para continuar, pero tenéis que entender que escribir un artículo técnico con las características de los aquí publicados requiere mucho tiempo, tiempo del que no siempre se dispone. Pero como mas vale tarde que nunca, y lo prometido es deuda, hoy por fin tengo un rato para sentarme tranquilamente delante del ordenador, desconectar de otros quehaceres (que a veces también es necesario), y escribir un artículo mientras disfruto de un sabroso café con leche. Así que os voy a contar la forma de resolver el: Forensic CyberSecurity Challenge.

En primer lugar quiero pedir disculpas a los que habéis leído la Parte 1 de este artículo, en ella os explicaba un método un tanto bizarro (extravagante) para unir las 157.288 partes del fichero de la imagen forense. Ya os comenté que esa no era la forma mas “cómoda” para realizar el concatenado de ficheros, pero en ese momento (la competición estaba abierta) no podía dar una pista que favoreciera a los competidores que visitaran GLIDER.es respecto de los que no, por eso di una pista para que los que estaban atascados pudieran continuar en cierto modo, pero a cambio, tendrían que invertir mucho tiempo en ejecutar todos los comandos que en ese artículo detallé, y no eran precisamente pocos 😉

Seguir leyendo