viernes, 31 de octubre de 2014

¿A quién le vas a decir la fecha de tu muerte?

Ya que estamos en la noche de Halloween, donde los seres del utlramundo asolarán la noche para ponerse hasta arriba de licores espirituales que los convierta aún más en lo que representan, donde a altas horas de la noche los zombies de incógnito se mezclarán con los de que van disfrazados de tal ente, para compartir con vosotros un macabra reflexión sobre la muerte de todos y cada uno de nosotros. La pregunta que os hago es... ¿a quién le vas a decir la fecha de tu muerte?



Figura 1: ¿A quién le vas a decir la fecha de tu muerte?



Decía el mítico Clint Eastwood en una de sus películas de mi niñez en las que actuaba al margen de la ley que se había retirado por las matemáticas. "¿Las matemáticas?", le pregunta inocente el actor que le da soporte en esa escena. "Sí, los números dicen que en esta profesión a mi edad se suele estar muerto". Laestadística que tanto nos hace sufrir en la universidad resulta ciencia clave para el análisis de los datos y la predicción del futuro. Sumado a ella, las técnicas demachine learning basadas en datos y datos de entrenamiento, al final consigue que esa matemática acabe convirtiéndose en resultados más o menos certeros de lo que va a pasar en el futuro, y dad por cierto que vuestra muerte esté en el futuro - os deseo que tan lejos como se sea posible -.


Lo cierto es que si nos hiciéramos un chequeo médico con asiduidad y nos midieran los valores de nuestro sistema cada cierto los doctores, aplicando su estadística y los sistemas de machine learning podrían saber más o menos cuándo va a suceder eso. Cuando alguien con tus síntomas, valores y hábitos va a vivir. Si esto lo hacemos regularme con sensores que reportan constantemente tus datos a la consulta del doctor éste podrá tener más información y pronosticar de forma más atinada cuando vas a comenzar a dormir el último sueño, el más largo y profundo que tendrás.



Figura 2: Datos de actividad física en Endomondo


Eso ya está aquí, y los datos médicos corren a servidores en la cloud bajo las famosas aplicaciones de e-health o los portales para deportistas como Endomondo - ¿La comprará Facebook y acabarán tus datos junto a tus likes y a tus fotos de fiesta? - que recoge tu actividad física. Qué mejor información que una información en tiempo real de todo lo que haces, de cómo reacciona tu cuerpo de cómo te sientan tus propios hábitos para saber cuándo cruzarás con el barquero a la otra orilla.


Ahora Microsoft se ha metido en este mercado con una nueva pulsera y el Apple Watch también tiene sensores para monitorizar tu salud e incluso el nuevo iOS 8 deApple, sin decirme nada ha comenzado a contar los pasos que doy, los pisos que subo, por dónde me muevo, etc. Todo ello, supuestamente, para que yo me controle. Pero, evidentemente, al final los números los tiene alguien, estarán en algún sitio para que formen parte de ese big data mágico que le permitirá saber a la compañía que elija el momento en el que creen que moriré, y hasta detectar que acabo de hacerlo para comprobar su predicción.




Figura 3: Monitorización de pasos en iOS 8 automática


Este control de salud podrá llegar a convertirse en algo preventivo que te permita mejorar tu salud o en algo completamente pernicioso que se convierta en un asedio de ofertas con planes de pensiones, ataúdes baratos, denegación de créditos, inhabilitación para avalar operaciones o incremento de costes en seguros sanitarios, de vida o de conducir.
"Lo siento señor Martínez, no podemos darle ese crédito a 5 años porque nuestros sistemas dicen que tiene una probabilidad de morir dentro de 2 años superior al 82 % y por política de compañía nos está prohibido aprobarle su operación crediticia"
El negocio de la muerte siempre ha dado mucho dinero, desde asesinos a sueldos, mercenarios, enterradores, casas fúnebres, agoreros, salvadores de almas y hasta maquilladores para el momento del adiós. Ahora hay otro negocio en ciernes, los predictores que podrán vender a buen precio la fecha de tu muerte. ¿Quién será el tuyo? ¿Has hecho testamento ya? ¿Has elegido ya a quién le vas a decir cuándo te vas a morir? ¡Qué tengas un terrorífico Halloween!


Saludos!

lunes, 27 de octubre de 2014

Un misterio criptográfico en la Universidad

Siempre estamos expuestos a cantidades ingentes de información, la mayoría de las veces visual, y sobre todo escrita, aunque habitualmente paseamos por el mundo sin prestarle demasiada atención. Pero, si nos tomamos cuidado para intentar prestarle la atención atención necesaria, a veces nos podemos llevar más de una sorpresa. La siguiente historia es un claro ejemplo de esto, ya que por prestar atención al entorno, acabé involucrado en un misterio de criptografía.



Figura 1: Un misterio criptográfico en la universidad

Un encuentro fortuito en la Universidad

A principios de este año, caminando por los pasillos de una facultad de una universidad pública conocida tuve la “suerte” de encontrar esto tirado en el suelo, documento que me he tomado la libertad de borrar –de forma muy amateur – algunos segmentos de la hoja para no implicar a las personas de la lista.

A primera vista es una página que podría pasar desapercibida por ser una hoja con los resultados y calificaciones de algún trabajo o examen de la , sobre todo por la estructura y más aún al encontrarse debajo de uno de los tablones que se usan a tal fin. La sorpresa viene cuando te paras a intentar leer detenidamente algo de lo que está escrito en ella, ya que aquello es totalmente ilegible a simple vista.



Figura 2: El extraño documento tirado en la Universidad

Cualquier otro en mi lugar hubiera dejado el papel donde estaba o, al recogerlo y verlo, lo habría tirado a la basura. Pero a mí me picó la curiosidad, así que me lo guardé para “analizarlo” más tarde en casa. El papel me recordó a los problemas y retos a los que jugaba con mi abuelo cuando era más pequeño. Al fin y al cabo, detrás del texto estaba la atracción inherente de todo reto.

Ya que había decidido que iba a jugar con esto, antes de abandonar el lugar de los hechos tuve la precaución de revisar sin éxito el suelo y otros tablones adyacentes para ver si encontraba más especímenes de este tipo, pero no hubo ninguna suerte. Este ejemplar era único en esa zona. Habría que intentar sacar todo lo necesario de allí.

Primeros impresiones sobre el misterio

Una vez en casa, confirmé mi idea de que se trataba de algún tipo de lista de clase: arriba podemos ver el encabezado con los datos de la asignatura y el curso en cuestión, así como el escudo de la Universidad (bueno, lo podríais ver si no lo hubiera eliminado de la imagen). Más abajo encontramos tres columnas, con lo que, a priori, parecen ser nombres y apellidos, DNIs y notas numéricas. El hecho de que el listado central estuviera ordenado alfabéticamente (aunque sin ningún sentido en castellano) reforzaba esta idea. Pero por qué estaba codificado era el misterio.

Como no era el primer documento cifrado con el que me topaba, decidí intentar descifrarlo. No estaba seguro de si un escáner OCR, incluso aplicado al documento original, funcionaría correctamente para pasar los caracteres al equipo y lanzarle baterías de análisis automático, así que primero decidí tratarlo analógicamente, al estilo de mi abuelo con sus acertijos.

Lo primero que se me ocurrió fue someterlo a un análisis de frecuencia para ver qué letras o grupo de letras tenían mayor número de apariciones, pero deseché la idea por dos motivos: primero, que eso solo me serviría con los caracteres alfabéticos, no tendría utilidad ni para números ni para el resto de caracteres como puntos o comas. Y segundo y más importante, me parecía un esfuerzo importante como para hacerlo a mano.

Así que le saqué una foto a la página y la compartí con un grupo de amigos a los que les gustan estas cosas y que a veces tienen muy buenas ideas. Introduje el tema preguntando de qué tenía pinta la hoja, y todos coincidieron en decir que se trataba de un listado de notas de la Universidad (les adelanté que no creía que se tratase de las notas de una asignatura de criptografía, aunque como idea no estaba mal). Algunos sugirieron la posibilidad de que estuviese escrito en otro idioma, aunque seguro que no era así, pues los caracteres pertenecen al alfabeto latino. Les pedí ayuda para resolver el primer reto: decodificar la hoja. Si lo conseguíamos estaríamos un paso más cerca de conocer el resto de detalles al respecto.



Figura 3: Ideas sobre la decodificación del listado

Tras un ratito de debate (en el que surgió la aburrida posibilidad de usar Haskellpara descifrarlo), llegamos a la conclusión de que estaba codificado usando una variación del clásico Cifrado César, en la que en lugar de desplazar cada carácter (ojo, no solo las letras) tres posiciones a la derecha el desplazamiento era de una sola posición. El hecho de que se mantuviese el orden alfabético era una pista importante para ello.



Figura 4: El debate en WhatsApp fue dando ideas

Una vez comprobado que se trataba de ese cifrado (traduciendo algunos segmentos y viendo que en efecto se corresponden con términos en castellano: González,Gómez… Y en efecto la cadena EOJ coincide con las siglas DNI) el siguiente paso era averiguar cómo y por qué. Es decir, la criminalística y la criminología del hecho.

Es un detalle curioso el hecho de que también tanto los números (como se puede comprobar en el encabezado de la hoja, donde se lee Dvstp!Bdbel n jdp!3124.25 –Curso académico 2013.14) como los signos de puntuación estuviesen desplazados sugiere que el cambio se ha hecho sobre una tabla de caracteres, bien en un drivero bien en una tipografía diseñada ad hoc.

Investigación de campo en la Universidad

Para ello el primer paso era analizar en profundidad el contenido de la lista. En efecto se trata de una lista de clase, con los alumnos matriculados en una determinada asignatura ordenados según sus apellidos alfabéticamente. En la primera columna aparecen los DNIs correspondientes, mientras que la última no refleja ni las calificaciones ni los nombres de los trabajos. En su lugar lo que aparece son los usuarios virtuales de cada alumno de la universidad.

Esta información, aunque es fácil de conseguir (pues el algoritmo que se usa para generarlos es unir las tres primeras letras del nombre y ambos apellidos; en caso de conflicto con otro usuario ya existente se añade un contador numérico al final al usuario virtual), se supone privada, de forma que solo tienen acceso a ella el propio usuario y los servicios informáticos y de administración de la universidad (según me contestaron cuando pregunté, hay veces en que ni siquiera los propios profesores tienen acceso a esa información). Por tanto y teóricamente no es algo accesible a todo el mundo (lo que supone, por tanto, una violación – aunque cifrada – de la intimidad de la gente, en especial que la persona responsable dejase el papel tirado en medio del pasillo).

Bien, dicho esto, ese hecho despertó mucho (más) mi curiosidad: si se trata de una información ya de por sí restringida o clasificada, ¿qué sentido tiene codificarla de nuevo? ¿Quién esconde una sala dentro de una base ya secreta? ¿Y a qué fin? Además, para más INRI, usando un cifrado técnicamente tan débil (visiblemente puede que asuste). Por más que buscaba, no le veía sentido.

Cabían dos opciones:

- Que fuese algo involuntario: que se hubiese producido un error en la impresión.
- Que fuese algo intencionado: bien como reto de alguien o para ocultar información.Investigación de campo en Internet

Investigué por Internet acerca de fallos que ocasionasen el cambio de caracteres en la impresión, pero no encontré nada al respecto. Y la verdad es que me parecía algo bastante extraño como para que no hubiese bibliografía al respecto. También podía tratarse de un virus informático o que la universidad usase un sistema de cifrado digital que deja mucho que desear. En el segundo caso, había tres enigmas que resolver: quién, cómo y por qué.

Dado que, tras mi infructuosa búsqueda por la red, me pareció más probable (e interesante por supuesto) la segunda opción, decidí diseñar hipótesis para la misma.

En cuanto al quién, la cosa era bastante evidente: alguien con acceso a esa información (me parecía muy improbable que alguien hubiese diseñado un ataque dirigido para conseguir tal información, máxime teniendo en cuenta que las contraseña no aparecen – por suerte – en la página). Esto reduce bastante la lista a profesores y miembros de administración (suponiendo que ningún alumno haya hecho un listado de este tipo). Y hace aún más difíciles las respuestas al por qué. ¿Para qué iba a querer un miembro del personal de la universidad codificar una hoja así?

Con respecto al cómo, la opción de hacerlo manualmente siempre está ahí, pero la descarté la primera por tratarse de un trabajo de chinos, como se dice, y muy probablemente nadie se iba a tomar ese esfuerzo para nada. También existía la posibilidad de que alguien hubiese creado una fuente tipográfica con estas características, que se hubiese usado un script para cifrarlo, un programa de cifrado para dummies…

Sin embargo, era el por qué lo que más intrigado me tenía. Un amigo mío, que conoce de mi afición por la criptografía y los juegos de ingenio de este tipo, me sugirió que había encontrado a mi alma gemela en esa facultad: alguien a quien le gustaba resolver enigmas como a mí y que lo había colocado allí a ver si alguien era capaz de resolverlo (lo cual era una idea rebuscada pero que a mí me gustaba bastante). Ese mismo amigo me incitaba a que escribiese un mensaje usando el mismo cifrado diciendo que había resuelto el misterio y lo dejase colgado donde encontré el primero (lo cual era bastante difícil, pues no recordaba dónde había sido). Además, ¿qué mensaje secreto podía haber oculto en una lista de clase?

Una resolución fortuita del misterio

Mi teoría se estaba asemejando peligrosamente a los relatos de misterio de Poe. Incluso llegué a pensar que podía tratarse de algún apasionante reto del estilo del recientemente resuelto Cicada 3301. Finalmente y por motivos de falta de tiempo, deseché esa última opción, aunque me hubiese gustado continuar mis pesquisas por ahí. Así que dejé apartado el asunto durante un tiempo. Hasta que unos meses más tarde, ordenando papeles, encontré con algo que me ayudó a esclarecer el asunto. Di con lo siguiente:



Figura 5: Mi piedra rosetta para este misterio

En la comparación de ambas páginas se puede comprobar cómo el número de letras, las líneas y la estructura del documento coinciden tanto en la versión codificada como en la que está en cristiano. Este se trataba (el de la izquierda) de un documento que mi padre me imprimió hace unos años, pero que “por error” quedó impreso así, por lo que luego tuvo que hacer una copia nueva (a la derecha). Y mira por dónde, a este documento le sucedía exactamente lo mismo que a la página misteriosa.

Ya me había topado con eso antes, pero nunca le había prestado atención. Hasta ahora. Esta evidencia viene a confirmar la teoría de que se trata de un bug en algúndriver de la impresora, ya que el suceso ocurrió en dos sistemas completamente distintos.

Tras reportar el fallo de seguridad al organismo correspondiente de la universidad (el sistema de gestión informática), sin obtener hasta el momento respuesta suya, contacté con Juan para contarle acerca del misterioso caso; le pareció interesante y me ofreció la oportunidad de publicarlo en un artículo en JBGTutoriales.blogspot.com.es, por lo que le estoy muy agradecido. ¿Y vosotros habéis tenido alguna experiencia similar? ¿Se os han desordenado las letras al imprimir algún documento?

Un saludo,

Autor: Nacho

lunes, 20 de octubre de 2014

Un fallo de CSRF en Twitter para robarte la cuenta

Los ataques de CSRF (Cross-Site Request Forgery) son conocidos hace bastante tiempo. La idea de ellos es bastante sencilla, y el objetivo es conseguir que una víctima, que tiene una sesión con su cuenta en un sitio web, haga acciones involuntarias en esa sesión al abrir un enlace o cargar un contenido externo.



Figura 1: Un bug de CSRF para robare la cuenta de Twitter

A día de hoy es una de las técnicas de hacking más utilizadas, y en el proyecto OWASP TOP TEN, que recoge los diez ataques más utilizadas en ataques a aplicaciones web y donde siguen reinando las técnicas de SQL Injection y el resto de inyecciones de código, ocupa el octavo lugar.


Una explicación sencilla de CSRF


Para que sea fácil de entender en que consiste el ataque, vamos a suponer una aplicación web para controlar las nóminas de los empleados de una empresa. A esa aplicación web solo puede entrar el administrador y es tan absurdamente sencilla como que hay una lista con los nombres de los empleados junto con dos enlaces a su lado. Uno es un enlace que poner "Subir Sueldo" y otro es un enlace que pone"Bajar Sueldo". Esa aplicación web es tan absurdamente sencilla, que si miramos el código de los enlaces son algo como:
- http://www.server.test/subir_sueldo.php?trabajador=juan
- http://www.server.text/bajar_sueldo.php?trabajador=juan
Cuando se llaman a esos enlaces, lo que sucede es que automáticamente se incrementa o decrementa el sueldo de ese trabajador, en este caso chema, en la base de datos del sistema. Por supuesto, por protección, para que nadie pueda hacer uso de esos procedimientos de incremento y decremento, las aplicacionessubir_sueldo.php y bajar_sueldo.php comprueban que la persona que está enviando esa petición está autenticado como administrador, para lo que es necesario tener una sesión abierta.


El ataque CSRF se aprovecha de esa construcción insegura de enlaces dentro de la aplicación de administración. Es cierto que solo el administrador puede invocarlos, pero si el administrador tiene abierta esa aplicación en una pestaña de su navegador, y en otra tiene abierto su correo electrónico, bastará con enviar un enlace a http://www.server.test/subir_sueldo.php?trabajador=juan para que haga clic en él para que se ejecute la acción. Si el administrador lo pulsa dentro del correo electrónico, entonces se ejecutará la orden de subir el sueldo a chema.


Esa es una forma muy "burda" de conseguir explotar el ataque, pero lo cierto es que si trasladamos esto a enlaces enviados por Twitter o Facebook o simples mensajes de correo electrónico escritos en HTML que cargan la imagen haciendo uso de img src="http://www.server.test/subir_sueldo.php?trabajador=juan".




Figura 2: En el año 2007, el propio Gmail fue víctima de un ataque CSRF que generó un gusano


O mucho peor, imaginad que yo sé que tenéis abierto el Twitter en otra pestaña mientras veis este artículo de http://jbgtutoriales.blogspot.com.es/ y cargo un fichero JavaScript malicioso que, usando vuestra sesión de Twitter, empieza a obligaros a publicar cosas, hacer seguimiento a personas o peor, os cambia la contraseña. Esto no podría ser. Sería un desastre.


Protecciones Anti CSRF


Para solucionar esto, se crean las protecciones Anti-CSRF, que consisten en un control del servidor a la hora de controlar desde donde viene hecho el clic. Es decir, en cada enlace que se muestra en una web, o en cada formulario que se carga en una página para que el usuario puede pulsar se genera un token, que se asocia a ese, y solo ese enlace, de tal manera que cuando el usuario hace clic en él debe ser enviado a al servidor junto con el enlace.



Figura 3: Ejemplo de protección anti-CSRF propuesta en OWASP



En el ejemplo de subir el sueldo, se debería poner algo comohttp://www.server.test/subir_sueldo.php?trabajador=juan&csrfToken=14123423234234. Esto ayudaría a que si el atacante envía un enlace malicioso deba conocer cuál es el valor del token CSRF válido para la ejecución de la aplicación subir_sueldo.php. Si no lo averigua, el servidor no ejecutará el comando. Por supuesto, la recomendación es no usar esostokens CSRF en peticiones GET, ya que los tokens quedarán en historiales de navegación, servidores Proxy, Firewalls, sistemas de registro de eventos, etcétera, por lo que lo mejor es hacerlo cambiando el enlace por un formulario.


El bug de Twitter


Esto es algo que hacen casi todos los sitios webs, y entre ellos se encuentra Twitter. Pero... nada de esto vale, si en el servidor no se valida correctamente el token CSRF. Si se envíe el token que se envíe da lo mismo, entonces volvemos a tener ese problema de que cualquiera pueda hacer lo que le de la gana con tu cuenta si la tienes abierta en otra pestaña.



Figura 4: Token Anti-CSRF en el formulario de añadir número de teléfono a cuenta de Twitter



Este es el caso del formulario que permite añadir un número de teléfono a tu cuenta de Twitter como protección, que tal y como podéis ver en el código fuente, cuenta con un token de protección anti-CSRF llamado authentiticity_token, pero... que se olvidó de validar. Este bug fue descubierto por el investigador colombiano Juan David Castro Dylan Irzi, y lo presentó en la pasada DragonJar Security Conference 2014, con una conferencia que puedes ver online sobre ataques CSRF en general.


Figura 5: Conferencia de Juan David Castro sobre ataques CSRF


En el caso concreto del ataque de Twitter, para robar la cuenta, lo que hay que hacer es enviar un enlace a la víctima. Cuando ella lo abra, se ejecutará el envío del formulario para añadir un número de teléfono a la cuenta de la víctima, tal y como se puede ver en el exploit que publicó. En él, authenticity_token está a null, porque Twitter no lo estaba validando.



Figura 6: Exploit para añadir el número de teléfono sin token CSRF


A partir de ese momento, la cuenta de la víctima estará asociada al número de teléfono del atacante, que podrá robar vía formulario de recuperación de contraseña. Para ello, basta con que el atacante solicite que se le envíe un código de recuperación de cuenta por SMS al número que está asociado a la identidad - que acaba de poner con el exploit de CSRF -. El vídeo completo de la prueba de concepto de cómo se puede robar una cuenta de Twitter por medio de un bug CSRFestá disponible en el siguiente vídeo.


Figura 7: Prueba de Concepto de cómo explotar CSRF en Twitter y robar la cuenta

Por supuesto, Juan David Castro lo reportó a Twitter, que lo solucionó y puso en elHall of Fame por ayudar a que los usuarios no estuvieran expuestos con este bug que en malas manos podría haber hecho mucho daño. Un hacker que encuentra un bug y lo reporta para que los usuarios no estén expuestos sin esperar nada a cambio. Buen trabajo Juan David, tienes mis respetos.


Saludos!

viernes, 17 de octubre de 2014

Latch Plugin Contest: Gana 10.000 USD en BitCoins

Normalmente no suelo publicar nada si no es lunes pero esto os va a interesar...


Ayer durante la segunda edición del Security Innovation Day 2014 desvelamos muchas cosas de Latch, MetasShield Protector, Faast y Path 5, así como la incorporación de las tecnologías y el equipo de SmartAccess dentro de la familia deEleven Paths. Fue un evento para el que habíamos trabajado mucho, e intentamos dosificar la información, pero ahora intentaré durante estos próximos días ir resumiendo por aquí todo lo que allí contamos, y hoy toca comenzar por el Latch Plugin Contest.


Figura 1: Chema's Ocean's Eleven

Desde que lanzamos Latch hace sólo 10 meses, lo que más nos ha gustado ha sido comentar las integraciones y hacks que la gente hacía con la tecnología. Algunos son plugins hechos para entornos que nosotros no tenemos dentro de los plugins y SDK oficiales, otros son hacks mucho más curiosos que incluso implican la integración de hardware. En la siguiente lista os dejo algunas de las cosas que la comunidad ha hecho con la plataforma Latch.

