25 septiembre 2012

Ekoparty 2012 - Crónica del Día 2 - #ekoparty2012




Seguimos con las diferentes charlas del segundo día de la edición 2012 del congreso EkoParty celebrado en Buenos Aires.

Por la mañana no pude asistir con los cinco sentidos hasta el momento de mi charla, por lo que describiré aquellas charlas en las que estuve íntegramente.


Welcome to your secure /home, $user!



Presentada por quien escribe este post, para la EkoParty quise explicar, además de las nuevas funcionalidades de Skynet, cómo lo he tenido que modificar para adaptarlo a las bajas prestaciones de mi Raspberry Pi! Sí, para aquellos que me preguntáis qué he hecho con el Raspberry Pi en todo este tiempo, prácticamente la totalidad de la funcionalidad de Skynet, excepto la grabación de movimiento, así como la detección facial, he movido el core de Skynet al juguetito de 35 dólares. Además he incorporado diversas funcionalidades domóticas, como bajar persianas y toldos mediante tecnología X-10 (siempre y cuando no llueva y no haya viento, según detecte mi estación meteorológica), así como funcionalidades de seguridad, cómo un modo vacaciones que aleatoriamente baja persianas y toldos (teniendo en cuenta las mismas premisas de antes) simulando que la casa está habitada, o el modo surveillance para la monitorización de la ubicación de mi coche por GPS, de manera que si aparco en un sitio del que no me fío y lo activo, al cambiar las coordenadas detectadas (dentro de un margen), me enviará notificaciones indicando que el vehículo se ha (o lo han) movido.

Por las manifestaciones de alegría que he visto por twitter, y que así me expresaron muchos asistentes, tengo la satisfacción del deber cumplido habiendo hecho una charla que agradó al público.  


4140 ways your alarm system can fail



El americano Babak y su compañero Keith, nos enseñaron TODO sobre el funcionamiento de las alarmas, los internals de la comunicación entre los sensores y la central, como resultado de su investigación. Es decir, las señales intercambiadas a través de un bus único compartido por los módulos de la central. Así lograban interceptar la contraseña introducida, mostraron en tiempo real una herramienta para hacer fuerza bruta de forma automática obteniendo contraseñas de usuarios válidos, e hicieron demostraciones en vivo con sistemas de alarma y diferentes teclados, con los que introducían códigos de forma remota. Como para replantearse si los sistemas de alarma profesionales son tan seguros como las centrales de alarma nos intentan vender.


VGA Persistent Rootkit



Los argentinos Diego Juarez y Nicolas Economou, dieron una genial charla, en la que flasheaban tarjetas de video, que ejecutaban código en los puntos que ellos deseaban. Mostraron ejemplos en los que añadían diversos gráficos en cualquiera de las pantallas mostradas por un ordenado desde la BIOS, el arranque de Windows, etc,… 





Mostraron incluso el flasheo de una tarjeta de video VGA de forma remota y como se puede ver, de forma persistente, aunque me despisté en la parte en la que explicaban, cómo hacían para inyectar el rootkit.



Dirty use of USSD codes in Cellular network



Tocó el turno a una de las charlas más esperadas, la de Ravi

Partió explicando lo que es un servicio USSD… es decir, servicios intercambiados entre un servidor y terminales móviles. Aunque hay diferentes servicios de datos interactivos, como mobile banking o incluso Twitter, mediante la utilización de SMS para enviar tweets, etc,.. ofrecidos por operadores en determinados países. Puso como ejemplos la India, Argelia, Nigeria o Sudáfrica, en los que se utilizan de manera habitual para mobile banking, poder consultar saldo, recargas, etc,...

Explicó la arquitectura utilizada normalmente por los operadores para proveer estos servicios, así como el resultado del análisis de la comunicación utilizada, demostrando así las debilidades que tienen este tipo de servicios.

En general, es posible desplegarlos a través de Internet, publicándolos en un servidor web.

La primera parte que explicó, es algo documentado en el RFC de telefonía correspondiente, y es que si se introduce erróneamente, 10 veces el código PUK de una tarjeta SIM, ésta queda directamente K.O. siendo necesario solicitar una nueva SIM en el operador de teléfono correspondiente.

Así fue como liberó una vulnerabilidad existente en Android por la que, al invocar al método TEL:[número] hace que Android llame a ese número, o ejecute ese servicio USSD, sin comprobar nada más.

Ahora sólo falta encontrar una forma por la que el usuario acceda a este enlace: Mediante ingeniería social, phising, redes sociales o el mismo whatsapp, es bastante sencillo hacer una campaña de Spam con un enlace acortado por ejemplo, que redirija a una web que contenga un servicio USSD especialmente creado para forzar 10 veces el cambio de PUK.

De hecho, Ravi puso a disposición de quien así lo quiera un servicio para comprobar si tu teléfono es vulnerable o no a este problema de ejecución automática.

Si descargáis el contenido del fichero html, os aparece algo como esto, dentro del contenido HTML:

frame src="tel:*%2306%23"

Es decir, que escribís un número en formato USSD, de manera que o llame a un número, o ejecute el USSD que queramos.

En la implementación de los teléfonos Samsung, además es posible mediante la recepción de un inocente WAP PUSH SMS, no requiriendo interacción del usuario. Además, en los dispositivos Samsung Galaxy (I, II y III) existe un código USSD para dejar el dispositivo "de fábrica".




Ravi mostraba en tiempo real cómo se formateaba su Galaxy S III en 3 segundos, sin posibilidad de cancelación por parte del usuario, así como la inutilización de la tarjeta SIM. Para este ejemplo, utilizó un código QR leído con una aplicación con esta funcionalidad popular para Android, aunque podría haberlo recibido mediante un SMS con WAP o cualquier otro mecanismo de los indicados (aunque requeriría una mayor interacción con el usuario).


Es decir, si combinamos ambos ataques, con la ejecución del USSD de introducción del PUK erróneo 10 veces, inutilizando la SIM, pasaremos de tener un "smartphone" a que sea sólo "smart". Además, con el reseteo a configuración de fábrica, nos quedaríamos sin datos personales que poder utilizar en el dispositivo.

Imaginad lo que podría llegar a pasar si alguien se comprase un super bono de envío de SMS a todos los números de teléfono de cualquier país. Habría una denegación de servicio tremenda en las tiendas de los operadores porque la gente se quedaría sin SIM... y a las compañías telefónicas además perderían un montón de dinero por gente que no podría usar el teléfono hasta que comprase una SIM nueva.

Además, en los dispositivos de la marca coreana, es posible la combinación de esta vulnerabilidad mediante tags NFC (Next Field Communications).

Esto es lo que pude entender de la exposición hecha por Ravi, en un rapidísimo inglés con un marcado acento indio, que estoy seguro que hizo incluso dudar al equipo de traductoras simultáneas del evento.

UPDATE: Gracias a @Spamloco por el video con la demo que hizo Ravi


The CRIME Attack 



Y por fin llegó la charla más esperada, que como es costumbre en Ekoparty, dejan como broche de oro para culminar el evento: la charla impartida por Juliano Rizzo y Thai Doung, en la que se presentaría CRIME, la evolución de BEAST, como mecanismo para ser capaz de robar cookies de sesión, pero a través del tráfico HTTPS.

Inicilamente, Juliano introdujo de una forma muy muy sencilla y asequible los requisitos para que un ataque con CRIME sea efectivo: hay que estar en un entorno en el que se puedan dar condiciones para efectuar un ataque Man in The Middle; además has de visitar un enlace malicioso preparado para CRIME. 

Las siglas de Crime son: Compression Ratio Info-Leak Mass Explotaition. Se confirmaba entonces que, efectivamente, el fallo venía en algún punto de la implementación de los algoritmos de compresión utilizados por HTTP, que permitirían descrifrar tráfico HTTPS y permitir extraer cookies de sesión. Básicamente, Juliano explicó cómo haciendo un tcpdump de tráfico SSL/TLS, se puede ver en texto claro la longitud de lo que se pide y lo que se recibe. Es en base a esto. Según indicaron, BEAST abrió la puerta a CRIME, en el sentido que en ambos casos se hace mediante texto plano y se hace uso del URL Path para descifrar las cookies; aunque difieren en que con CRIME se descifran las cookies por no estar cifrada la longitud de las peticiones y respuestas dentro del SSL, en vez de aprovecharse de una vulnerabilidad del modo CBC con encadenamiento de IVs.

El ataque se presentó como algo muy rápido, dado que con ver pasar una media de 6 peticiones para descifrar 1 byte de cada cookie, siendo efectivo sobre navegación realizada en Firefox y Chrome. 

El ataque funciona el 100% de las veces en los servidores que implementen SPDY, como Gmail o Twitter, y un 40% de las veces en aquellos que usan SSL/TLS, como Github o Dropbox.  

Igualmente indicaron que el ataque es viable para TLS también por lo que aquellos protocolos que hagan uso de TLS, como OpenVPN por ejemplo, podrían ser vulnerables también.

En el momento de mostrarlo en modo live, no se sabe si por efecto del efecto demo, o por si ciertas modificaciones de última hora que llevó a cabo Thai sobre el código fuente del programa, no fue posible verlo en funcionamiento. Pese a todo, la credibilidad de Juliano y Thai, junto al video introductorio que corría por la red la semana antes del evento, nos hicieron aplaudir con fuerza la investigación criptográfica de estos dos geniales profesionales.

Las fotos de este post han sido por cortesía de @golmatt

12 comments :

Alejandro Eguía dijo...

Hola Lorenzo, tu charla estuvo muy buena! La verdad es que has montado la casa que todo geek o hacker quiere tener jaja, espero que Skynet no se revele un día de estos y te deje afuera xD


