RootedCON 2014: Charlas en vídeo publicadas

Desde RootedCON están haciendo un trabajo de recuperación de todas las charlas que tuvieron lugar este año. El montaje es verdaderamente bueno y puedes disfrutarlas una tras otra aprendiendo un montón de cosas. Estas son las charlas, entre las que está la mía y la de muchos compañeros y amigos.

Figura 1: Pablo González y Juan Antonio Calles - Cyberwar: Looking for... Touchdown!
    Figura 2: Fran y Charlie hablan de Sinfonier

Figura 3: Alfonso Muñoz habla de Esteganografía y en texto natural

Figura 4: José Luis Verdeguer (autor del libro hacking VoiP) y Víctor Seva - Secure Communications
  Figura 5: Jorge Ramió (Autor del libro de Criptografía RSA) habla de los 36 años de RSA
Figura 6: Chema Alonso - Playing & Hacking with Digital Latches

Figura 7: Andrés Tarasco - Ataques dirigidos con APTs WiFi

Figura 8: Miguel Tarasco - Análisis WiFi de forma nativa en Windows


Figura 9: Jorge Bermudez - Los hackers son de Marte los jueces son de Venus

Figura 10: Antonio Ramos - Agilidad: La via a la seguridad

Figura 11: Alberto Cita - Skype sin Levita: Un análisis de seguridad

Figura 12: César Lorenzana y Javier Rodriguez - Por qué los llaman APT's
Figura 13: Bypassing wifi pay-walls with Android

Figura 14: Raúl Siles - iOS: Regreso al futuro

Figura 15: José Luis Quintero & Felix Estrada - De Juegos de Guerra a La Jungla de Cristal 4

Figura 16: Raj Shah - The Kill Chain: A day in the life of an APT 
Figura 17: Borja Berástegui  - Handware Hacking

Figura 18: Roberto Baratta - Monetizando la seguridad: De más a menos con nada

Figura 19: Pablo San Emeterio y Jamie Sánchez: WhatsApp, Mentiras y Cintas de Vídeo

Figura 20: Hugo Teso - Profundizando en la seguridad de la aviación

Figura 21: Joaquín Moreno Garijo - Forense a OS X a bajo nivel

Aún no están publicadas todas las charlas que formaron parte de RootedCON 2014, pero según las vayan publicano iré actualizando este post para que las tengáis todas. No obstante, si queréis ver las de 2013 y las que se vayan publicando, podéis suscribiros al Canal Youtube de RootedCON Madrid que tienen abierto. Saludos Malignos!

Cálico Electrónico 5x05: "Las Tortugas Pijas" y más stuff

El próximo día 5 de Julio saldrá publicado el nuevo capítulo de Cálico Electrónico. En esta ocasión el Capítulo 5 de la Temporada 5, titulado "Las Tortugas Pijas", en el que han colaborado grandes como Escardi, Baxa, El Tito Bertín, Dani Lagi o Narehop. Todos ellos son los simpáticos animalicos de color verde que podéis ver ya en el avance del capítulo.

Figura 1: Avance del Capítulo "Las Tortugas Pijas

El capítulo será pre-estrenado el día 4 de Julio en la HobbyCON, donde La tienda Oficial Cálico Electrónico y el creador Nikotxan estarán ese fin de semana, así que si estás por allí, puedes verlo antes que los demás.

Mientras tanto, durante este periodo hemos recuperado más material. La primera ha sido la tira 109 de Deili Electrónico, que es una colaboración para el cómic de Andrea Down "Helado de Huevos Fritos". Un cómic en el que la protagonista ve el mundo de esa forma tan especial que lo ve la gente con síndrome de Down.

Figura 2: Tira de Cálico Electrónico 109 para el cómic "Andrea Down"

Además, hemos ido recuperando algunos vídeos perdidos de Cálico Electrónico. En este caso algunas promos de sorteos curiosas, como esta en el que el Chacho Migué le enseña al Minitun lo que es una navajilla para un gitano.

Figura 3: El chacho Miguel le enseña a MiniTun lo que es una navajilla

Recuerda que todos los vídeos de todas las series están disponibles en el Canal de Cálico Electrónico en Youtube oficial y para que te puedas enterar de todo esto con facilidad, recuerda que tienes una aplicación de Cálico Electrónico para Windows Phone, otra app de Cálico para Android, una aplicación para Windows 8, y una versión para iOS (iPhone & iPad) que podrás descargar desde iTunes. Si te quieres enterar de todas las novedades ya sabes que también puedes seguir la actividad del gordito en su cuenta oficial Twitter, en su página fan de Facebook, a través de Google+ o suscribirte al Canal Oficial Youtube Cálico Electrónico. 

Saludos Malignos!

375.000 WordPress en riesgo por un exploit de Command Injection para el plugin TimThumb

Se ha publicado un 0day para un plugin muy popular de WordPress que permite la inyección de comandos en el sistema operativo. El plugin, TimThumb, permite hacer redimensión de imágenes en el popular framework, y a día de hoy, buscando el fichero PHP del plugin, pueden verse 375.000 referencias en Internet.

Figura 1: Número de sitios con el plugin TimThumb instalado

La ejecución de la inyección de comandos es muy sencilla, y ya se está explotando de forma activa, así que si tienes un WordPress con este plugin debes actualizarlo inmediatamente para no tener problemas. La explotación es bastante sencilla.

Figura 2: El exploit de Command Injection del plugin vulnerable

