Tinder, cuando haces Match, no hay STOP.

Hoy os traigo un artículo un tanto distinto, pero no distinto por la temática del mismo, distinto por la aplicación que vamos a “trinchar”. Posiblemente ya os imaginareis por el título del artículo, que hoy va a pasar por el bisturí y la mesa de autopsias de GLIDER la aplicación para smartphones: Tinder. Como seguro que nadie conoce esta aplicación 😉 , os explico brevemente para que sirve. Tinder básicamente es una aplicación de citas o contactos, cada usuario crea un perfil con su descripción: nombre, foto (normalmente sugerente), edad, estatuara, empleo… y todo (todo) lo que quiera dar a conocer para ser mas “matcheable”.

Fig. 1 Match en Tinder by mashable.com

El tema de los match es muy sencillo, el usuario al darse de alta indica que es lo que busca: (hombres, mujeres, bi), edad del candidato/a y distancia en kilómetros a su posición actual. Por ejemplo podemos configurar Tinder para que nos muestre mujeres de entre 35 a 40 años, interesadas en hombres y que se encuentren en un radio de 30Km de nuestra posición. Lo de configurar la distancia es una autentica declaración de intenciones… no dejes para mañana lo que puedas hacer hoy. Configurado todo, en este caso, al usuario le irán apareciendo candidatas y este en base a la foto y su bio indicará si le gusta o no le gusta cada una de ellas, a la candidata también se le mostrará de forma aleatoria el usuario, si esta también hace match, ambos podrán chatear entre sí, si no hay match mutuo, nunca podrán hablar entre ellos. Lógicamente, a mi todo esto me lo han contado, yo no uso esta aplicación. De hecho, no hay muchas personas que confiesen que usen esta aplicación, pero la realidad es bien distinta, si nos vamos a las estadísticas de Google, Tinder ha sido descargada por más de 100 millones de usuarios en todo el mundo, y esto solo en Android.

Fig. 2 100 millones de descargas

Cierto es, que tengo algunos amigos y amigas, que me cuentan que usan esta aplicación simplemente para conocer a gente, sin mayor intención que esa, en este momento es cuando se me viene a la cabeza el anuncio de la App Chicfy, que decía algo tal que: “Claro que sí….” bueno, sea como fuere, el caso es que nosotros somos forenses y nuestra finalidad ha de ser obtener datos y evidencias empíricas de un vestigio, nada de valorar el motivo por el cual alguien decide instalar o usar una aplicación concreta en su móvil.

Fig. 3 CLARO QUE SÍ, GUAPI

Como es costumbre en cualquier sistema Android, los datos de las aplicaciones que tenemos instalados en nuestro smartphone se encuentran en la ruta “/data/data”, en este caso estamos analizado la app Tinder, tan solo tendremos que dirigirnos a la ruta “/data/data/tinder” para extraer toda la información de esta aplicación. Existen varias formas para obtener estos datos, hoy me voy a decantar por ejecutar un elegante “adb pull” para traerme todo el directorio de la aplicación a mi ordenador de análisis. Como es habitual, podemos tener problemas con los permisos de los ficheros a los que estamos accediendo a través de ADB, una buena solución es comprimir todo el directorio en .ZIP, para posteriormente “descargar” el fichero .zip el cual hemos creado desde ADB. De este modo no vamos a tener ningún problema con nuestros privilegios de usuario.

Fig. 4 adb pull al zip

Ya con el fichero .ZIP en nuestro equipo forense (en este caso un sistema Linux) descomprimimos la extracción y comprobamos que contiene una estructura con todas las carpetas y ficheros que ha generado la aplicación Tinder. Para este articulo me voy a centrar exclusivamente en cuatro directorios clave: databases, shared_prefs, app_webview y cache.

Fig. 5 Contenido de la carpeta extraída

La primera carpeta que vamos a “trinchar” será la denominada: “shared_prefs”. En ella hay un fichero de texto llamado: “appsflyer-data.xml”, en el que podemos encontrar y por lo tanto determinar, cual es el género con el que el usuario se ha registrado (hombre, mujer…), la localización GPS de su posición, su edad (la que haya puesto, que ya sabemos lo que pasa en estas apps), la versión de Android con la que está operando Tinder, el nombre del usuario, en este caso: “manu” (usuario para pruebas), marca y modelo del teléfono móvil y por último la compañía telefónica. Esta información nos puede resultar de interés si resulta que alguien se ha hecho pasar por quien no debe.

Fig. 6 fichero appsflyler

En el fichero “LastActivityDatePreferencesRepository_last_activity_date.xml”, encontraremos un registro con la fecha y la hora en la que se utilizó/abrió por última vez Tinder en ese teléfono en concreto. “– Nah, yo tengo el Tinder pero no lo uso…

Fig. 7 Información con timestamps

Otro de los ficheros que encontraremos en la carpeta “shared_prefs”, es el fichero “sp.xml”, el cual, entre otros datos, contiene el User Agent concreto con el que opera la aplicación Tinder. Este dato se podría llegar a utilizar como un fingerprint o huella digital de la navegación web que se ha realizado desde el propio Tinder.

Fig. 8 User Agent

De nuevo, en el fichero “sp.xml”, tambien podremos determinar la geoposición del usuario a través de unas coordenadas GPS. Que Tinder necesite registrar en varios sitios la geoposición del usuario es normal, ya que según dicen, yo nunca lo he probado, para buscar a otros usuarios/as es necesario estar físicamente cerca de su posición, o al menos que el GPS crea que está cerca de una posición.

Fig. 9 Información de ubicación

El fichero xml “com.tinder_preferences”, en principio no tiene demasiados datos relevantes, a excepción de dos timestamps, el: “SESSION_APP_START” con la fecha en formato epoch del momento en el que se inició la aplicación, y la variable “SESSION_APP_END”con la fecha en la que se cerró la sesión. De este modo se puede llegar a determinar el tiempo que la aplicación/sesión permaneció abierta.

Fig. 10 fechas de las sesiones

Como sabréis, yo no, se puede iniciar sesión en Tinder con una cuenta de Facebook, eso sí, ya os anticipo que no es buena idea mezclar Tinder y Facebook si lo que buscáis es tener una cuenta de Tinder “undercover”. En el fichero “com.facebook.loginManager.xml”, queda registrado si el login de Tinder es mediante una cuenta de Facebook o no.

Fig. 11 Vinculación a Facebook

Es el turno de analizar la segunda de las carpetas, en el directorio “app_webview/…/leveldb”, encontraremos un fichero llamado “LOG”, que como su propio nombre indica es un pequeño registro de tareas de la aplicación. No vamos a entrar en lo que significa cada uno de los registros. Desde el punto de vista del análisis, es interesante saber que en este fichero podemos encontrar un registro tipo timestamp de “cosas” que hace la app Tinder, y si hace “cosas” es que está abierta, o lo que es lo mismo, es otra forma de contrastar o determinar si esta aplicación en un momento dado estaba abierta.

Fig. 12 Ficheros de log

Subiendo un nivel a la ruta: “Web Data”, encontraremos una base de datos muy curiosa, o mejor dicho, un tabla. En la tabla “unmasked_credit_cards”, podremos localizar las distintas tarjetas bancarias que el usuario vinculó a la aplicación para poder realizar pagos. Resulta, que según me han dicho, si no se es muy ducho/a en los temas del amor, existe la posibilidad de pagar cierta cantidad de dinero a Tinder y de este modo entras en una especie de modo “pro” o “turbo” para lograr más “matchs” en menos tiempo.

Fig. 13 Datos bancarios

La tercera carpeta que vamos a analizar en este artículo se llama “cache/image_manager_disk_cache”. En ella habrá un fichero de texto llamado: “journal” que contiene una serie de líneas con un “string/hash” suficientemente largo como para que no pueden existir duplicidades. Además cada línea termina con un número aparentemente aleatorio. SPOILER: No es un número aleatorio, es el tamaño en bytes del fichero al que hace mención.

Fig. 14 Journal

Resulta que en ese mismo directorio existen otro tantos ficheros como líneas que contiene el fichero: “image_manager_disk_cache” y con el mismo nombre, por supuesto, también con el mismo tamaño al que se hace mención en el fichero de “journal”. Básicamente el fichero “jourunal” es un listado con los nombres y tamaño de todos los ficheros almacenados en esta carpeta.

Fig. 15 Caché

