Cálico Electrónico: Cómo recuperar juegos en Flash como Pang Tumaka usando Ruffle

Preparar este artículo ha sido precioso. Empecé con un gran tesoro en un cofre muy pequeño en forma de una línea de código para llamar a un emulador Flash, y terminé construyendo un vídeo loquísimo. Soy María, (¡gracias dr. dr. Maligno! *reverencia* *namasté* *patada voladora*). El vídeo es un tutorial para recuperar juegos Flash, tanto para jugarlos en local como para publicarlos en Internet.

Figura 1: Cálico Electrónico - Cómo recuperar juegos en Flash como

Pang Tumaka usando Ruffle

Como ejemplo, hemos recuperado el Pang Tumaka, el minijuego original de Cálico Electrónico. Es el único que hemos encontrado. Hubo algunos más, hechos por fans y si alguien puede facilitarnos alguna copia para que los rescatemos, sería un detallazo.

Figura 2: El juego de Pang Tumaka de Cálico Electrónico

En ordenador funciona estupendamente, con teclado. Aunque puedes ver la intro también en móviles, los controles del juego en principio no te van a funcionar en el móvil, porque son de teclado (no de ratón) y eso el móvil (táctil) no lo entiende. Seguro que hay forma de apañarlo, ¿alguien se atreve?

Figura 3: Ya puedes jugar a Pang Tumaka en la web de Cálico Electrónico

Pensaba escribir este artículo como tutorial sobre cómo recuperar minijuegos Flash, que es lo mismo que os cuento en el vídeo. Pero ahora me parece más interesante hablaros del vídeo en sí. Me lo he currado yo solita, a "caraperro". 

Figura 4: El juego arranca en móviles, pero los controles no

Me ha llevado dos semanas. La única voz natural es la mía. Las demás las he clonado en ElevenLabs. La música la he generado con Suno. Las animaciones son robaditas del Canal de YouTube de Cálico Electrónico, aunque todo el timing es nuevo. Está todo editadísimo, prácticamente fotograma a fotograma.

Figura 5: Las Tiras de Cálico 3. Ya a la venta el cómic en 0xWord

Ayer añadí la intro de Sombra Oscura. Por cierto, ¿has notado ese carraspeo al principio? Es una transición que se me ocurrió entre el susto inicial, que es voz original, y el resto del discurso, que es voz clonada.

El susto inicial lo choriceé junto con la animación del último episodio de Cálico Electrónico, porque la profundidad de matices de Santi Riscos no me la da ElevenLabs ni de lejos. La tosecilla es natural también, es un free to use grabado por un chaval, lo pillé en freesound.org. Sombra Oscura dice en la intro:

«En estos días de computación cuántica e inteligencia artificial, os traemos este tributo por los viejos tiempos, cuando creábamos y compartíamos sandeces monumentales desde lo más profundo de nuestra humanidad.»

No me voy a detener a considerar la tradición del género satírico como una constante en nuestra cultura grecorromana de toda la vida de Dios, con todo lo obsceno, lo malsonante y lo escatológico desafiando las convenciones sociales y sustentando la base de la comedia más orgánica. Nada nuevo. Vamos con lo tecnológico.

Figura 6: Vídeo Tutorial de Cómo recuperar Pang Tumaka

Cuando Nikotxan y todos sus secuaces crearon Cálico Electrónico, hace 20 años, Internet iba despacico y nuestros ordenadores más. Adobe sacó un programilla llamado Flash, que era otra apuesta diferente a Photoshop, más orientado a ilustración vectorial... 

Figura 7: Contactar con Nikotxan, papá de Cálico Electrónico

Pero resultó que ¡Flash tenía TIMELINE! Lo cual nos permitía gestionar nuestros garabatos en la línea de tiempo y crear animaciones sin grandes despliegues. Hablando de timeline, esta imagen no es un diseño raro de tipografía del futuro, no... es el timeline de este vídeo tributo a Cálico, en Premiere Pro. ¡El timeline del infierno! Pues así me divierto yo, hala.

Figura 8: El timeline de este vídeo tributo a Cálico Electrónico, en Premiere Pro.  

Hoy en día tenemos muchos más medios que hace 20 años. Hay quien teme que la inteligencia artificial haga lo suyo y nos "vuele la cabeza" con sus generaditos. Y ya que estamos, le damos de comer todo lo anterior y nosotros lo olvidamos... Pero (en mi experiencia), no creo que funcione así.  Por cierto, antes de que se me pase, estamos en BlackFriday.... píllate algo de Cálico Electrónico.

Figura 9: Estamos BlackFriday en 0xWord.com

Cupón 10% descuento: BLACKFRIDAY2024

y descuentos con Tempos de MyPublicInbox

Formatos como Flash, que fue nuestro sandbox para animar y programar en ActionScript, se pueden recuperar gracias a proyectos de código abierto que dependen del trabajo desinteresado de muchísimas personas comprometidas con la conservación de nuestros bienes culturales. 

Figura 10: Camiseta de Cálico Electrónico lady fit

Esta es la magia de los emuladores, desde los mejorados Neo Geo hasta la joya de la corona ScummVM, los emuladores nos permiten revivir los patrones de pensamiento lógico que marcaron una generación. El anterior párrafo me ha quedado muy serio. Imagínatelo dicho por Sombra Oscura. No no... ¡Mejor por Chindasvinta, hermano *!

Niko miamol, si estás leyendo esto... Es triste de robar, pero más triste es de clonar.

Recursos utilizados para rescatar el Pang Tumaka:

• https://flashpointarchive.org
• https://ruffle.rs
• https://github.com/jindrapetrik/jpexs-decompiler

¡Saludos!

Autor: María Gómez Prieto

Contactar con María Gómez Prieto

¿Has encontrado Oro o Plata? El precio de los 0days en forma de Tabla Periódica

La empresa Zerodium saltó a la fama en Internet por haber ofrecido un precio de 1.000.000 USD por un 0day en Apple iOS que permitiría tomar control remotamente de un terminal iOS. La idea de ese exploit es la posible construcción de un JailbreakMe 4.0 que, como ya hiciera el investigador José Selvi con JailbreakMe 3.0, agencias de inteligencia podrían convertir en un JailOwnMe 4.0 tal y como se explica en el libro de Hacking iOS: iPhone & iPad.

Figura 1: ¿Qué 0day es Oro y cuál es plata?

Por supuesto, ya anunciaron que habían pagado ese Millón de Dólares por un exploit que cumplía las características pero que NO lo iban a publicar. Es parte de su negocio, ya que ellos luego venden este conocimiento a empresas que quieren estar más seguras que el resto. O esa es la idea.

Figura 2: El cartel con la recompensa de 1.000.000 USD inicial

Ahora, ya conocido su negocio por todos, han puesto en Internet una tabla periódica con los precios que van a pagar por exploits en los principales productos. La estrella sigue siendo Apple iOS, con pagos de hasta 500.000 USD por 0days en su plataforma, seguido por Android y Windows Phone que llegan hasta las 100.000 USD. Luego baja ya a los plugins y navegadores con Adobe PDF, Flash Player y Google Chrome llegando a los 80.000 USD. La lista es larga y deja, por ejemplo, los exploits de Windows, Mac OS X y Linux en un precio de 30.000 USD. Puedes buscar tu software favorito en ella.

Figura 3: Lista de precios por exploits y tecnologías

Una cosa interesante es que no se pagan todos los exploits y buscan exploits detallados en cada cuadrito. Por ejemplo, los RCE (Remote Code Executation) son los que se buscan en los plugins y navegadores. En los sistemas operativos de escritorio bastan con un LPE (Local Privilege Escalation) siempre que tenga un SBX (SandBox Escape) asociado, ya que con pedir la ayuda al usuario para que haga un clic en un enlace sería suficiente para conseguir el RCE final.

Figura 4: Zerodium Preguntas Frecuentes

Por supuesto en Apple iOS se busca el RJB (Remote Jailbreak) para poder tomar control total del dispositivo. Es decir, no solo ejecutar código, sino hacer la elevación de privilegios, cargarse el CodeSigning y controlar totalmente el dispositivo.Si queréis más información de qué se paga y qué no se paga, o como reportar un exploit de 0day, lo mejor es que os leáis las FAQs.

Saludos Mglignos!

Cross-Site SWF Scripting con Rosetta para Flash

Cuando un sitio web está utilizando en alguna medida Adobe Flash, está poniendo en el cliente códigos que van a ser ejecutados no directamente en el navegador de Internet, sino en un plugin que se carga en él, el famoso - muchas veces por fallos de seguridad - Adobe Flash Player. Al ser una plugin completo que ejecuta un código propio - Action Script - se comporta como un navegador de Internet dentro de un navegador de Internet y por ello debe aplicar más o menos las mismas medidas de protección que toman hoy en día los navegadores, y a veces no lo hace correctamente.

Same-Origin Policy en Adobe con CrossDomain.xml

Una de las políticas de seguridad que implementan los navegadores de Internet es el Same-Origin Policy. Esta política hace que el código que se carga en una pestaña de un navegador pueda acceder a datos solo a páginas que son del mismo dominio, es decir, que un código JavaScript no podría nunca acceder a la cookie o ningún elemento que compongan la página servida desde otro dominio. Es por ello que para poder acceder a los datos de otra pestaña se utilizan, por ejemplo, los ataques de Cross-Site Scripting, ya que consiguen inyectar código en la pestaña del dominio víctima.

En el caso de Adobe Flash y Adobe Acrobat, es el plugin es que debe forzar esa política de Same-Origin Policy y lo hace mediante la configuración de un fichero en la web de cada sitio, llamado CrossDomain.XML. Por defecto el acceso a datos desde otras ubicaciones está prohibido, pero el dueño de un sitio web puede permitir excepciones. Por ejemplo, si vamos a ver el fichero CrossDomain.XML de EBay podemos ver que hay muchas excepciones en él.

Figura 1: Fichero CrossDomain.XML en Ebay

Sin embargo, existe una forma de saltarse la protección de Same-Origin Policy en Adobe Flash Player mediante la inyección de un fichero SWF en un ataque Cross-Site Scripting o CSRF, pero para ello hay que conseguir que el fichero NO sea servido desde ninguna ubicación externa, sino que sea servido desde el mismo sitio creándolo al vuelo.

Es decir, si se inyecta un código JavaScript que carga un SWF que venga desde una ubicación de terceros, entonces se aplicará Same-Origin Policy y no se podrá hacer nada, pero el plugin de Adobe Flash Player permite que se ejecuten ficheros SWF que desde las llamadas especificadas dentro del parámetro DATA luego si se consigue que esa URL devuelva un SWF aunque sea inyectándolo en un parámetro, se ejecutar. Es decir, si un atacante es capaz de inyectar byte a byte el código de un SWF en la respuesta de una web inyectable haciendo mirroring sin que el plugin tenga que ir a una ubicación tercera, la configuración de CrossDomain.xml no afectaría para nada a este esquema.

Ataques a JASONP API

El trabajo que va a ser presentado por el investigador Michele Spagnolo se ha basado en lo explicado anteriormente, es decir, en inyectar objetos SWF maliciosos en funciones vulnerables de un dominio víctima que van a ejecutar un código Action Script que robará los datos del usuario que se conecte a ese domino víctima. Algo que podríamos decir que es un Cross-Site SWF Scripting.

Para ello ha abusado de los puntos de llamada a las APIs de JASONP vulnerables. Estas APIs de JASONP son muy comunes en los grandes sitios web de Internet ya que permiten servir y consumir WebServices con llamadas en texto plano, indicando en el parámetro Callback de la API el nombre de la función a invocar, y luego los parámetros que deben pasarse. 

Figura 2: Inyección de SWF en el parámetro callback de un API JASONP

En APIs de JASONP en las que se pueda controlar la respuesta de los datos mediante la inyección en los parámetros de llamada por CallBack, un atacante podría aprovecharse de un bug de XSS, o lo que es aún más peligroso, de un bug de CSRF en la web e inyectar en ellos un objeto SWF malicioso escrito directamente en la URL que robara  las cookies de la víctima haciendo peticiones GET y/o POST a un servidor controlado.

Rosetta Tool

En este entorno hay dos limitaciones, la primera de ellas encontrar la función del API JASONP que permite controlar la salida, y que por lo visto no ha sido un reto para Michele Spagnolo que ha visto como este ataque afectaba a Google, Ebay, Twitter, Tumblr, Instagram, etcétera, etcétera. Algunos de ellos, como Ebay o Instagram aún permanecen vulnerables.

La segunda de las limitaciones era la complejidad técnica más grande que había que saltar, y es que la API de JASONP generalmente solo permite entradas de valores en los parámetros que sean alfanuméricas, por lo que hay que conseguir que el objeto SWF que se inyecte en el parámetro esté codificado en ese formato. 

Figura 3: Concepto de Rosetta Tool

Habitualmente un fichero SWF es un archivo binario, y ahí es donde aparece Rosetta. Lo que hace esta herramienta es, a partir de cualquier objeto binario SWF genera un archivo comprimido con zlib que utiliza solo caracteres alfanuméricos, gracias a técnicas basadas en la codificación Huffman y algún ataque más. Todo esto lo explicará en su próxima charla en Hack in The Box, pero las diapositivas están ya disponibles.

Figura 4: Prueba de Concepto Universal escrita en Action Script 2 para ejecutar en la víctima

Esto permite generar ataques saltándose Same-Origin Policy, y para hacerlo más fácil ha creado una Prueba de Concepto Universal escrita en Action Script 2 que realiza la petición de los datos de entorno de una ubicación víctima a un servidor atacante. Puede ser descargada desde su repositorio en GitHUB.

Figura 5: Explotación de la POC con un Objeto Flash que debe ser cargado en el navegador de la víctima

La codificación con Rosetta del objeto malicioso es la que se ve en Data y para realizar el ataque completo hay que llamar con los parámetros URL y Exfiltrate correctos.

Mitigaciones y estado actual

Por supuesto, Adobe no tardó en proveer de una actualización de seguridad para todos los Adobe Flash Players en Windows, Linux y Mac OS X con el objeto de evitar estos ataques mediante una nueva versión que revisa con mayor fortaleza los objetos que le entran escritos en las páginas web, pero como no todos los usuarios se actualizan hay aún muchos clientes vulnerables. Algunos como Apple, ha prohibido con XCode el uso de versiones de Adobe Flash Player en Apple Safari para OS X vulnerables a esta técnica.

Por su parte, los sitos web con APIs JASONP que permiten al atacante controlar la salida de las respuestas están mirando cómo solucionar estos bugs. Algunos como Google o Twitter ya lo han solucionado, pero aún quedan muchos otros por corregir estos fallos. Tú, por si acaso, actualiza tu Adobe Flash Player ahora mismo.

Saludos Malignos!

Más de 161 millones de identidades pwneadas en Internet

En muchas conferencias de las que he dado últimamente he hablado del sitio Have I been Pwned? que se dedica a recoger bases de datos de identidades expuestas en Internet tras el hackeo de sitios de renombre. En este sitio se encuentra, por ejemplo, la base de datos de Adobe con 152 millones de identidades, que es la más llamativa, pero también hay otras como una de Vodafone con algo más de 52 mil cuentas expuestas, la de Snapchat con más de 4 millones de identidades, la base de datos de Forrester y Gawker con algo más de 1 millón de cuentas cada una, etcétera.

Figura 1: Bases de Datos consolidadas en Have I been Pwned?

Al final, la lista alcanza los más de 161 millones de identidades en Internet, por lo que si alguien ha tenido la brillante idea de utilizar una cuenta de otro sitio para registrarse en los servicios hackeados y usar una contraseña repetida, entonces sus cuentas están en serio riesgo.

Figura 2: Cómo conquistar el mundo gracias al password reuse por XKCD

El servicio en cuestión de Have I been Pwned? permite realizar búsquedas de cuentas de correo electrónico en esa base de datos, para ver si alguna cuenta de correo electrónico ha aparecido en alguna de ellas. Yo he buscado por ejemplo admin@forbes.com y puedes ver que aparece expuesta en el incidente de hackeo de Forbes, lo que es hasta normal.

Figura 3: La identidad de admin@forbes.com aparece en la base de datos de Forbes

Lo que no es tan normal es que ma haya salido como resultado que la cuenta admin@sony.com no aparezca en la base de datos del hackeo Sony y sí por el contrario en la base de datos del hackeo de Adobe, como es el caso.

Figura 4: La cuenta de correo de admin@sony.com apareció en la base de datos de Adobe

Que el administrador de Sony ha utilizado su cuenta de correo para registrarse en Adobe es una mala idea, pero esperemos que al menos no haga reutilización de passwords ni tenga algún método de construcción de contraseñas similares al de Dan Kaminsky en su famoso pwnage... o que al menos use Latch }:)

Saludos Malignos!

Cuando hackean una base de datos te hackean a ti también

Muchas veces la gente que no trabaja en seguridad me pregunta porque esa obsesión mía de estar conectado todo el tiempo y alerta de lo que está pasando, actualizando el buzón de  correo electrónico cada poco tiempo y leyendo lista infinitas de noticias en RSS que vuelven a crecer cada semana con nuevos focos de información que ofrecen nuevos datos de interés.

La respuesta no es demasiado fácil de explicar a la gente que no trabaja en este area profesional, y a sus ojos acabamos pareciendo adictos a Internet, pero lo cierto es que tiene su explicación, ya que lo que sucede en Internet te puede afectar a ti también de forma directa, especialmente cuando hay un hackeo de un sitio y se publican bases de datos de usuarios y contraseñas.

El caso de las contraseñas de Adobe

Con la liberación de las contraseñas de la base de datos de usuarios de Abode, el mundo de la seguridad en la empresa está revuelto. Por supuesto, lo primero de todo ha sido comidilla que supone que una empresa como Adobe sufra una intrusión de esta índole, dejando claro que los algoritmos de almacenamiento de passwords no eran los más adecuados para garantizar una buena estrategia de Defensa en Profundidad que debería haber terminado con "Si acceden a los hashes que no las pueda crackear fácilmente".

Figura 1: Tira de XKCD sobre cómo usar las pistas de las passwords para hacer un juego de palabras cruzadas

Esto ha llevado al cachondeo en XKCD que decía que sería divertida una implementación de un juego de palabras cruzadas usando las pistas que los propios dueños de las credenciales han dejado junto a sus hashes, y ha terminado convirtiéndose en un juego real en Internet.

El análisis de los datos filtrados

Pero lo más importante no es la comidilla que pueda generarse alrededor de un determinado incidente de seguridad, sino lo que todos los equipos de seguridad de todas las empresas han tenido que hacer para contener el impacto de esta intrusión dentro de sus propios sistemas. Aquí es donde los equipos CERT de cada una de las organizaciones deben comenzar a trabajar, para saber cuánto les puede afectar este fallo de "otros".

Figura 2: Cuentas con dominios del IBEX 35 en la base de datos filtrada de Adobe

En Security By Default se alertaba de la cantidad de direcciones de correo corporativas utilizadas para la generación de cuentas de servicio en Adobe, lo que podría llevar, por una mala gestión de sus propias contraseñas, a que un usuario hubiera utilizado la misma password en Adobe que la que utiliza en su compañía.

Si el usuario de nuestra organización hubiera sido lo suficiente descuidado como para utilizar la misma contraseña en ese servicio de Internet para el que le han robado la password que en el sistema de la empresa, entonces tendríamos un problema. Por desgracia, la reutilización de passwords es un mal endémico demasiado difícil de erradicar, tratado también hace tiempo por xkcd.

Los datos de malware y botnets exfiltradas

Los equipos de seguridad de una empresa, cuentan con las políticas de contraseñas, que obligan a no repetir contraseñas, a cumplir grados de complejidad y a cambiarlas periódicamente, así, aunque un usuario repita una contraseña en un servicio perdido de Internet, las probabilidades de que sea la misma que la que se usa en la empresa son menores.

Figura 3: Datos de cuentas filtrados de una botnet con HCStealer

Esto mismo sucede cuando en algún almacén de un malware o una botnet de los amigos del Fraude Online aparecen datos de de cuentas de usuarios de cualquier servicio de Internet con direcciones de correo electrónico pertenecientes a dominios de una empresa. Solo hay que buscar un poco siguiendo las indicaciones que aparecen en el artículo de Enrique Rando para acabar dando con cuentas corporativas junto con la contraseña de algún servicio en Internet que ha acabado siendo robado por cualquier malware.

Imagen corporativa

Aunque se pueda mitigar el impacto de la re-utilización de contraseñas, sigue siendo malo para la compañía la fuga de nombres de direcciones de correo en servicios de Internet no es una buena cosa, por lo que es necesario contar con servicios de ciberseguridad que vigilen el mundo sin fin en que se ha convertido nuestro CPD.

Además de contratar esos servicios, una de las buenas prácticas es la de prohibir por política de uso la dirección de correo electrónico para darse de alta en servicios de Internet. En muchos servicios es posible conocer qué cuentas se han utilizado para registrar servicios por medio de pequeñas fugas de información en los procesos de alta de cuenta, de login o recuperación de contraseñas.

Esto hace que como medida de seguridad los servicios de ciberseguridad o las mismas empresas puedan monitorizar determinadas cuentas de correo electrónico para saber si están cumpliendo o no las políticas de seguridad corporativas.

Protección Personal

El que no se deban utilizar las cuentas de correo electrónico de la empresa para darse de alta en servicios de Internet de uso personal es algo que no deberían prohibir tan siquiera, ya que es de sentido común. Hay que tener en cuenta que una vez que la cuenta de correo ya no sea del empleado la empresa podrá recuperar todas los servicios asociados a ella.

Para uso en servicios al margen de la empresa, lo recomendable para una persona es utilizar una cuenta de correo electrónico de registro de servicios, pero que nunca sea la cuenta de correo que actúa como piedra de clave, para que nunca caiga esa cuenta cuando salgan los logins de cualquier base de datos de usuarios y contraseñas hackeada.

Tampoco deberían utilizarse cuentas de correo corporativas asociadas a personas concretas para darse de alta en servicios, sino que deberían utilizarse cuentas especiales de registro en servicios que además estuvieran inventariadas y controladas, ya que deben perdurar - o no - más allá que la vida profesional de un determinado empleado.

En definitiva, piénsate muy mucho qué identidad vas a dar de alta en un servicio en Internet antes de hacerlo, que si lo haces muy a la ligera puedes estar poniendo en riesgo a tu empresa o a ti mismo.

Saludos Malignos!

Análisis de metadatos en la contabilidad filtrada del PP

Antes de comenzar a leer este artículo, quiero dejar claro que esto no es más que un ejercicio técnico de revisión de documentos, y que un informe pericial podría sacar mucha más información. Es cierto que con tal cantidad de documentos filtrados, era imposible no pensar en analizar los metadatos de todos ellos para ver qué se podía extraer en global de todos ellos, pero desconocemos si fue la misma persona la que los escaneó, los empaquetó en ficheros .ZIP y la que los filtró en Internet. Vamos a hacer un pequeño análisis forense digital, a ver qué sale.

Figura 1: Vídeo-Tutorial de Forensic FOCA

Para este ejercicio que formará parte de los ejemplos ejemplares de análisis forense de metadatos supondremos que todas son personas distintas - hasta que se demuestre lo contrario - y solo se hace un ejercicio de análisis de metadatos para ver qué sale. Por supuesto, para hacer esta tarea de análisis de más de 5GB de datos nada mejor que Forensic FOCA que para esto se creó.

Los ficheros comprimidos

Los documentos se publicaron en ficheros .ZIP comprimidos, en los que aparecían archivos de miniaturas Thumbs.db, lo que podría significar que se habían creado con un Windows XP o anteriores. En el último de ellos, relativo a la contabilidad de 2011 aparecía sin embargo, entre la compleja estructura de carpetas, un fichero .DS_Store, típico de sistemas operativos Mac OS X, lo que parece que se podría haber hecho desde varios ordenadores el empaquetado de los documentos. Así que hemos de suponer que la persona que los empaquetó, o era una con dos equipos distintos, o fueron dos personas distintas.

Figura 2: Thumbs.db en ZIP de año 1999

Los ficheros descomprimidos

Si se descomprimen los ficheros, aparecen más de 400 documentos en formato PDF. Todos ellos son copias escaneadas de documentos originales, pero tenemos la ventaja de que no han sido limpiados de metadatos, por lo que se puede extraer mucha información de ellos. Para analizarlos con Forensic FOCA se extraen todos y se arrastran a la herramienta. El resto se hace solo.

Figura 3: Lista de documentos publicados

Que aparezcan los ficheros comprimidos con archivos de miniaturas y los documentos PDF con metadatos podrían hacernos pensar que la persona que filtró los documentos en Internet o no es la misma que los escaneó y comprimió - y por tanto no le importa la info que de ahí se pueda extraer - o no tiene un perfil técnico alto, lo que haría pensar más en una filtración de alguien con acceso a los documentos en lugar de un ataque hacktivista.

Las rutas a carpetas

Si miramos al estructura de carpetas que aparecen, es curioso ver unidades como m: o t:, lo que significa que se está utilizando algún tipo de sistema de almacenamiento en red NAS para guardar todos los documentos mientras se escanean. Si hubiera que especular sobre el sistema, parece un scaner/digitalizados/multifunción que come documentos y genera los PDF, pero hay cosas que generan diferencias más adelante.

Figura 4: Rutas a carpetas encontradas en los documentos PDF

El software utilizado

Esta información sí que es relevante, pues además de software muy común como Adobe Acrobat o Adobe Distiler, aparecen versiones de software muy concretas, como EFI Cyclone o Developer Express Inc.

Figura 5: Software de creación de documentos PDF encontrado

La primera de ellas es especialmente llamativa, pues es software de impresión profesional que se usa en impresoras de gama alta utilizadas en centros de reprografía de documentos. La lista de equipos que incorporan estas librerías de EFI puede consultarse en la web del fabricante. Nitro PDF Professional tampoco es un software demasiado común, y la versión 6 es bastante antigua.

Las fechas de creación de los documentos

Tras analizar cuándo se crearon y modificaron los documentos, puede verse como se crean y modifican los ficheros PDF. Esto es algo típico de documentos creados página a página, es decir, se digitaliza la página 1 y se crea el documento, luego se digitaliza la página 2, y se modifica el documento PDF anterior.

Figura 6: Sección de fechas de creación y modificación de documentos

Las fechas de creación de estos documentos digitalizados comienzan a hacerse en serie a partir del 8 de Febrero de 2013 en adelante, lo que parece que se hizo a conciencia, ya que hay miles de páginas entre todos los documentos.

Figura 7: Algunos documentos creados el 7 y 8 de Julio

Los usuarios

No aparecen usuarios en casi ningún documento, pero hay 4 de ellos en los que sí. En uno de ellos aparece un genérico Administrador, pero en otros tres documentos aparece el nombre de un usuario MAGomezc.

Figura 8: Usuarios encontrados en documentos PDF

Este nombre, que parece algo similar a Miguel Ángel Gómez C., Marco Antonio Garmendia Crespo o cualquiera de ese estilo, aparece en tres documentos digitalizados en el año 2008, es decir, hace 5 años, pero que podría indicar a una persona concreta.

Figura 9: Un documento digitalizado por MAgomezc en el año 2008

Por supuesto, este metadato sólo dice que se escaneo desde un equipo en el año 2008 en el que el usuario que estaba trabajando con ese Adobe Acrobat PDF Maker 7.0 era MAgomezc.

Al final, serán los investigadores de este caso los que tendrán que casar software con equipos personales de personas o tiendas, modelos de impresoras/digitalizadoras con dueñas, y nombres de usuarios con personas, pero esa ya es labor policial y queda lejos de nuestro objetivo por ahora.

Saludos Malignos!

Tapa la webcam o ponte sexy si usas Adobe Flash Player

Conozco desde hace tiempo el bug de Adobe Flash Player que por medio de un ataque de ClickJacking permitía activar la webcam y grabar al usuario que visita una web con robar solo unos clics para utilizar el configurador de la webcam en el sitio de Adobe. Este bug lo suponía solucionado desde el 2011, pero lo cierto es el descubridor del mismo ha vuelto a alertar de que aún no lo está.