Por ejemplo, para poder borrar un fichero del servidor, por ejemplo un .htaccess si hubieran los permisos adecuados se puede hacer de la siguiente forma:

http://WordpressVulnerable.com/wp-content/plugins/pluginX/timthumb.php?webshot=1&src=http://WordpressVulnerable.com/$(rm$IFS/dir/.htaccess)

Y para crear un archivo, sería de la siguiente forma:

http://WordpressVulnerable.com/wp-content/plugins/pluginX/timthumb.php??webshot=1&src=http://WordpressVulnerable.com/$(touch$IFS/dir/file.php)

Con esta vulnerabilidad, descrita en este advisory, se pueden crear Web Shells en los servidores no actualizados, y por supuesto el mundo del fraude online o los amigos del Black SEO lo utilizarán inmediatamente, así que actualiza cuanto antes tu sitio y toma todas las medidas que puedas para fortificar tu WordPress.

Saludos Malignos!

Hay que acabar con las passwords complejas en servicios online

Como muchos de vosotros, he intentado poner contraseñas más o menos complejas a todas mis cosas. Desde volumenes cifrados, arranque de BIOS, documentos, arranque de sistemas operativos o servicios online. Passwords que a veces me cabrean porque me cuesta tres intentos ponerlas bien. Pero sigo con mis passwords complejas, al igual que siempre he recomendado a todo el mundo que ponga claves complejas en su vida digital e incluso he dejado artículos por aquí para la generación de claves robustas - que son necesarias para muchas cosas.

Figura 1: my_p@sSw0RD!

Esta bien, pero ni mucho menos sirve para sentirse seguro. De hecho, el pensamiento que ronda mi cabeza desde unos meses acá es que en los servicios online, las contraseñas complejas no deberían existir. Deberían ser todas contraseñas sencillas para que el usuario estuviera feliz y contento. Algo como el movimiento de Facebook de permitir 3 passwords distintas para hacer la vida del usuario más sencilla. Y dejadme que os explique por qué pienso así.

¿Para que sirve una password compleja en un servicio online?

Vamos a suponer un servicio online en el que heme de registrar para hacer algo. Supongamos que es un e-commerce, una nueva red social o simplemente un juego online, donde usamos una contraseña que protege nuestra cuenta ante posibles ladrones de identidad que se lleven el servicio y los datos que contiene por delante.

En todos esos esquemas, si el servidor ha hecho los deberes la contraseña compleja no nos defiende de nada (o casi nada) que no haga una contraseña sencilla como una cadena de letras y números de 8 caracteres. Estos son los deberes que el servidor podría hacer:

Deber número 1 - Permitir que se añada un segundo factor de autenticación

Si el servicio online permite poner un segundo factor de autenticación para proteger la cuenta, como Google Authenticator, un envío de SMS o el uso de Latch. Si alguien consigue la password (sencilla o compleja) no podrá usarla nunca.

Deber número 2 - Controlar el número de intentos de contraseña fallidos a una cuenta:

El servidor debe evitar que se realicen intentos al infinito de contraseñas a una cuenta - aquí un ejemplo para fortificar WordPress frente ataques de fuerza bruta -. Evitando la fuerza bruta online - con desactivaciones parciales, añadir una segunda verificación a la cuenta, bloqueo de direcciones IP temporales, etcétera, el ataque a una password de 8 caracteres o a una password compleja - aunque no sea igual de difícil en la teoría, será igual de difícil en la práctica, ya que sortear todas las barreras será un problema exactamente igual para ambas contraseñas. El resto solo "is a matter of time".

Deber número 3 - Controlar el número de intentos a nombres de usuario con misma contraseña

Al igual que se debe tener en cuenta que se debe controlar cuando se hace un ataque de fuerza bruta - o diccionario - a una contraseña, hay que tener en cuenta que el ataque se puede hacer al nombre de usuario fijando una contraseña.  Este ataque os lo expliqué en el artículo de "tus passwords son suprayectivas".  En ese caso, igual que se fija una contraseña sencilla, se puede fijar una contraseña que cumpla la política de complejidad y sea común siguiendo la política de de complejidad del sitio web. Es fácil.

Deber número 4 - Almacenar de forma segura las passwords

Utilizando un algoritmo de cifrado de contraseñas seguro, con su salt o con algoritmos criptográficos que hagan complejo - al menos durante un tiempo prudencial su crackeo -. ¿Por qué esto? Pues porque para que alguien se haga con las passwords debe hackear el servicio online completamente - algo que debe evitar el sitio  con auditoría continúa. Al final esto puede fallar, como hemos visto, hasta en sitios como eBay.

En segundo lugar, si me obliga el sitio online a poner una password compleja que me está jodiendo la vida y luego resulta que la almacena en BASE64 o en texto claro o en MD5 sin salt, merece un castigo ejemplar. Al final, con que el tiempo que aguante el algoritmo sea el suficiente para que el servio me avise de que le han hackeado y me de tiempo a cambiarla, me valdrá.

Deber número 5 - Cifrado seguro end-to-end

Poniendo un conexión con Certificate Pinning desde las apps y de HTTPs con validación extendida, sin mezclar contenido HTTP y HTTPs y añadiendo los flags Secure a todas las cookies con una gestión segura de las. Así, tendré las medidas necesarias para saber que estoy en una conexión cifrada de forma segura o no.

¿Y el resto de ataques?

El resto de los problemas que voy a tener con mi identidad recaen en mi lado. Si la password la publico en un post-it o en una captura de una foto es mi problema. Si me como un troyano en mi equipo o usa la password en un equipo que no es mío controlado es cosa mía. Si me como un ataque de red con un man in the middle en IPv4 o IPv6 porque no he visto las alertas de seguridad es mi problema. Y en todos estos casos, el problema será igual para contraseñas sencillas y contraseñas complejas.

En todos ellos, al final, si el sitio me permite poner un segundo factor de autenticación si alguien me roba la password recibiré la alerta de que algo va mal. Al menos en soluciones como Latch - donde te llegará la alerta - o vía SMS donde te llegará un código que te indicará que alguien ha iniciado sesión, que en soluciones como Google Authenticator no se recibe ninguna alerta de seguridad cuando alguien ha usado la password correctamente.

Es más, si mi cuenta tiene un 2FA, creo que el servicio online debería premiarme y dejarme poner contraseñas sencillas y dejar las contraseñas complejas solo para aquellos usuarios que no hayan puesto el 2FA. Una PIN de 4 números y un Latch es mucho más seguro para tu cuenta online que una password compleja y hace mucho más fácil la vida del usuario.

Saludos Malignos!

El Security Center del Mundial publica la clave de su WiFi

Lo de hacerse fotos y que en el fondo se vaya algo que no debería haberse visto es muy común. Hace poco se lío cuando Tim Cook - el chairman de Apple - se fue a visitar la fábrica en USA donde se montan los MacBook Pro, y en el fondo se veía que usaban Windows para hacerlos - eso sí, con mucho estilo corriendo en un iMac como los puntos de Internet que hay por ahí. -.

Figura 1: Lo que se ve es un Windows corriendo en un iMac

Yo mismo, cuando me pasan las capturas para poner en los artículos que publico por este blog que no son míos, reviso que no se escape nada que no deba verse. Reviso los títulos de las ventanas, los valores hexadecimales o los códigos en Base64 que puedan ser decodificados, etcétera, y aún así se me escapa alguno de vez en cuando.

Que esto le pase a Sara Carbonero con las passwords de la WiFi que iban a utilizar en el mundial de fútbol el equipo de reporteros, es gracioso y hasta enternecedor. Al fin y al cabo, en el mundo de la tecnología se puede permitir ser un poco más Penny que en el mundo del periodismo, donde ejerce su profesión de verdad.

Figura 2: Las redes WiFi y las passwords. Me encanta la de "iniestademivida"

Lo que ya es curioso es que al Centro de Seguridad encargado de velar por la seguridad del Mundial de Fútbol de Brasil, se le escape una foto con la contraseña bien gordo en el fondo. Vamos, supongo que ya la habrán cambiado, pero ellos seguro que deberían conocer los riegos de seguridad de que alguien con malas intenciones se pueda colar en tu red WiFi.

Figura 3: Posando con las banderitas, el SSID, la clave WiFi y algún correo por ahí

Esto, también le pasó tiempo atrás al Centro de Control de Seguridad la SuperBowl, que también publicó la clave WiFi que utilizaban, y que por supuesto fue hiper-retwitteado por todo el planeta.

Figura 4: Otro centro de control de seguridad que publicó la password de su WiFi

Si quieres tener problemas de seguridad con tu red WiFi, no hace falta hacer el ridículo poniendo una clave que luego se vea en una imagen en la que encima vas a posar, pon una red abierta que todo el mundo se configure y espera que lleguen los malos.

Figura 5: Las redes WiFi del Senado

Pero al final, tampoco hay que preocuparse tanto. Total, ¿qué podría alguien querer hacer con la red WiFi de cualquiera de estos sitios? Si eres de los que sí que te importa, os dejé un artículo sobre cómo securizar una red WiFi para que no te entren.

Saludos Malignos!

SQL Injection: Aplicar Mínima Superficie de Exposición en las Cadenas de Conexión a BBDD

Cuando me toca explicar la fortificación de aplicaciones web hay que hablar obligatoriamente del impacto que tienen los bus de SQL Injection y de cómo poder limitarlos aplicando las reglas de Mínimo Punto de Exposición y Minima Superficie de Exposición. Una de las areas donde se puede tener un buen resultado, es en la utilización del propio sistema de seguridad del motor de bases de datos que se esté utilizando, aprovechando un esquema múltiple de conexiones a bases de datos y permisos restringidos a cada uno de ellas. 

Bases de datos sin compartición de usuarios

Cuando se va a conectar una aplicación web a una base de datos, es necesario contar con al menos un usuario de la base de datos que tenga permisos en el SGBD. Con ese usuario, al menos, se hará la cadena de conexión para gestionar los datos que se almacenen en la base de datos que que allí se cree. Uno de los errores más comunes que se encuentran es que ese usuario al final se puede usar en varias bases de datos creadas dentro del mismo SGBD - algo muy común en entornos Microsoft SQL Server - o que tenga acceso a esquemas creados para otras aplicaciones - algo muy común en entornos Oracle Dabatabase -.

Figura 1: Mala gestión de conexiones a bases de datos en un SGBD

Esto lleva a que al final, si alguien es capaz de localizar un bug de SQL Injection en una aplicación web conectada a una base de datos, con el mismo usuario que la aplicación usa para conectarse a esa base de datos es capaz de conectarse a otras bases de datos y sacar datos de ella.

Figura 2: Bases de datos con usuarios aislados

Para evitar eso, cada base de datos de aplicación debe poder ser accedida única y exclusivamente por el/los usuarios que vayan a ser utilizados en la conexión de esa aplicación. Si alguien intenta acceder a esa base de datos desde otra cadena de conexión, deberá recibir un mensaje de error.

Figura 3: Error de conexión al intentar cambiar de base de datos con un bug de SQL Injection

Dentro de una aplicación web, conexiones distintas para cada rol

Supongamos que tenemos una aplicación web expuesta en Internet en la que los usuarios que allí se creen tienen tres roles. Vamos a suponer que estos tres roles son: Rol Administrador que puede leer, escribir todas las tablas que dan soporte a la aplicación, el Rol Editor, que pueden escribir y borrar registros en tres tablas, y el Rol Lector que solo puede leer datos de dos tablas.

A estos roles, hay que sumar que la propia aplicación web, en algún momento puede tener que realizar algunas acciones no dependientes de las acciones de los usuarios, por ejemplo la autenticación de las credenciales, las operaciones de mantenimiento, etcétera. Para ello, hablaremos del Rol de Aplicación.

Lo suyo es que, para dejar un entorno fortificado se creen dentro de la base de datos cuatro usuarios que representen a los cuatro roles con los que se va a conectar la aplicación web. Cada uno de esos usuarios de la base de datos tendrá asignados los privilegios sobre el sistema necesarios para el cumplimiento de su rol dentro de la aplicación web, así como los permisos sobre los objetos estrictos y nada más.

Figura 4: Tabla de roles y permisos

A partir de ese momento, la aplicación web no gestionará una única cadena de conexión, sino que gestionará 4 cadenas de conexión distintas para cada una de las acciones que quiera realizar. Por ejemplo, para hacer un proceso de login con un usuario, la aplicación web primero creará una conexión con el usuario del Aplicación, autenticará las credenciales que le introduzcan contra su tabla_usuarios, y una vez que se sepa el rol que deberá tener ese usuario dentro de la aplicación web, se cerrará la conexión con el Rol_Aplicación y se abrirá una nueva conexión con el usuario de la base de datos con el rol adecuado.

Figura 5: Esquema de cadenas de conexión múltiples desde la misma aplicación web a la misma base de datos

Esto lo que hace es que, si un usuario con el Rol_Lector encuentra un bug de SQL Injection dentro de la aplicación, el impacto que puede tener estará limitado. Por el contrario, lo habitual es que las aplicaciones web solo gestionen un único usuario de conexión con todos los permisos sobre todos los objetos de la base de datos, lo que lleva a que cualquier usuario de la aplicación web que encuentra un bug de SQL Injection acabe teniendo acceso a todos los objetos de la base de datos, ya  que el usuario que está utilizando la aplicación web en la conexión a la base de datos los tiene.

Saludos Malignos!

No pongas tus tokens oAuth en tus apps para Andorid

Cuando los investigadores de la Universidad de Columbia publicaron su trabajo referente a PlayDrone, una de las cosas que más revuelo causó fue su aviso sobre la cantidad de apps que están guardando sus tokens OAuth y sus API Keys de Amazon directamente en las apps.

Figura 1: Número de tokens por tipo descubiertos en apps de Google Play

En el artículo de The Register, los mismos autores del trabajo decían que Google estaba trabajando en añadir una alerta que avise a un desarrollador cuando una de sus apps lleve hardcodeado uno de estos tokens, para que sea consciente del riesgo que corre.

Para encontrar esos tokens, no es necesario ni irse a Google Play a buscar las apps y decompilarlas, ya que simplemente haciendo un poco de hacking con buscadores en los repositorios de código habituales es más que suficiente para localizar códigos fuentes con el OAuth_Token y el OAuth_Token_Secret a la vista de cualquiera. Algo similar a cuando se buscan bugs en repositorios de código open source.

Figura 2: Tokens OAuth publicados en repositorios de código

Al final, cuando se da un OAuth_Token y un OAuth_Token_Secret a una app se le está concediendo una especie de contraseña que da acceso a una cuenta con una lista de permisos. Esos permisos pueden ser acceder a información personal, hacer una publicación, hacer un follow a otra persona de una red social, dar un like, acceder a la lista de contactos, leer y escribir mensajes privados, etcétera. 

Cuando se pone un token OAuth en una app que va a ser instalada en miles de dispositivos, se está dando un acceso común a una misma cuenta a todos los dispositivos que hayan descargado y ejecutado esa app, lo que no parece tener mucho sentido. Si uno de esos comienza a hacer un mal uso del token, la única forma de detenerlo será generar un nuevo token y desplegar una nueva versión de la app, algo que va contra cualquier sentido común.

Figura 3: Esquema de gestión centralizada server-side del token de acceso a cuenta

Si se quiere que desde una app que está instalada en muchos dispositivos se pueda hacer cosas en una cuenta por medio de un token OAuth, lo suyo es crear un servicio que controle el uso del token y que monitorice qué es lo que quiere hacer cada usuario con la cuenta. Así, si uno de los usuarios comienza a hacer un uso malicioso o simplemente no autorizado, se puede restringir su acceso.

Si pones los tokens en las apps, o se los envías, o cualquier otra cosa que acabe con que muchas apps instaladas en clientes acaben teniendo el mismo token, ya sabes a todos los riesgos que te expones. Si vas a hacer una app para subir a Google Play, antes aprende buenas prácticas de desarrollo seguro de apps para Android.

Saludos Malignos!

TrueCrypt y la posible advertencia con Esteganografía

La esteganografía es la ciencia de utilizar canales encubiertos para enviar mensajes, y a lo largo de la historia hemos visto muchos ejemplos en periodos de guerra, en los que o bien miembros del mismo bando se envían mensajes usando técnicas como los micropuntos o los mensajes ocultos en textos. De todo ello se hablan los autores en el libro de Esteganografía y Estegoanálisis, donde de pueden encontrar muchos ejemplos de los que tal vez os hable en el futuro. Ahora, con el mensaje que puede leerse en la web de TrueCrypt las especulaciones han comenzado a extenderse, al parecer cierto para muchos que hay un mensaje oculto en el texto de despedida del proyecto. Según está publicado allí, puede verse el siguiente mensaje.

Figura 1: Mensaje de la web de TrueCrypt

En él texto "Using TrueCrypt is not secure as it may contain unfixed security issues" es donde parece que puede estar oculto el mensaje. Si se elige la primera letra de cada palabra, el resultado es la cadena siguiente: "utinsaimcusi". Si se ponen espacios en los sitios adecuados puede leerse la siguiente frase: "uti nsa im cu si", que traducida al latín da el resultado que se puede ver en la imagen siguiente.

Figura 2: Cadena traducida del latín al inglés

Como se puede ver, traduciendo la cadena como si fuera un texto en latín, el mensaje que se lee es "If I with to use the NSA", lo que muchos han interpretado como que no lo uses, a menos que quieras usar un software de la NSA, algo que se ha interpretado como que TrueCrypt está más que controlado por la agencia.

Lo cierto es que del control de la NSA sobre TrueCrypt hay muchas especulaciones hace tiempo, y tras el misterioso anuncio sobre el abandono del proyecto, se han exacerbado. Es cierto que la auditoría de código que le están haciendo dice no haber encontrado aún ninguna puerta trasera, pero lo cierto es que podría ser que existiera una muy bien escondida, que tras los fallos descubiertos en muchos de los principales sistemas de cifrado es más que factible.

De hecho, con el supuesto mensaje esteganográfico en la despedida de TrueCrypt, si se toma como un lenguaje como el Croata, Sérbio o Bósnio, lo que se obtiene es otro resultado distinto, pero en la misma línea.

Figura 3: Mensaje traducido del Croata. Falta una tilde en la c para ser completo.

A partir de este momento, cada uno deberá decidir si lo cree o si no lo cree. Si se cambia a otro software de cifrado o no. Lo cierto es que desde que salieron todas las prácticas de espionaje creo Internet está sufriendo y muchos somos los que no nos sentimos cómodos con esta orgía de espionaje. Incluso en los USA, lo que ha llevado a que ahora se le vaya a recortar un poco su poder. Con este No Lusers que hice en una tarde tonta quería reflejar esa sensación que tengo, y lo hice en papel y rotulador por algo.

Figura 4: No Lusers 174 - Demasiado acompañado en Internet

El problema además es que no solo es la NSA la que está haciendo estas cosas, y muchos otros individuos, organizaciones y/o grupos - por llamarlos de alguna forma - están haciendo cosas similares, así que al menos protege todo lo que puedas tu paso por la red, no se lo pongas fácil.  Ten en cuenta que si este mensaje con esteganografía es cierto estamos en guerra de verdad.

Saludos Malignos!

Todas las herramientas de Black USA 2014 Arsenal

Esta semana se ha publicado la lista de herramientas que van a componer el Arsenal de Black Hat USA 2014, y este año parece que han batido records en cuanto a número de ellas propuestas, ya que el número que hay es ingente. Entre ellas hay herramientas de compañeros y amigos como ProxyMe de nuestro compañero Manu "The Sur", WhatsApp Privacy Guard de Jaime Sánchez y Pablo San Emeterio para ayudar evitar los ataques de quienes quieren espiar WhatsApp o Voyeur de Juan Garrido "Silverhack" para auditar un Active Directory usando PowerShell y sin necesidad de cuentas administrativas.

Figura 1: Herramientas en Black Hat USA 2014 Arsenal

La lista es larga, y cuenta con herramientas de gran calado y utilidades pequeñitas pero que pueden resultar más que prácticas para muchos entornos. Aún no están disponibles en la web de Black USA 2014 Arsenal, pero la mayoría de ellas se pueden encontrar en sus repositorios de desarrollo. Este es un resumen que he hecho por si te puede ayudar a localizarlas mejor.

- ANDROID DEVICE TESTING FRAMEWORK: Framework y APIs para auditar Android
- AUTOMATED MEMORY ANALYSIS: Plugins para Cuckoo Sandbox
- BEEF (Browser Explotation Framework): JavaScript Botnets Control Panel
- BREWSKI (BURP RHINO WEB SCANNER): Plugin para Burp scriptable
- C-SCAD: Herramienta de explotación de un cliente SCADA
- CHIPSEC: Auditoría de plataforma (Secure Boot, BadBios, etc..)
- CLASSIFY6: Command Line Tool que clasifica una dirección IPv6
- CYNOMIX: Proyecto de clasificación de malware en familias
- DAMM: Análisis diferencial de malware en memoria
- DEPENDENCY-CHECK: Analiza dependencias entre apps y librerías
- DRADIS: Plataforma para consolidación de datos en auditorías
- FILIBUSTER: Analiza puertos filtrados en firewalls
- FLOWINSPECT: Análisis e inspección de tráfico de  red con reglas
- FSEXPLOITME: ActiveX vulnerable para enseñar Browser Explotation
- HEYBE: Herramienta de pentesting para redes empresariales
- ICE-HOLE: Framework para auditar tests de phishing en auditoría
- IDB: Herramienta automatizada para auditar apps en iOS
- IMAS: iOS Mobile Application Security Libraries
- IMPACKET: Clases en Python para herramientas de hacking de red
- ISPY: Herramientas de auditoría de Apps para iOS
- JTAGULATOR: Herramienta de auditoría de chips en hardware
- MALTRIEVE: Recuperar malware desde la fuente en que se sirve
- MELKOR: Herramienta de Fuzzing para formato de fichero ELF
- MODSECURITY: Popular WAF OpenSource. Lo usamos en FOCA.
- MORNING CATCH: Virtual Machine para enseñar ataques client-side
- MOZDEF THE MOZILLA DEFENSE PLATFORM: Plataforma SIEM de Mozilla
- NFCULT: Auditar y explotar NFC ultralight en Android
- OOPS, RFIDID IT AGAIN: Pentesting de RFID
- OWASP PCI TOOLKIT: Herramientas OWASP para aplicar PCI
- OWASP ZED ATTACK PROXY (ZAP): Popular Proxy para pentesting
- POWERSPLOIT: Metasploit-like escrito en PowerShell
- PRAEDA: Explota impresoras multi-función y saca credenciales
- PROXYME: Proxy HTTP-s con plugins scriptables para auditoría web
- REGEORG: Creación de túneles vía HTTPs a puertos de red
- RICKROLLING YOUR NEIGHBORS WITH GOOGLE CHROMECAST: hacking Chromecast
- SECURESCAN SAAS FREE SCANNER: Vulnerability Management Cloud-Service
- SERPICO: Crear informes con datos de herramientas de auditoría
- SHINOBOT SUITE: R.A.T. Simulator para auditar sistemas
- SIMPLERISK: Herramienta de gestión de riesgo para empresas
- SMARTPHONE PEN-TEST FRAMEWORK: Hacking de usuarios con smartphone
- SNOOPY: Sonda para recolectar información de dispositivos con cercanía
- SPOTLIGHT INSPECTOR: Análisis forense de BBDD Spotlight de OSX
- TAINTLESS: Detección y explotación de SQL Injection
- THREADFIX: Gestión de vulnerabilidades y parches
- VEIL-FRAMEWORK: Herramienta para pentesting en equipos
- VIPER: Herramienta de gestión de scrips para reversing
- VIPROY: Herramienta para hacking de VoiP
- VOLATILITY FRAMEWORK 2.4: Nueva versión de memory forensics
- VOYEUR: Auditoría de Active Directory hecha en PowerShell
- W3AF: Web Security Scanner
- WATOBO: Herramientas para auditoría web
- WHATSAPP PRIVACY GUARD: Cifrado de WhatsApp
- ZIG TOOLS: Librerías Python para desarrollo con Freakduino
- ZITMO NOM: Para auditar el despliegue de ZitMo vía SMS

Como veis, la lista de herramientas es grande, así que he intentado resumir en una sola línea información básica para que decidas si quieres conocer mejor esas herramientas o no, además de dejaros enlaces a algunos de sus repositorios y/o documentación disponible. Si quieres saber más de cada una de ellas, visita la web del Arsenal o busca la herramienta en su repositorio si está disponible y ponte a probarla.

La verdad es personalmente me encanta ver la cantidad de gente que hay haciendo investigación en seguridad y que hace que cada día avance más el conocimiento. Con grandes herramientas, pequeñas soluciones o simplemente documentando y creando recursos para enseñar o agitar la mente de todos con nuevas ideas.

Saludos Malignos!

El asesino en serie BTK fue descubierto por los metadatos

Todo comenzó con un brutal asesinato en el año 1974. El asesinato de la familia Otero donde el padre, la madre, el hijo y la hija fueron atados, torturados psicológica y físicamente y después asesinados. Ese mismo año volvió a matar, en este caso a una joven de 21 años a la que apuñaló. Estos dos asesinatos conmocionaron a la opinión pública de Wichita, donde tuvieron lugar los asesinatos, pero también levantó cierta admiración morbosa lo que llevó a que algunos impostores llamaran declarándose ellos los asesinos.

El asesino auténtico, que disfrutaba tanto de sus actos como para llegar a masturbarse en el medio de las torturas, no iba a dejar que le quitaran el mérito de sus actos, así que dejó una carta incrustada en un libro de la biblioteca pública de Wichita en la que describió, con todo lujo de detalles, todas y cada una de las atrocidades que había hecho en sus asesinatos.

Su marca sería era, según él mismo decía, Bind them, Torture them and Kill them (Átalos, Tortúralos y Mátalos), que era uno de los nombres mediáticos que él sugería que lo llamaran BTK. En el año 1978, reclamando más atención de los medios, envió una carta a una cadena de televisión local en la que adjuntaba su firma BTK, y convirtiéndose ya oficialmente en el asesino en serie de Wichita.

Figura 1: Carta manuscrita y firma de BTK

En total, desde el año 1974 que comenzó, el número de asesinatos continuó creciendo hasta el año 1991, siendo 10 el número de personas que sufrieron con él. En el año 1988, tras el asesinado de tres miembros de una familia, volvió a escribir una carta a la Policía para dejar claro que él no había sido, a pesar de que consideraba los asesinatos "un buen trabajo". Todos sus asesinatos están recogidos y explicados en detalle en este documental que se hizo para la televisión.

Figura 2: Documental sobre BTK Killer (visto en SecurityByDefault)

