Con el eslogan ‘Easy for People. Hard for Bots’, Google introdujo reCaptcha (tras su compra) como uno de sus servicios con el fin de evitar la automatización del envió de formularios (registros, soporte…). Siendo a día de hoy uno de los captchas más extendidos por la web, su versión 2 ha sido uno de los más complejos y difíciles de atacar con éxito. Es por ello que desde ElevenPaths, y aprovechando nuestra ya clásica jornada de Equinox (nuestro Hackathon interno de 24h), nos propusimos al menos investigar, y porque no, resolver automáticamente reCaptcha.
Aunque 24 horas no parecen muchas, la investigación acabo en una automatización completa de la resolución de este servicio, aunque con una tasa de acierto no demasiado grande. Para ello nos basamos en la característica de accesibilidad del servicio, con el que el reto visual desaparece y presenta un nuevo reto auditivo, es decir, mediante audio, se pronuncian cinco dígitos (en inglés) con voces de diferentes personas y múltiples dialectos. Y ya que Google ofrece un servicio de reconocimiento de voz… ¿Por qué no utilizarlo?
La automatización no fue sencilla ni mucho menos, ya que pudimos comprobar algunas y deducir otras medidas de seguridad que Google emplea en reCaptcha:
Una de las ventajas del servicio de reconocimiento es que permite especificar palabras como sugerencias para la detección, y en este caso facilitaba la tarea, ya que, indicando los dígitos del cero al nueve la tasa de aciertos es bastante elevada. Aun así, y para mejorar esta tasa de aciertos, aplicamos diferentes tratamientos de audio, como por ejemplo igualar la duración de los silencios o reducir su velocidad.
Resultados obtenidos
Una vez el sistema funcionaba, y tras aplicar ciertas mejoras en el cliente para detectar la posición del objeto reCaptcha en la web independientemente de la posición del navegador, tomamos muestras del comportamiento de la solución.
Tras 1172 pruebas, 328 fueron resueltas directamente (el primer click lo considera “humano”), y de las 844 restantes el 92% fueron resueltas automáticamente mediante el desafío de audio. Lo más interesante de esto, es que a pesar de que la muestra de audio del desafío sean 5 dígitos, reCaptcha lo considera válido únicamente con 3 de ellos correctos. Es por ello que la tasa de acierto sea tan alta, y probablemente un ejemplo más de usabilidad frente a seguridad.
El paper que no se publicó a tiempo
Han pasado unos 5 meses desde ese Equinox, en el que estuvimos depurando y mejorando la solución, a la vez que escribíamos un paper para presentarlo en varios congresos de seguridad. Este fue el paper que redactamos hace unos meses, pero... ..finalmente, no será posible presentarlo ya que hace aproximadamente 15 días hicieron una publicación con la misma idea, y por lo visto Google ha tomado cartas en el asunto mejorando el desafío de audio. Más información en esta publicación.
Sin embargo, como una de las ideas de implementación - que hicimos como una extensión de Google Chrome que íbamos a correr en un Google ChromeBook para que fuera más redondo todo - decidimos que quedaría chulo si nuestro entrañable Clippy iba explicando paso a paso todo el proceso... y aquí está el vídeo que grabamos en su momento como PoC saltándonos reCaptcha en El lado del mal.
Al final, lo que tiene la investigación es que el primero que lo publica es el primero que lo publica. Nosotros tardamos mucho en sacarlo y ya será tarde, pero... nos lo pasamos genial haciendo el trabajo, así que continuaremos con el mismo espíritu de hacer algo chulo en el próximo Equinox. Os seguiremos contando.
Autores: Óscar Bralo, Álvaro Nuñez-Romero & Ioseba Palop @ElevenPaths
 |
| Figura 1: Hacking Google reCapthca with Google Voice Recognition ... and Google Chrome in a Google ChromeBook |
Aunque 24 horas no parecen muchas, la investigación acabo en una automatización completa de la resolución de este servicio, aunque con una tasa de acierto no demasiado grande. Para ello nos basamos en la característica de accesibilidad del servicio, con el que el reto visual desaparece y presenta un nuevo reto auditivo, es decir, mediante audio, se pronuncian cinco dígitos (en inglés) con voces de diferentes personas y múltiples dialectos. Y ya que Google ofrece un servicio de reconocimiento de voz… ¿Por qué no utilizarlo?
 |
| Figura 2: Opción de verificar por audio de dígitos en ReCaptcha |
La automatización no fue sencilla ni mucho menos, ya que pudimos comprobar algunas y deducir otras medidas de seguridad que Google emplea en reCaptcha:
• La detección de clicks simulados mediante herramientas o frameworks de navegador.
• Pausas de diferente duración entre la pronunciación de los dígitos, incluso con velocidades distintas.
• La velocidad en la introducción de la solución y su verificación.Para enfrentarnos a la problemática, optamos por una solución cliente-servidor, siendo el cliente un plugin del propio Google Chrome, y un servicio REST encargado de descargar el audio, enviárselo al servicio de reconocimiento de Google, y además de esto, simular los clicks de ratón y la pulsación de teclas utilizando llamadas nativas del sistema operativo.
Una de las ventajas del servicio de reconocimiento es que permite especificar palabras como sugerencias para la detección, y en este caso facilitaba la tarea, ya que, indicando los dígitos del cero al nueve la tasa de aciertos es bastante elevada. Aun así, y para mejorar esta tasa de aciertos, aplicamos diferentes tratamientos de audio, como por ejemplo igualar la duración de los silencios o reducir su velocidad.
Resultados obtenidos
Una vez el sistema funcionaba, y tras aplicar ciertas mejoras en el cliente para detectar la posición del objeto reCaptcha en la web independientemente de la posición del navegador, tomamos muestras del comportamiento de la solución.
 |
| Figura 4: Resultados de las pruebas realizadas |
Tras 1172 pruebas, 328 fueron resueltas directamente (el primer click lo considera “humano”), y de las 844 restantes el 92% fueron resueltas automáticamente mediante el desafío de audio. Lo más interesante de esto, es que a pesar de que la muestra de audio del desafío sean 5 dígitos, reCaptcha lo considera válido únicamente con 3 de ellos correctos. Es por ello que la tasa de acierto sea tan alta, y probablemente un ejemplo más de usabilidad frente a seguridad.
El paper que no se publicó a tiempo
Han pasado unos 5 meses desde ese Equinox, en el que estuvimos depurando y mejorando la solución, a la vez que escribíamos un paper para presentarlo en varios congresos de seguridad. Este fue el paper que redactamos hace unos meses, pero... ..finalmente, no será posible presentarlo ya que hace aproximadamente 15 días hicieron una publicación con la misma idea, y por lo visto Google ha tomado cartas en el asunto mejorando el desafío de audio. Más información en esta publicación.
 |
| Figura 5: Breaking Google's ReCaptcha v2 using.. .Google |
Sin embargo, como una de las ideas de implementación - que hicimos como una extensión de Google Chrome que íbamos a correr en un Google ChromeBook para que fuera más redondo todo - decidimos que quedaría chulo si nuestro entrañable Clippy iba explicando paso a paso todo el proceso... y aquí está el vídeo que grabamos en su momento como PoC saltándonos reCaptcha en El lado del mal.
Figura 6: El vídeo de la PoC con la ayuda de Clippy
Al final, lo que tiene la investigación es que el primero que lo publica es el primero que lo publica. Nosotros tardamos mucho en sacarlo y ya será tarde, pero... nos lo pasamos genial haciendo el trabajo, así que continuaremos con el mismo espíritu de hacer algo chulo en el próximo Equinox. Os seguiremos contando.
Autores: Óscar Bralo, Álvaro Nuñez-Romero & Ioseba Palop @ElevenPaths
No hay comentarios:
Publicar un comentario