Figura 1: PoC publicada en 2011

Yo he ido a probar la PoC que te tira una foto con un clickjacking de chicas sexies usando un OS X Mountain Lion 10.8.4, Google Chrome 27 y la última versión de Adobe Flash Player... y no lo está. Eso sí, al menos me ha salido la lucecita en el MacBook Pro para que me diera tiempo a sonreir, aunque no me he animado a ello como podéis ver.

Figura 2: Cara con la que he salido cuando he probado la PoC

Dos años parece más que suficiente para que Adobe se hubiera tomado esto más en serio, pero no ha sido así, por lo que se lo pueden estar pasando genial los malos gracias a la colaboración de Google Chrome. Un negativo para el equipo de seguridad de Adobe. Sea cual sea tu versión de Adobe Flash Player estás vulnerable, así que ya sabes lo que debes hacer: Tapa la webcam o ponte sexy para salir en Internet. 

Saludos Malignos!

Decompilador Flash, Java, .NET y QR Codes Online

En el artículo de sacar URLs de un sitio web os hablaba de la necesidad de decompilar los ficheros SWF y Java para poder sacar más información de ficheros de un sitio web. Para hacer esta tarea el servicio online Show My Code te lo pone bastante fácil, ya que solo tienes que decirle la URL del fichero que quieras decompilar y un sencillo captcha de una única letra, con lo que es rápido y cómodo analizar ficheros.

Figura 1: Show My Code

En este ejemplo he buscado un SWF de Apple.com, y como veis es posible acceder a las URLs que está utilizando para manejar, por ejemplo en este caso, la tienda de música de Apple iTunes.

Figura 2: Código de un SWF en Apple.com

El sitio es muy cómodo, y además de mostrar el código rápidamente, también permite descargarlo para poder hacer búsquedas de cadenas que sean de interés - cada uno sabrá qué es lo que busca -. Eso sí, no te devuelve el FLA, por lo que los archivos embebidos o el resto de información del SWF se queda fuera y necesitarías otro tipo de herramientas.

Figura 3: URLs de iTunes para conseguir el Top de Albumes

Si quieres perder un poco el tiempo rebuscado en los SWF, podrás encontrar un montón de información de rutas, usuarios y passwords embebidos, links a archivos locales, rutas a ficheros almacenados en perfiles locales, etcétera.

Saludos Malignos!

Dmitry Sklyravov y su detención tras hablar en DEFCON 9

Hace poco os conté la historia de Michael Lynn y el CISCOGate que acabó con la censura de la documentación en BlackHat, y hoy os quiero contar otro suceso que bien podría haber sido otra microhistoria y que es de tintes similares a la anterior, pero con otro ponente. En este caso tuvo lugar en las conferncias DEFCON. Pero dejadme que os lo cuente tal y como yo me enteré de todos los acontecimientos que os voy a narrar.

La historia comienza con la primera vez que visité las conferencias Troopers en el año 2010, donde acabé sentado en la cena al lado de un ponente de origen ruso que se presentó como Dmitry. No conocía su historia previamente, pero a lo largo de la cena y la sobremesa, a la que asistían en la misma mesa Steve Dispensa y Marsh Ray que explicarían su TLS-Renegotiation bug, me enteré de todos los problemas legales que tuvo tras pasar por DEFCON 9. 

Para aquel año de conferencias, Dmitry Sklyravov, de ElcomSoft, impartió una charla en la DEFCON que tuvo lugar el 16 de Julio de 2001 sobre básicamente cómo quitar el DRM de los e-books comprados en formato PDF, en una charla que se tituló "ebook security - theory and practice" y en la que se presentaba una herramienta llamada Advanced E-Book Processor que puede ser localizada aún en Internet.

Figura 1: Dmitry Sklyravov

Todo parecía normal, hasta que intentó salir de USA de camino a Rusia el 19 de Julio de 2001, donde fue detenido y puesto en prisión por haber violado la DMCA (Digital Millenium Copyright Act) algo que apoyó la Association of American Publishers. Por supuesto se armó una buena, y hubo manifestación hasta en la puerta de Adobe pidiendo la liberación de Dmitry. Este vídeo muestra en un pequeño reportaje estos momentos.

Dmitry fue liberado tras pagar una fianza de 50.000 USD el 6 de Agosto de 2001, pero no pudo abandonar los USA hasta Diciembre de 2001. El juicio no se realizó hasta Diciembre de 2002, donde fue declarado "No Culpable" pero la historia estuvo coleando hasta el 2008 y puedes ver todos los documentos del caso en la EFF. La secuencia de los acontecimientos está recogida en el artículo de este caso en la Wikipedia.