- Integración de Latch en un servicio FTP
- Demonizando Latch para proteger archivos con dos llaves
- Plugin de Latch en Synfony2
- Controlar un cerrojo físico con Latch + código
- Controlar reglas de IPTables con Latch
- Integración de Latch en SCCAID
- Hack de integración de Latch como Windows Gina
- Plugin de Latch para Laravel (se hicieron 2 distintos)
- Empujando a Latch fuera de Matrix: Controlando conexiones BlueTooth
- Plugin de Latch para Django
- Hack para controlar múltiples WordPress con Latch
- Cómo controlar puertos USB con Latch en OS X
Tanto nos gusta esto, que decidimos hacer un concurso-competición para premiar las mejores ideas, que hay mucho que se puede "Latchear". ¿Tú SmartTV? ¿TusXBOX? ¿Un sistema para controlar el volumen de tu portero para evitar que te molesten por la noche? ¿Un hack para controlar las sesiones de Facebook? ¿Desconectar sesiones de una web matando cookies con Latch? ¿Controlar la publicación de secretos en la web con Latch? El límite lo pones tú, pero queríamos premiarlo, por eso lanzamos Latch Plugin Contest.



Figura 2: Latch Plugin Contest


Se podrá presentar cualquier trabajo realizado, no importa si es tu Trabajo Fin de Carrera, Trabajo Fin de Máster, si es un hack que has hecho en tu casa, un pluginque necesitabas para una integración, el uso de Latch con un producto comercial, o similares. También puedes trabajar en equipo, aunque solo habrá una candidatura para el premio, pero puedes hacer algo con tus compañeros para que sea más sorprendente. Desde Eleven Paths solo queremos premiar a los mejores con 10.000 USD, 5.000 USD y 1.000 USD que serán pagados en BitCoins.




Figura 3: Premios del Latch Plugin Contest

Todos los SDK de Latch son Open Source, el 99% de los plugins también son Open Source, toda la API de Latch está documentada en la web de developers y en los artículos que te he publicado tienes ejemplos de código, con lo que sumando todos los recursos tienes información suficiente para comenzar a integrar Latch. Además tienes un artículo que explica en detalle el concepto de Latch con arquitecturas y casos de uso posibles y una lista de vídeos con ejemplos de uso de Latch.



Figura 4: Fecha límite para entrega de los plugins & hacks con Latch


Además, si eres un estudiante, o no tienes empleo, podrás tener una beca de 6 meses trabajando en Eleven Paths con nuestro equipo y... luego quién sabe. Tal vez seas parte del equipo que desarrolle el nuevo Path 6 al fin y al cabo. Toda la información del concurso lo tienes en la web de Latch Plugin Contest.

Saludos Malignos!

Autor: Chema Alonso

lunes, 13 de octubre de 2014

Crear una JavaScript Botnet con dispositivos Android

El día 1 de Septiembre se hizo noticia la vulnerabilidad publicada por el investigadorRafay Baloch detectada en dispositivos Android previos a la versión 4.4, que había sido identificada con el CVE-2014-6041. En ésta se reporta que el componenteWebView de versiones anteriores al framework 4.4 permiten la evasión de su mecanismo de seguridad SOP (Same Origin Policy o Política del Mismo Origen), que es un control que deben implementar los clientes web para limitar que sólo ante determinadas circunstancias un documento web pueda cargar o modificar código en otro si estos están ubicados en orígenes diferentes.



Figura 1: Dispositivos Android vulnerables a bug del XSS Universal

El alcance de esta vulnerabilidad es notable ya que se estima que actualmente en torno al 75% de los dispositivos Android se encuentran en versiones anteriores a la4.4, y en estos dispositivos suele estar instalado de serie el cliente Web Android Open Source Browser, el cual implementa este componente WebView vulnerable, y además el bug no se reduce únicamente a este componente, ya que como se ha hecho público en otros estudios realizados existen más clientes web vulnerables como Maxthon Browser o CM Browser.




Figura 2: Cuota de mercado de versiones de Android

En cuanto a la vulnerabilidad reportada, cabe destacar lo simple que es realizar una explotación como Prueba de Concepto ya que lo único que hace falta para evadir elSOP en este componente es incluir un byte nulo en un manejador con el código que queremos ejecutar en el contexto del origen de destino:



Figura 3: Inserción del null byte \u0000 para lograr el salto de SOP

Si accedemos a la página con el código anterior desde un navegador que contenga este componente vulnerable veremos cómo somos capaces de ejecutar el scriptinsertado en el manejador onclick.



Figura 4: Código ejecutado saltándose la política SOP

Este método podría ser usado tanto para extraer información como el contenidoHTML de una página web desde la sesión de un usuario, el envío de formularios sin el consentimiento del usuario, o ataques de session hijacking, entre otros.



Figura 5: Explotación del bug desde Metasploit sobre una distribución Kali Linux

Sea como sea la historia de esta vulnerabilidad no acabó en su publicación y desde el día 7 de Septiembre disponemos de un módulo para Metasploit que en su configuración por defecto extraerá la cookie y el contenido HTML que el usuario ve al acceder a la página web.