En un primer momento estos ficheros nos pueden parecer “garbage”, pero si abrimos cualquier de ellos con un editor hexadecimal pronto veremos que todos comienza con el mismo patrón: xFF xD8, o lo que es lo mismo, la cabecera hexadeciamal de un fichero de imagen tipo JPG. Lo que significa que estos ficheros son imágenes sin extensión, por lo que las podremos visualizar con cualquier visor de imágenes. Esto nos permitirá determinar si el usuario en algún momento ha visto el perfil de la otra persona.

Fig. 16 Cabecera hexadecimal de los ficheros

Para terminar esta primer parte del artículo sobre Tinder, analizaremos quizás una de las carpetas más importantes de esta aplicación, la carpeta “databases” dónde se almacenan todas las bases de datos de la aplicación. Como es habitual en este tipo de aplicaciones, las bases de datos se operan en ficheros del tipo SQLite, por lo que solamente necesitaremos un visor compatible con estas bases de datos para poder leer todo su contenido. A grandes rasgos, una base de datos SQLite es como un fichero en “Excel”, contiene tablas, y cada tabla contiene: columnas y filas, cuya intersección es una celda. Comenzaremos analizando la base de datos “Tinder-1.db

En la tabla “photos_processed”, de la base de datos “legacy_tinder-1.db”, encontraremos las fotos del usuario que está utilizando en la aplicación. Si nos fijamos, la ruta de la imagen no es local, si no que apunta a una URL de Internet.

Fig. 17 Foto subida públicamente

En ese caso vemos hasta cuatro URLs distintas, esto no significa que el usuario de Tinder tengo subidas cuatro fotos de perfil, si no que es la misma imagen pero en cuatro tamaños distintos: 84×84; 172×172; 320×320 y 640×640 pixeles. Resulta curioso que podamos ver la imagen del usuario tan solo con la URL, sin necesidad de estar logados en la aplicación, ni tan siquiera es necesario tratar de ver la fotografía desde un smartphone, desde cualquier navegador la imagen es visible.

Fig. 18 DB photos

Antes de alarmarse pensado que las fotos de Tinder pueden ser tan fácilmente accesibles por un tercero, hay que tener en cuenta que la URL es lo suficientemente compleja para que no sea tarea sencilla poder hacer fuerza bruta contra las posibles combinaciones de URLs.

Existe otra tabla llamada “photos”, en esta tabla podremos encontrar la misma foto anterior, pero sin redimensionar.

Fig. 19 Foto principal del usuario

Finalmente, en la tabla “user” de la DB “legacy_tinder-1.db”, podremos encontrar los datos del usuario, datos como: fecha de nacimiento en epoch (1 de enero de 1970); distancia (en millas) que el usuario ha indicado en la aplicación para localizar a otros usuarios; género; nombre; bio; si es un superuser (ha pagado); intereses y número de teléfono, entre otros datos personales.

Fig. 20 Información de usuario

Vamos a cambiar de base de datos, ahora le toca a la DB: “tinder-3.db”, dónde podremos encontrar información diversa. Por ejemplo en la tabla “gif”, como su propio nombre indica podremos ver los gif que el usuario ha enviado.

Fig. 21 Información de los gif

No hay que olvidar que este análisis de la aplicación Tinder lo estoy realizando sobre un sistema Android, para iOS (Apple) funcionará todo igual, a excepción del nombre de las bases de datos que suelen comenzar por el carácter “Z”, como por ejemplo: ZMESSAGE; ZUSER; ZPROCESSEDPHOTO; Z_5SHAREDFRIENDS

Y ahora viene lo más importante de todo: ¡los casos de éxito!. En la tabla “match” veremos un listado con todos los match que el usuario ha conseguido, en este caso solo han sido dos (para evitar suspicacias comentar que ningún usuario real ha interactuado con el perfil simulado creado para este análisis). Gracias a esta tabla podremos determinar la fecha del match y el ID del usuario/a con la que el usuario ha logrado hacer match.

Fig. 22 Casos de éxito

Ahora que sabemos que el usuario ha logrado conseguir dos matchs, podremos ir a la tabla: “match_person” para ver la información personal de los usuarios con los que el usuario analizado ha hecho match, podremos ver: ID del usuario, nombre de usuario y fecha de nacimiento entre otros datos.

Fig. 23 Listado de matchs

Finalmente, si ha habido un match, ¿qué habrás después?, pues lógicamente una conversación. Tinder dispone de un sistema de chat integrado, el cual solamente se pude usar con los contactos con los que el usuario hubiera conseguido un match. Antes de continuar, me gustaría aclarar que los mensajes que a continuación se describen los he creado de forma artificial entre dos cuentas de Tinder controladas por mí, tampoco es cuestión de crearle exceptivas falsas a ningún usuario de esta red social hacía un usuario que en la vida real no existe. Podremos consultar todas la conversaciones del usuario con otros usuarios en la tabla “messages”. Veremos datos como las ID de los distintos usuarios, fecha de envío, el identificador del match y por supuesto, el texto del mensaje en sí.

Fig. 24 Chats

En este artículo no he hablado de todas las bases de datos, ni de todos los ficheros con los que trabaja la aplicación Tinder, simplemente he comentado los que a mi criterio me parecen más interesantes, si tienes que realizar un análisis forense sobre esta aplicación te recomiendo que no te quedes solamente en las bases de datos que he comentado y que trates de profundizar un poco más en el resto de ficheros. En la siguiente parte de este artículo seguiremos comentados otros lugares de los que poder obtener datos de interés en esta aplicación tan conocida, o no.

OK Google ¿Me estás espiando?

-OK Google, dime cual es el próximo Ave a Madrid”. Aquí estoy, en la estación de tren de Madrid-Atocha, tomando un café con leche mientras espero al tren que me llevará a casa después de una intensa semana de formación, ha sido una semana de Análisis Forense de telefonía móvil con el curso FOR-585 de SANS: “Smartphone Forensics in-depth”.

 


Fig. SANS 585 Challenge coin.

 

Como suele ocurrir en estos cursos, la carga lectiva es muy importante, pero no menos importante que las pausas para café, pausas que te permiten intercambiar opiniones, puntos de vista e ideas con otros compañeros de profesión, tanto de empresas privadas como de otras organizaciones. En uno de esos cafés, fue cuando surgió este artículo, un compañero del curso nos mostró la noticia sobre los dispositivos Alexa y de como supuestamente “Los empleados de Amazon escuchan todo lo que le decimos a Alexa y además saben dónde vivimos”, bueno, ese era el titular. Alguien que sepa un poco como funciona esto del reconocimiento de voz, ya se imaginará por “dónde irán los tiros”. No seré yo quien ponga la mano en el fuego por ninguna compañía de este tipo, pero tampoco es cuestión de vender una imagen de espionaje, desde mi punto de vista, irreal.

 


Fig. Momentos de relax.

 

¿Y cual es la realidad?, en estos tiempos vivimos en una realidad paralela, dos afirmaciones distintas pueden ser ciertas y falsas al mismo tiempo, todo depende del enfoque que le demos en la exposición. La noticia de Alexa no iba a ser menos, tampoco voy a escribir un artículo explicando lo que hace o deje de hacer esta compañía con la información que tenga que gestionar, pero la cosa es mas o menos así: básicamente los sistema de reconocmiento de voz como: Alexa, Google Home, Siri, etc… Necesitan depurar sus fallos en el reconocimiento de voz, es decir, cuando le decimos una frase al dispositivo y este no es capaz de interpretarla, ese audio se envía a un equipo concreto de personas que deben interpretarlo (mas allá de transcribir literalmente lo que el usuario dijo, tendrán que comprender lo que el usuario quiso decir) y enseñarle a la aplicación como hacerlo, así, la próxima vez que algún usuario vuelva realizar la misma petición, esta se gestionará correctamente. De este modo la aplicación sabrá interpretar lo que le están diciendo, lo que viene a ser una depuración de código de toda la vida. – ¿Y que tiene que ver Alexa con este artículo?, en realidad nada, pero así fue como surgió este articulo sobre Google Home y así os lo cuento.

 

Fig. Google Home Mini.

 