Sobre la charla de Ravi, muy buena la explicación... durante las demos que realizó grabé un video, lo dejo para los que quieran verlo: www.youtube.com/watch?v=Q2-0B04HPhs

Lorenzo_Martinez dijo...

Hola Alejandro!
para mí fue un placer desvirtualizarte. Menos mal que el barco pudo partir ;D
A Skynet lo tengo controlado, aunque si un día aparece un mensajero del futuro con un arma para protegerme, ya tendré claro por qué es jejeje


Muchas gracias por el video! Nos vemos en la siguiente. Un abrazo

PacoRamirez dijo...

Supongo que esta es la entrada está relacionada con el RIP a android. Ciertamente es una vulnerabilidad bastante grave, pero que según veo requiere la aceptación del usuario para la ejecución de susodichos códigos. Como comentas, probablemente enviando un bono masivo, muchos caerían en la trampa de permitir la ejecución.


Sin embargo, he de decir que no es una vulnerabilidad que vaya a mandar a Android al RIP, ni algo que no pueda arreglarse con una actualización. Tampoco es lo que se comentaba en el post anterior de que te deje el telefono como un pisapapeles...al fin y al cabo una sim cuesta 6€.


En resumidas cuentas, pese a que, efectivamente es una vulnerabilidad grave, considero que se vendió con demasiado entusiasmo para lo que al final resultó ser. Si iOS no murió con las vulnerabilidades a través de la simple descarga de un pdf, intuyo que esto también se podrá subsanar.


Por otro lado, y en la línea de lo que comentaban otros en el post anterior, considero que esto debiera ser informado con anterioridad a la divulgación, por razones obvias. Ahora la veda esta abierta a que alguien lo utilice para el mal hasta que finalmente se subsane.

Lorenzo_Martinez dijo...

Paco, en el caso de los Samsung NO es necesaria la aceptación de nada. Vía SMS con WAP, por defecto, se ejecuta...
No es que mande Android al RIP, pero para mí tener un Teléfono móvil que la SIM queda inservible, es quedarse sin teléfono (vamos, que ni puedes recibir ni emitir llamadas) Efectivamente la SIM cuesta 6 euros, pero si te hacen llegar el enlace con veneno desde diferentes métodos, igual hasta caes en más de uno. Que puedes seguir hablando por Viber y recibir mensajes por whatsapp, pues sí, pero que la funcionalidad principal de un teléfono móvil, es seguir hablando por teléfono, con esta vulnerabilidad, el dispositivo pasa a ser RIP.


Que además tienes un Samsung Galaxy, pues además te quedas con el dispositivo de fábrica, porque precisamente estos dispositivos tienen un código USSD que al ejecutarlo hace el Reset Factory Defaults.
Evidentemente se puede arreglar con una actualización: SI... y si aún no está, estará! como sucede con cualquier vulnerabilidad subsanable por un fabricante. Incluso, Ravi decía que la auto-ejecución por defecto cuando llega por SMS, puede hacerse deshabilitando el "Service Loading"... y efectivamente ahí, tienes que hacer click en un enlace malicioso que ejecute el USSD de bloqueo de SIM por poner el PUK mal 10 veces (y el reset to factory si además es un Samsung)
Ravi también indicó que Google había sido notificado convenientemente sobre ello.

DeTopo dijo...

Gracias por la crónica ;)

Elbuenedd dijo...

Gracias por las noticias!!! muy interesantes!!!sin duda alguna muy buena la web.... Saludos.

Tito dijo...

Lorenzo, EXCELENTE tu charla estuvo genial! espero que puedas continuar con el control de Skynet!
Sobre la charla de Ravi, excelente la explicación.



Un Abrazo!

Marcos Gimeno dijo...

Lorenzo, hay alguna posibilidad de ver tu charla en video? Gracias.

DoLpHiN dijo...

He probado a acceder a una página creada por mi con el código malicioso
poniendo un teléfono cualquiera, y he de decir que el teléfono no llama
automáticamente, no se si estaré haciendo algo mal. Pero lo único que
hace es poner el número en el teléfono, listo para llamar pero sin
iniciar la llamada.
Alguien ha conseguido que le realice la llamada automáticamente. De todas formas muy interesante la información.
Saludos

Lorenzo_Martinez dijo...

Muchas gracias Tito!

Lorenzo_Martinez dijo...

Pues, hay un video de 30 minutos de duración, que está bastante bien grabado por una asistente. No lo he querido enlazar aún al no estar completo. Tengo fe que la organización de Ekoparty, este año publique los videos antes de lo habitual :D

Camaron dijo...

Yo tambien he probado con el iframe y se marca pero no se ejecuta solo. De todas maneras con el chrome y con opera ni llegaba a ejecutar el "tel:", lo tienen bloqueado por defecto.