La investigación se fue enfriando, hasta que en el año 2004 se volvió a abrir. Esto fue a debido a que la Policía no le había atribuido uno de sus asesinatos a BTK, por lo que comenzó a intercambiar cartas con ellos reclamando la autoría del crimen. Tras confirmar que las cartas podrían ser auténticas, se reabrió la investigación de BTK Killer, y con el avance de la ciencia de investigación forense, se recuperaron muestras de ADN de debajo de las uñas de una de sus víctimas.

Con el anuncio de la obtención de ADN del posible asesino se comenzó a comprobar contra muestras de los principales sospechosos, junto con el de muchas personas que habían sido estigmatizados con las sospechas de ser el ellos el asesino, que decidieron voluntariamente dar muestras de su ADN para poder salir de sospechas. Este proceso por el que pasaron 1.300 personas llevó a eliminar a muchos de los sospechosos que tenía tanto la Policía como la ciudadanía de Wichita, pero no a localizar al asesino.

En una de las cartas que envió, BTK preguntó si podrían seguir el origen en el que había sido utilizado un disquete, a lo que la Policía contesto que no era posible hacer eso - algo que sabemos que no es del todo cierto como sabéis los especialistas en análisis forense informático -. Confiado, el 16 de Febrero de 2005, BTK Killer envió un sobre a la cadena de televisión KSAS-TV - filial de la FOX - de Wichita en el que puso un disquete, una carta, una fotocopia de la cubierta de una novela sobre un asesino en serie y un collar de color oro con un medallón.

Los metadatos que le llevaron a la cárcel

Dentro del disquete de 3 1/2" y 1.44 MB se pudo recuperar un fichero borrado en formato Microsoft Word que se le había pasado a BTK Killer por no hacer un borrado seguro de los documentos. El archivo recuperado .DOC tenía metadatos, y se podían leer dos cosas importantes. En primer lugar aparecía el texto "Christ Lutheran Church" y en el historial de edición del fichero se podía leer que el último que lo había modificado era el usuario "Dennis". Con esta información, una sencilla búsqueda en Internet puso sobre la mesa un nuevo sospechoso. 

Figura 3: El disco de 3 1/2 que envió BTK Killer (en el NYTimes)

De BTK Killer se suponía que tenía un Jeep Cherokee, que coincidía con el coche de Dennis Reader, el Presidente del Consejo de la Congregación de la Iglesia Luterana de Cristo en Wichita. Solo faltaba la prueba definitiva, conseguir una muestra de ADN y contrastarla con la que había sido recuperada en el año 2004 de las uñas de una de sus víctimas. Para ello, primero consiguieron una orden para poder contrastar la muestra de ADN con la de la hija de Dennis Rader que tenían en la Universidad donde estudiaba. Tras comprobar que había muchas coincidencias, consiguieron la orden de arresto y el asesino BTK Killer fue detenido y condenado a 10 cadenas perpetuas que aún está cumpliendo.

Una vez más un caso de informática forense en el que con un recuperador de archivos y un análisis de metadatos consigue los indicios necesarios para apuntar a un sospechoso sobre que el que focalizar los esfuerzos en la obtención de pruebas. Un ejemplo que añadir a la lista de ejemplos de análisis forense de metadatos.

Saludos Malignos!

NSA PlaySet: Juega con los juguetes de espionaje de la NSA

Dentro de todas las revelaciones sobre las actividades de la NSA que fueron filtradas por Edward Snowden se encontraba el catálogo de herramientas de espionaje de ANT. Un total de 48 proyectos con utilidades para controlar y hackear todo tipo de sistemas que los miembros de la NSA tenían a su disposición.  El catálogo completo lo tenéis este PDF de 48 páginas donde hay todo tipo de utilidades de hacking de red, de herramientas de espionaje SDR, o de gadgets hardware aplicables diferentes esquemas de ataque.

Figura 1: NSA Ant

Ahora, el objetivo en la comunidad hacker es poder recrear todo lo descrito en ese catálogo de ANT, para que el conocimiento de cómo están creadas esas herramientas ayuden a mejorar la seguridad de los sistemas, añadiendo las utilidades al catálogo de los pentesters, o abriendo nuevos caminos a los investigadores de seguridad. 

Figura 2: Catálogo completo de Productos de ANT

Para ello, se ha lanzado e proyecto NSA PlaySet, donde cada investigador de seguridad puede aportar su conocimiento sobre cómo está construido cada uno de los proyectos de espionaje de ANT, que están aún en Problemas Abiertos, aportando documentación, herramientas o estudios totales o parciales de cómo está construido o puede replicarse cada uno de ellos.

Figura 3: NSA PlaySet

La verdad es que si tienes un trabajo de fin de carrera o master y no sabes qué hacer, intentar replicar uno de los proyectos de ANT puede ser divertido e interesante. Además, si este verano querías aprovechar el tiempo libre que te quede - si es que te va a quedar algo - juntarse a estudiar uno de ellos, documentarlo y presentarlo al mundo puede ser entretenido cuanto menos.

Saludos Malignos!

PlayDrone: Tokens de autenticación en apps Google Play

Un grupo de investigadores de la Universidad de Columbia han publicado un paper titulado "A Measurement Study of Google Play", donde explican cómo han realizado un estudio sobre las apps publicadas en Google Play y los resultados descubiertos, donde llama poderosamente la atención el descubrimiento de los tokens de autenticación hardcodeados en el código de las apps.

Figura 1: El paper que describe PlayDrone y el estudio de Google Play