Hace ya unos meses que me compré un Google Home modelo Mini. En realidad mi intención, como es habitual, no era hacer un uso real del dispositivo, lo compré para realizar un análisis forense sobre el mismo. Estaba, estoy y estaré convencido, que este tipos de dispositivos domésticos del tipo: Internet of Things serán el futuro del análisis forense informático. Lo mismo que nos pasó con la telefonía móvil hace 10-15 años, nos pasará con el IoT, por eso, cuanto mas podamos aprender y entender como funcionan estos dispositivos a nivel forense y mas rápido seamos capaces de hacerlo, será lo que llevemos de ventaja cuando tengamos que realizar análisis exhaustivos y masivos de estos dispositivos. Ese día llegará. Seguir leyendo

Tor Forensics Advanced. Part 2

Aquí estoy de nuevo, después de un pequeño parón para poder dedicarme a otros quehaceres, vuelvo a retomar GLIDER.es justo dónde lo dejé, hablando de lo que más me gusta, de análisis forense informático, en este caso, hablando de análisis forense en TOR. En la primera parte de este artículo: “TOR Forensics I”, os contaba todos los artefactos forenses que podemos extraer del navegador Tor Browser, ya que este no es otra cosa que un Mozilla Firefox modificado. Sin embargo en esta segunda parte, un poco más avanzada y técnica, os voy a hablar en primer lugar del resto de artefactos forenses que nos podemos encontrar cuando se ejecuta el navegador Tor Browser, ya sea en un sistema Linux o Windows, artefactos como por ejemplo los ficheros de configuración de Tor, así como los vestigios que Tor puede dejar en la memoria RAM.


Fig. 1 Tor Forensics II

 

Como ya comenté muchas veces, Tor no es solo un cliente, es decir, un sistema para conectarnos a un lugar. Ese lugar al que nos conectamos también formará parte de la red TOR y de ello también os voy a hablar en este nuevo artículo, comentando toda la información forense que se puede extraer de un servidor que se ha utilizado para ofrecer un servicio a través de la red Tor.

Comenzaremos hablando por un fichero bastante importante en lo que a forense en Tor Browser se refiere, este es el fichero: “state”, el cual nos permitirá determinar los distintos bridges que el navegador Tor Browser ha usado, así como sus direcciones IP (¡OJO! Estas no son las direcciones IP públicas del usuario), de forma indirecta podremos averiguar cuando fue la última vez que se escribió este archivo, o lo que es lo mismo, la última vez que se inició Tor Browser en ese equipo, ya que para que Tor Browser puede conectarse a la red, tiene que tener actualizado este fichero.

 


Fig. 2 Actualización del fichero “state”

 

Otro dato importante del fichero “state” es la versión de Tor con la que se está operando (No confundir con la versión del navegador Web). Normalmente, podremos encontrar este fichero en la ruta de instalación de Tor Browser: “/Browser/TorBrowser/Data/Tor/state” (Linux o Windows)

 


Fig. 3 Versión Tor

 

Es importante distinguir a la hora de realizar un análisis forense sobre Tor: Tor Browser (el Mozilla Firefox modificado) de lo que es la red Tor en sí (sistema de servidores y enrutadores que nos permite acceder a los distintos nodos y servicios que nos ofrece esta red). Lógicamente, una cosa necesita de la otra, pero son independientes al a hora de realizar el análisis.

 


Fig. 4 Versión Tor Browser

 

Que en la primera parte de este artículo, hubiera nombrado una serie de bases de datos y ficheros, no significa que solo sean estos los ficheros que pueden ser interesantes a nivel forense. He reseñado los que desde mi punto de vista pudieran ser interesantes, pero para poder realizar un análisis en profundidad de este navegador es necesario realizar un trabajo pormenorizado con cada uno de los ficheros que nos podamos encontrar durante el análisis, ya que en caso de que se actualice el navegador o el sistema Tor, estos artefactos pueden modificarse y dejar de proporcionar la información que ahora nos dan, o también que simplemente pase a almacenarse en un lugar distinto al ahora explicado.

 


Fig. 5 Aviso de actualización de Tor Browser

 

