Llegados a este punto, significa que ya habéis leído la Primera y Segunda parte de esta serie de artículos sobre Análisis Forense en la Nube. En los “episodios” anteriores os contaba la parte teórica del funcionamiento de los sistemas de computación en la nube, para a continuación, explicar como realizar un análisis de la información y artefactos forenses que pudiera albergar un sistema en la nube, en este caso, una instancia de Ubuntu 16, alojada en la nube de Amazon WS.
En este último apartado (III), os contaré como realizar un análisis forense en e vivo de estas máquinas o instancias en la nube, más concretamente como realizar un análisis de la memoria RAM de una instancia de AWS. Quizás en otra ocasión os cuente como realizar un análisis de tráfico de red de una máquina en la nube, pero de momento, nos vamos a centrar en el análisis de la memoria RAM.
Fig. Ejecución de htop en una máquina Ubuntu
Que la máquina a analizar sea un Ubuntu 16.04 no es fruto de la casualidad, en la parte anterior de este artículo ya os contaba que seleccioné un sistema operativo tipo Linux a propósito. Analizar la memoria RAM de un sistema Windows, no tiene mucha complicación, poco importa que la máquina se encuentre en la nube o delante de nuestros ojos, el procedimiento es prácticamente el mismo. Sin embargo, con Linux la cosa cambia bastante, no es que sea imposible realizar un análisis de la RAMde un sistema Linux, pero no hay un protocolo tan simple o intuitivo como puede ser con un Windows. Si utilizamos la herramienta Volatility nos daremos cuenta que prácticamente, por defecto, ya viene con todos los perfiles de los distintos sistemas Windows que tenemos en el mercado (XP, Vista, 7, 10… así como con sus distintos “Servipacks”), cosa distinta ocurre con los sistemas operativos Linux, en los cuales tendremos que compilar nosotros manualmente cada uno de los perfiles del sistema, para que Volatility “entienda” como funciona cada uno de los kernel de Linux. El problema es que la versiones de Windows prácticamente se cuentan con los dedos de la mano, si embargo el número de kernels de Linux existentes hoy en día, son prácticamente infinitos, ya que cada cual puede “engendrar” el suyo propio, lo que imposibilita que Volatility pueda incluir todos los perfiles de todos los kernel de Linux existentes.
Pero tampoco nos vayamos a asustar, que no venga incluido en Volatility un perfil por defecto, no quiere decir que no se pueda realizar un análisis de la memoria RAM de ese sistema, a continuación os detallaré cuales son los pasos necesarios para poder realizar este análisis, pasos que por cierto, no difieren mucho de un análisis físico a un análisis en la nube.
Explicado esto, ahora nos toca ponernos manos a la obra, en primer lugar, tendremos que saber cual es el Kernel de nuestra máquina Linux “victima”, para ello la teoría dice que ejecutando el comando ”uname -r” nos devuelve la versión del Kernel. Pero en este caso, vamos a hacer un poco de trampa. No nos interesa interactuar en exceso con nuestra máquina victima, digamos que ya sufrido lo suyo con el ciber ataque que recibió, como para seguir ejecutando comandos y procesos en ella.
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.
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.
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
“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:
