C0Nferencias

Publicado el Por Manuel Guerra

El tiempo pasa, y pasa para todo el mundo, ya hace más de media década que di mi primera conferencia de ciberseguridad, eran 20 chavales de un grado de Formación Profesional relacionado con la informática, sentí que podía compartir con ellos la mucha o poca experiencia que por aquellas tenía en el campo de la Ciberseguridad y el Análisis Forense. Hoy, siete años después, sigue ocurriendo exactamente lo mismo, me gusta compartir de forma desinteresada con quien esté interesado en aprender lo poco que le pueda enseñar, con esa filosofía nació GLIDER.es, un lugar dónde compartir mis aventuras y “researches” en Informática Forense y Hacking.

En estos siete años, ya son muchas las charlas que llevo a mis espaldas, muchas de ellas grabadas en vídeo y publicadas en plataformas como YouTube por parte de los organizadores, otras, en forma de curso gratuito subidas a plataformas de formación online, algunas otras no han podido ser grabadas, pero si dispongo de las diapositivas que utilice para impartirlas. De ahí la idea de este apartado “CONferencias” de Glider, dónde poder compartir con vosotros todo el material que estos años he ido generando para poder realizar estas conferencias. Fueron varios los que me comentaron que les costaba encontrar las presentaciones o los vídeos de las distintas charlas que había dado, ya que al estar desperdigadas por distintos sitios de Internet, no lograban localizarlas, ahora las iré centralizando todas aquí.

 

Fig. Stickers de distintas CONs

 

Lógicamente, este apartado no sería nada sin mis queridas CONs, (Conferencias de Ciberseguridad) en las que tan buenos ratos he pasado y pasaré: Hack&Beers por todo el territorio nacional, HoneyCON en Guadalajara, QurtubaCON en Córdoba; ShellCON en Santander, MorterueloCON en Cuenca, RootedCON en Madrid, AlbahacaCON en Huesca, MoscowCON en Moscú, PaellaCON en Valencia, CONPilar en Zaragoza, Hackron en Canarias CONAnd en Andorra, ForoCiber en Badajoz East Mad Hack en Arganda, X1RedmasSegura en Madrid, Jornadas CCN-CERT en Madrid y CyberCamp itinerante por España, y por supuesto programas como el de Palabra de Hacker y Mundo Hacker TV.

En este apartado CONferencias iré publicado las distintas conferencias que vaya impartiendo a lo largo del año, pero no puedo prometer publicarlas todas, muchas de ellas no son públicas y en otras, la organización no se puede hacer cargo de la grabación de la conferencia. El resto de conferencias, las podréis encontrar aquí:

 

 

Título: Mitos, debilidades y delitos imperfectos en Tor.

Evento: X1 JORNADAS STIC CCN-CERT Centro Criptológico Nacional.
Fecha: Diciembre 2017


Fig. Fotograma de la conferencia.

Ponentes: Francisco Rodríguez (INCIBE) y Manuel Guerra.
Editor video: CCN-CERT
Descripción: En esta ponencia realizamos un análisis de la red Tor desde un punto de vista realista, dejando sensacionalismos a un lado. En la primera parte de la charla, Francisco nos habla de los delitos cometidos a través de la red Tor así como de la surface web, realizado una comparativa de ambas redes. A continuación, Manuel Guerra, realiza una práctica en directo en la que se demuestra una serie de vulnerabilidades que pueden existir en la red Tor, las cuales pueden permitir identificar plenamente a un usuario de esta red.
Difusión: Pública.
Materiales: Enlace al Video.

 

Título: Investigación en Informática Forense y Ciberderecho.

Evento: CyberMOOC – Universidad de Extremadura.
Fecha: Octubre 2018


Fig. Inicio del MOOC

Ponentes: Andrés Caro (Profesor de la Universidad de Extremadura), Enrique Avila (Director del Centro Nacional de Excelencia en Ciberseguridad), José Aurelio (Auditor Informático en Evidencias), Silvia Barrera (Experta en Ciberseguridad), Manuel Guerra, Pablo Gonzalez (Technical Manager & Security Telefónica Digital España), Ruth Sala (Directora del despacho de abogados Legalconsultor.es), Susana Gonzalez (Socio gerente en Ecixgroup) y  Tote Sancho (Personal Científico e Investigador de la Universidad de Extremadura).
Editor video: Miriadax
Descripción: Este MOOC gratuito está indicado para todos aquellos que deseen iniciarse y profundizar en Informática Forense y Derecho Tecnológico. El MOOC está especialmente orientado a una audiencia muy heterogénea: Profesionales del mundo de la informática que deseen formarse en aspectos técnicos de informática forense, hacking ético y ciberseguridad, a la vez que aprender la legislación que acompaña todo ese tratamiento técnico. En él os hablaré desde un punto de vista básico, qué es, y para que sirve la informática forense.
Difusión: Pública, previo registro.
Materiales: Enlace al Curso Gratuito.

 

Título: Taller: Autopsia a Whatsapp.

Evento: Congreso de Ciberseguridad CyberCamp 2017 – Santander.
Fecha: Diciembre 2017


Fig. Autopsia a Whatsapp

Ponentes: Manuel Guerra.
Editor video: INCIBE
Descripción: La idea de este taller, eminentemente práctico, es demostrar y mostrar toda la información que se puede extraer desde el punto de vista forense, de la aplicación de mensajería instantánea más utilizada en España y en el resto de Europa: WhatsApp.
Difusión: Pública.
Materiales: Enlace al Video.

 

Título: Taller: Cambiando el CuenTOR.

Evento: Congreso de Ciberseguridad CyberCamp 2016 – León
Fecha: Diciembre 2016


Fig. Cambiando el CuenTOR

Ponentes: Francisco Rodríguez (INCIBE) y Manuel Guerra.
Editor video: INCIBE
Descripción: El objetivo del taller es desmitificar mucha de la información proporcionada por los medios de comunicación sobre red TOR, proporcionando al público información realista obtenida de primera mano tanto por INCIBE, UIT y TOR Project. Se proporcionaran el conocimiento práctico para el uso de Tor desde un punto de vista técnico.
Difusión: Pública.
Materiales: Enlace al Video.

Seguir leyendo

Forense en Babia. Parte 3

Publicado el Por Manuel Guerra

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 RAM de 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.

 

Fig. Versión de Ubuntu 16.04 en AWS

 

Seguir leyendo

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