Pero… – ¿Que es lo que no nos podemos olvidar de analizar en un artículo de este tipo?, eso es, – ¡La memoria RAM!. Como ya dije al principio de este artículo, TOR Browser, está pensado para enrrutar tráfico a través de la red Tor, pero no está pensado para ofrecernos anonimato mas allá de lo que es la propia red, por lo que a nivel forense, podremos aplicar técnicas usables en cualquier otro navegador, como por ejemplo el análisis de RAM. No os voy a contar como capturar la RAM de un equipo, ya que lo he explicado en otros artículos anteriores. Tampoco hablaremos de Volatility, la navaja suiza del análisis de memoria RAM, hoy vamos a ser un poco mas artesanales, tan solo utilizaremos dos herramientas para realizar este análisis de RAM, un “grep” y un “uniq” (comandos de Unix) . ¡Vamos a ello!. Seguir leyendo

TOR Forensics. Part 1

En este nuevo artículo de GLIDER.es os quiero mostrar otro punto de vista sobre TOR. Hasta ahora había hablado de TOR desde el punto de vista de la red, es decir, del enrutamiento de comunicaciones a través de la red onion. Pero hoy voy hablar sobre Tor Browser, es decir, uno de los navegadores web mas usados a la hora de acceder a la red TOR. En primer lugar es importante reseñar que no es lo mismo la red TOR, que el navegador TOR. Algunas veces escuchamos que alguien es usuario de la red TOR por usar el navegador Tor Browser, esto realmente no es así, el navegador es simplemente un medio para poder conectarnos a esta red. En realidad el navegador Tor Browser es un navegador Mozilla Firefox, modificado para que se puede conectar a la red TOR, pero por detrás prácticamente la forma de operar de un Tor Browser y un Mozilla Firefox es muy similar. De esto precisamente es de lo que voy hablar en este artículo: de un análisis forense del navegador Tor Browser para mostrar toda la información que se puede extraer de este. No hay que olvidar que la red TOR está pensada para ofrecer anonimato a sus usuarios, pero este anonimato se queda en el enrutamiento de los distintos paquetes a través de la red. A nivel local, es decir, a nivel del ordenador del usuario que se conecta a esta red, TOR no ofrece ninguna medida de anonimato, ya que realmente no está diseñado para ello, por lo que lo que voy a contar a continuación no se puede considerar una vulnerabilidad en la red TOR, ni mucho menos en el navegador Tor Browser, simplemente está diseñado así, y de eso, sea mucho o poco, nos tendremos que aprovechar para poder realizar nuestro análisis forense.

 

Fig. Tor Forensics

 

En primer lugar vamos a comenzar por el estudio del navegador Tor Browser, y toda la información que este va almacenado en sus distintas bases de datos y ficheros de configuración. Como ya dije anteriormente, si alguna vez habéis realizado un análisis forense del navegador Mozilla Firefox, os daréis cuenta que muchos de los pasos que a continuación voy a describir serán muy similares a los que ya conocéis de este otro navegador web.

Este análisis forense lo voy a realizar sobre una maquina Linux, mas concretamente sobre un Ubuntu v16 de 64bits. Aunque podréis comprobar que Tor Browser en sistemas Windows opera exactamente igual. En el caso de Windows podréis encontrar todos los ficheros “interesantes” en la ruta: “Tor Browser/Tor/TorBrowser/Data/Browser/profile.default/”, como así se puede observar en la siguiente imagen.

 


Fig. TOR Browser en Windows

 

Por el contrario, si necesitáis realizar un análisis forense de navegador Tor de un sistema Linux, tendréis que buscar estos ficheros en la ruta: “/home/user/.tor-browser_es-ES/Browser/TorBrowser/Data/Browser/profile.default”, que será el caso del análisis que ahora nos ocupa:

 


Fig.TOR Browser en Linux

 

Tor Browser, al igual que Mozilla Firefox, puede operar con un grado de “secretesimo” mayor o menor en función de la configuración que hubiera seleccionado el usuario. A continuación os muestro como sería la configuración de privacidad por defecto de un navegador Tor Browser recien instalado.

 


Fig. Configuración por defecto TOR Browser

 

Ahora nos metemos en materia y comenzamos con el análisis de las distintas bases de datos y ficheros de Tor Browser, comenzaremos, desde mi punto de vista con uno de los ficheros mas importantes que Tor Browser nos puede ofrecer a niver forense, la base de datos “places.sqlite”. Como su propio nombre indica, es una base de datos tipo SQLite, por lo que la podremos abrir si ningún problema con un visor de bases datos de este tipo.

 

Seguir leyendo

C0Nferencias

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