Figura 6: Extracciíon de la cookie de sesión con el módulo de Metasploit

Es interesante destacar las opciones adicionales que incluye el módulo, ya que nos permitirán jugar con certificados, ejecutar nuestro propio código script si lo definimos en la opción del módulo CUSTOM_JS. Es en este punto donde los más juguetones están aprovechando para mediante una campaña, por ejemplo de spamenviado a usuarios de versiones Android vulnerables, cargar otros scripts tan interesantes como BeEF para hacerse una JavaScript Botnet de dispositivos Android, además de ofrecer otros mecanismos menos sutiles para hacer por ejemplo evasión de las cabeceras X-Frame-Options.



Figura 7: Inyección de scripts personalizados de control

Si a este grave fallo de seguridad le sumamos la fragmentación de la plataformaAndroid y el abandono por parte de proveedores de dispositivos y adaptaciones del sistema operativo, nos damos cuenta de que estamos ante una situación muy complicada ya que aunque se han publicado parches para corregir este fallo (aquíaquí) un alto porcentaje de dispositivos no serán actualizados y mantendrán esta vulnerabilidad.

Autor: Miguel Ángel García (@nodoraiz)
Developer en Eleven Paths

lunes, 6 de octubre de 2014

Cómo te espía tu centro comercial por WiFi y BlueTooth



Desde hace años, las técnicas de Business Intelligence, Data Mining y el algo más reciente concepto de Big Data buscan la forma de ganar dinero con toda la información que sea posible atesorar. Los centros comerciales, lugar donde trabajan grandes vendedores, saben que la información es dinero, y por eso se estudian las ofertas, los packs, la colocación de los productos, el diseño de los paneles, etcétera, basándose en todos los datos que están a su alcance y que son capaces de obtener en sus instalaciones.



Figura 1: Personas, smartphones, redes WiFi y conexiones BT en un Centro Comercial



Desde la cuánto, cómo y a qué horas se llenan las plazas de aparcamiento o qué modelos de coches y con cuanta antigüedad pasan por la barrera del parking. Cuánto tarda una persona en comprar desde que aparca y se va, las cantidades que compra, con qué medio de pago lo hace, qué banco es el que utiliza, qué tipo de cantidades se hace en efectivo, los productos, la relación que hay entre esos productos y el tipo de vehículo y día del mes, etcétera. Toda esa información es útil para generar el mejor catálogo de productos, y poner el descuento en el sitio adecuado, a la hora adecuada, el día adecuado y conseguir maximizar la ganancia.

En algunos sitios - yo esto lo he visto en el Leroy Merlin - te hacen además encuestas, e incluso hay algunos que te piden el código postal para saber desde qué ubicación vienes. Son datos que si el cliente se los da libremente y ellos pueden asociarlos a la compra podrán utilizar para mejorar su sistema.

Por supuesto, entre los tipos de datos que son de interés se encuentra también la información relativa a cómo se mueven los clientes dentro del centro comercial, para ver si hay zonas calientes, zonas con poco tráfico o mal señalizadas, y cómo influye la colocación de la mercancía en la venta en función de los tiempos y distancias que es capaz de recorrer un cliente dentro del espacio de la tienda. ¡Qué se lo digan a IKEA!

Nomofobia: Tú vas donde va tu smartphone

Para hacer seguimiento del movimiento de los clientes se pueden utilizar las populares cámaras de seguridad usando sistemas de reconocimiento de personas automático para poder alimentar esa base de datos o técnicas más modernas y sencillas de implementar, como seguir la ubicación de los dispositivos smartphone y la información que generan sus conexiones a redes WiFi o BlueTooth. La mayoría de los compradores llevan su teléfono consigo, si no no estaríamos hablando del síndrome de abstinencia de la falta del móvil: Nomofobia.



Figura 2: Los compradores llevan su smartphone siempre encima



Utilizar un dispositivo smartphone para seguir a un usuario dentro de una tienda tiene las ventajas de que no solo puedes seguir por dónde se mueve un determinado cliente, sino además tendrías la información de qué dispositivo tiene para tener un perfil más completo de ese cliente, del que podrías tener la marca de su coche, su modelo, su tipo de dispositivo móvil, lo que ha comprado, cuánto se ha gastado y cómo suele comprar. Todo con el objeto de maximizar su satisfacción con la tienda y hacer las ofertas más a medida para maximizar el rédito económico a largo plazo.

Seguir a un dispositivo smartphone es tan sencillo como poner puntos de accesoWiFi que vayan reconociendo las direcciones MAC de las peticiones de búsqueda de redes WiFi, pero también vale con sniffers que escuchen el tráfico de red para ver dónde están siendo emitidos los paquetes. Es decir, no solo con los mensajes deProbe Request para buscar redes inalámbricas se puede hacer esto, sino que si el cliente está conectado a una red ya, se podría analizar desde qué puntos se están emitiendo los paquetes.