Los miembros del equipo, Nicolas Viennot, Edward Garcia y Jason Nieh han construido para su análisis PlayDrone, un sistema que hace crawling de todo Google Play para descubrir el máximo número de apps y descargarlas. Hacer esto no es trivial, ya que Google no permite hacer esto, así que han tenido que utilizar técnicas conocidas por la industria de seguridad para obtener la máxima visibilidad de ellas.

Una vez conseguidas las apps, más de 1.000.000 de apps distintas, los investigadores han hecho una serie de catalogación de las apps en base a las librerías que utilizan, los tipos de servicios que ofrecen, etcétera, que siempre vienen bien para poder entender mejor Google Play.

Figura 2: PlayDrone y el análisis de la app de Gmail para Android

Esto es importante, sobre todo vista la industria de Fake Apps que se ha creado alrededor de Android, para poder localizar aquellas que utilizan los mismos patrones, como por ejemplo las mismas librerías de publicidad. O para localizar apps maliciosas que te quieran robar el WhatsApp para que otro te pueda espiar WhatsApp o  los números de teléfono de tu terminal para hacer suscripciones a sistemas SMS Premium.

Sin embargo, lo que más llama la atención es que tras decompilar todas las apps han realizado una búsqueda de tokens OAuth y credenciales para la API de AWS (Amazon Web Services) y han podido descubrir miles y miles de tokens hardcodeados, incluido los de cuentas de Facebook, Twitter, Linkedin, Flickr, BitLy, FourSquare, etcétera.

Figura 3: Tokens de cuentas de servicios localizados en apps 

Cualquiera que consiga estos tokens podrá gestionar gran parte de las cosas que se haya autorizado a ese token, como por ejemplo poner twitts o hacer follow en Twitter (hay más de 28.000 tokens) y poder vender retwitts o seguidores para satisfacer las necesidades de los Community Managers de Cartón Piedra. También podrían hacer like a páginas de Facebook - como hacía el tipo que se cambió el nombre a Mark Zuckerberg - o compartir contenido en los muros de Facebook y distribuir malware (como se hacía con la estafa de la linterna molona), etcétera. Los amigos del Fraude Online seguro que encuentran siempre algo valioso con estas cuentas.

Figura 4: La charla de la presentación del trabajo

El uso de tokens hardcodeados en las apps lo hemos visto no solo en Android y también en las apps de App Store de iPhone se encuentra demasiado comúnmente, como se explica en el libro de Hacking iOS, e incluso a veces pueden encontrarse estos tokens simplemente revisando el log de una app usando el Apple System Log para ver cuándo hace uso de él.

Dicho esto, si tienes una app desarrollada en iOS o desarrollada en Android, o si piensas hacer una app en breve, aplícate el cuento y ten mucho cuidado con los tokens o passwords que hardcodeas en tu código, que como puedes ver si está en Google Play o en App Store está al alcance de cualquiera.

Saludos Malignos!

Vídeos de (casi) todas mis charlas en el canal YouTube

Hace cosa de un mes comencé a recuperar algunas de las charlas que he ido dando a lo largo de los últimos años. Es un trabajo arduo porque muchas tienen más de 10 años, y no las encuentro por ningún sitio, pero al menos he recuperado una buena cantidad de ellas, y las he consolidado en mi canal Youtube.

Figura 1: Hay más de 120 vídeos en el canal

Para que sea más fácil de localizar una charla, las conferencias completas, o los programas y documentales de televisión en los que he participado, los he clasificado en algunas listas por años y por temas. De momento he subido conferencias desde el 2007.

Figura 2: Listas de vídeos por años, programas de TV y charlas en inglés

Seguiré recuperando todas las conferencias que pueda, para dejarlas ahí. La primera charla de Black Hat 2007 sobre LDAD Injection & Blind LDAP Injection aún no la he localizado, pero tienes las primeras charlas de FOCA, de Connection String Parameter Pollution, de Time-Based Blind SQL Injection using heavy queries, de Evil FOCA, de DUST RSS, etcétera, etcétera por allí.

Saludos Malignos!

3 de Julio: Escenarios de Seguridad con Latch

El próximo día jueves, 3 de Julio de 2014 desde Eleven Paths haremos un pequeño evento dirigido a responsables de seguridad y sistemas. No será muy largo, pues es solo una actualización de nuestras tecnologías con la presentación especial de Latch for Active Directory,  Latch for OS X, la presentación de casos de uso en clientes que lo han implantado, la integración de Latch con soluciones biométricas, además de la presentación de una nueva actualización de nuestro sistema de Pentesting Persistente Faast. 

Figura 1: Escenarios de Seguridad contra atacantes internos con Latch

El evento será en el Distrito C de Telefónica, y como es un evento muy dirigido a CSOs, CISOs y CTOs solo hemos reservado una sala para 70 personas, porque queremos poder charlar, comer, discutir y disfrutar un rato del intercambio de ideas, por lo que hemos creado un sistema de pre-registro online en la web Eleven Paths Security Day Julio 2014 para que puedas solicitar tu plaza. La agenda en detalle es la siguiente.

Figura 2: Agenda del evento

Después, los compañeros que están cuidando del registro os enviaran la confirmación de vuestra reserva cuando se pueda garantizar que hay plazas, ya que vamos hacer un pequeño café y un cocktail. Si tienes especial interés en asistir porque estás muy interesado en Latch, MetaShield o Faast, a parte de registrarte no dudes en enviarme un correo para que pueda avisar a los compañeros de ello.

Saludos Malignos!