A día de hoy Dmitry es un reputado speaker en todas las conferencias de hacking del mundo, aunque no en las que se realizan en USA. El caso ya está cerrado, pero jamás olvidará este episodio que le llevó a pasar por la cárcel, pasar 6 meses retenido en USA y andar con problemas legales durante años. Este próximo mes de marzo tendré la suerte de volverle a ver en acción, que además habla justo detrás de mí en la agenda de la Troopers 13.

Saludos Malignos!

Certificado Digital de Adobe comprometido ha sido utilizado para firmar herramientas de hacking: ¡A revocar!

A través de un post titulado "Inappropriate Use of Adobe Code Signing Certificate" - Uso inapropiado de certificado de firma de código de Adobe - la compañía ha alertado a los usuarios de la necesidad de actualizar sus productos ante una inminente revocación del certificado digital con el que algunos de ellos se encuentran firmados, ya que ha sido comprometida su seguridad y a principios de Octubre dejará de tener validez.

El incidente parece que tuvo lugar al quedar comprometido un servidor de compilación a finales de Julio, en el que se encontraba el certificado digital para firmar el código. Dicho certificado fue utilizado para firmar la popular herramienta PwDump7 - junto con la librería libeay32.dll de OpenSSL - que se utiliza para volcar las contraseñas de sistemas Microsoft Windows desde el LSA, y myGeeksmail.dll que es un filtro ISAPI que puede instalarse en servidores web para interceptar y manipular las conexiones HTTP lo que permitiría a un atacante acceder a toda la información que por ese servidor web pase y modificarla a gusto.

Los detalles y hashes MD5 de los ficheros firmados han sido publicados en un Security Advisory desde Adobe APSA 12-01 y son los siguientes:

PwDump7.exe
MD5 hash: 130F7543D2360C40F8703D3898AFAC22
Tamaño: 81.6 KB (83,648 bytes)
Signature timestamp: Thursday, July 26, 2012 8:44:40 PM PDT (GMT -7:00)
MD5 hash del fichero sin firma: D1337B9E8BAC0EE285492B89F895CADB

libeay32.dll
MD5 hash: 095AB1CCC827BE2F38620256A620F7A4
Tamaño: 999 KB (1,023,168 bytes)
Signature timestamp: Thursday, July 26, 2012 8:44:13 PM PDT (GMT -7:00)
MD5 hash del fichero sin firma: A7EFD09E5B963AF88CE2FC5B8EB7127C

myGeeksmail.dll
MD5 hash: 46DB73375F05F09AC78EC3D940F3E61A
Tamaño: 80.6 KB (82,624 bytes)
Signature timestamp: Wednesday, July 25, 2012 8:48:59 PM (GMT -7:00)
MD5 hash del fichero sin firma: 8EA2420013090077EA875B97D7D1FF07

Según cuentan, a Adobe llego una copia de estos ficheros el 12 de Septiembre desde una fuente anónima, y desde entonces han trabajado en firmar el software con otros certificados digitales y poner actualizaciones de sus programas afectados disponibles, además de informar al Microsoft Active Protection Program y fabricantes de soluciones de seguridad para que detecten estos ficheros como maliciosos.

El tener las herramientas de hacking firmadas con un certificado de firma de código de Adobe es casi un salvoconducto contra cualquier antimalware, ya que estos cuentan con medidas especiales para no detectar como malware software firmado por entidades certificadoras de confianza, lo que hace que muchos de ellos ni los analicen. El contar con una firma de confianza hace que estas herramientas no levanten ninguna sospecha en los motores antimalware que quieren evitar casos como el de McAffe que "decidió" firmar como malware a Excel - y 7 páginas más de falsos positivos - o el reciente caso de Shopos que se detectaba a sí mismo como malware.

Por supuesto, estas herramientas son de post-explotación, y si alguien se ha tomado la molestia de firmarlas digitalmente mediante el robo de certificados a Adobe es debido a que se estaba preparando, o se hizo, un ataque dirigido y no un hacking masivo, aunque parece que han durado muy poco tiempo sin ser detectado.

La lista de software de Adobe que tiene que ser actualizado ahora - debido a que había sido firmado por este certificado - está publicada en la web de Adobe, así que si tienes este software desplegado en tu empresa atento a las actualizaciones, que cuando esté revocado digitalmente el certificado los usuarios empezarán a ver alertas "raras" en la ejecución.

Casos como este, que se suma al incidente de Comodo o de Diginotar - que Apple tardó un mes en revocar en iPhone & iPad - , al del malware firmado con un certificado de desarrollador de Microsoft y distribuido por Windows Update, o el más impactante ataque criptográfico a los certificados digitales de Microsoft en el caso de Flame, hacen que confiar en la firma digital de un software o una conexión sea confiable ... solo en un porcentaje del total de los casos.

Saludos Malignos!