Mensajes WiFi Probe Request

El capturar el tráfico de los paquetes Probe Request es especialmente significativo, ya que un terminal emite esos paquetes en busca de las redes que conoce, adjuntando en cada uno de los paquetes el SSID - nombre de la red - WiFi que busca. Así, si una persona tiene metido en el historial de su iPhone o su Android una lista de cinco redes WiFi (la del trabajo, la de casa, la de la cafetería de al lado de trabajo o la del dentista), estará enviando en esos mensajes de Probe Request todos esos datos, permitiendo que el centro comercial los pueda asociar a su dirección deMAC, su tipo de dispositivo móvil, junto con la marca y año de fabricación del coche, su compra, etcétera.



Figura 3: Mensajes Probe Request generados por un iPhone buscando redes WiFi



La gracia de tener los SSID, es que además se podrá saber, utilizando las bases de datos de WarDriving, la ubicación GPS de cada una de esas redes inalámbricas, lo que ayudará a saber dónde vive, dónde trabaja o dónde va al dentista. Y si además sus redes inalámbricas tienen sus nombres por defecto, se podría saber qué operador de comunicaciones es el que tiene contratado en su casa.

La WiFi gratis

Como ya he dicho, no solo se puede hacer con los mensajes de Probe Request de un dispositivo cuando va buscando redes WiFi a las que conectarse. Si se conecta a una de nuestras redes, se podrá acceder a mucha más información de la navegación de ese cliente, pero también al envío de búsquedas DNS, Bonjour (MDNS) o al reporte de las redes WiFi a Apple o Google, tal y como hacen iOS y Android.



Figura 4: iSniff GPS pinta en el mapa la ubicación de los SSID de un iOS capturados por la WiFi



Esto está documentado y estudiadísimo, y existe una herramienta llamada iSniff GPSque saca los mapas de conexión de un cliente con iPhone para saber dónde se conecta a redes WiFi. Pero no solo eso, como ya se vio con WhatsApp Discover, podrían saber hasta tu número de teléfono.

Las conexiones BlueTooth

Además de WiFi, los dispositivos móviles también utilizan BlueTooth para conectarse al sistema de manos libres del coche o al altavoz del cuarto de baño, pulsómetro o lo que sea. El tener activado el descubrimiento de dispositivos en unsmartphone hace que se estén enviando señales para conectarse que pueden ser monitorizadas para generar también datos de seguimiento y movimiento.



Figura 5: Direcciones WiFi y BlueTooth en iOS. En muchos casos consecutivas.



En el caso de iOS es aún más curioso, ya que las direcciones MAC de la red WiFi y la dirección MAC de BlueTooth son generadas de forma consecutiva en muchos de los casos, lo que permite que, conociendo una, puedas predecir con un alto grado de probabilidad la otra.

Conclusiones

Es decir, que ya no sería necesario preguntarte en qué código postal vives, ya que con un análisis de tus conexiones WiFi y BlueTooth un centro comercial, una empresa o cualquier curioso podría añadir a su colección de datos mucha más información tuya. Yo por eso, tengo la manía de apagar todas las conexiones inalámbricas cada vez que salgo de casa, y el BlueTooth en cuando me bajo del coche, y solo las activo por necesidad puntual, pero no las llevo encendidas nunca.

Ahora Apple, conocido todo el revuelo que se formó con la publicación de iSniff-GPSy pensando en que se quieren meter en el negocio de los pagos con Apple Pay (de hecho creo que ya están dentro) quieren limpiar cualquier resquicio de dudas de que ellos quieren tus datos. "Nosotros vendemos grandes productos, no tus datos", ha dicho Tim Cook. Le ha faltado decir que los venden muy caros, pero lo cierto es que los venden sí o sí.



Figura 6: Anuncio de Apple del uso de MAC spoofeadas en mensajes Probe Request



Coincidiendo con esto, en la última presentación de iOS 8, Apple anunció un detalle que a mí se me pasó por alto, y que mi compañero Juan Luís en Eleven Paths me apuntó. Esta nueva característica es la de hacer que los mensajes Probe Request de redes WiFi se harán con direcciones MAC spoofeadas, para evitar el seguimiento de direcciones MAC y redes WiFi pero también para ocultar el fabricante del dispositivo, y hacer que los usuarios de iPhone no vayan descubriendo esa información alegremente.

Ahora acaba de sacar iOS 8, y nuestra misión será ver cómo se ha implementado esta característica, para ver si es útil, privada y segura, pero lo que si ha quedado claro y constatado es que la propia Apple confirma que estas técnicas de vigilancia se están haciendo masivamente, por lo que yo sigo apagando mi WiFi, mi BlueTooth y cualquier otra comunicación en caso de dudas.

Saludos!