El (Test de Turing Público Completamente Automatizado para Diferenciar Ordenadores y Humanos), fue diseñado originalmente para evitar que los bots, el malware y la inteligencia artificial (IA) interactuaran con una página web. En los años 90, esto significaba evitar los bots de spam. Hoy en día, las organizaciones lo utilizan para intentar evitar ataques automatizados más siniestros, como el relleno de credenciales.
Sin embargo, casi tan pronto como se introdujo, los ciberdelincuentes desarrollaron métodos eficaces para eludirlo. Los buenos respondieron con s «endurecidos» pero el resultado sigue siendo el mismo: la prueba que intenta detener la automatización es burlada con la automatización.
Hay múltiples formas de ser derrotado. Un método común es utilizar un servicio de resolución, que utiliza mano de obra humana de bajo coste en países en desarrollo para resolver imágenes. Los ciberdelincuentes se suscriben a un servicio para obtener soluciones, que se incorporan a sus herramientas de automatización a través de APIs, poblando las respuestas en el sitio web objetivo. Estas empresas turbias son tan ubicuas que muchas pueden encontrarse con una rápida búsqueda en Google, incluyendo:
- Deathby
- 2
- Kolotibablo
- ProTypers
- Antigate
Este artículo utilizará 2 para demostrar cómo los atacantes integran la solución para orquestar ataques de relleno de credenciales.
2
Al acceder al sitio 2.com, el visitante es recibido con la siguiente imagen, en la que se le pregunta si desea 1) trabajar para 2 o 2) comprar 2 como servicio.
Opción 1 – Trabajar para 2
Para trabajar para 2, basta con registrarse para obtener una cuenta, proporcionando una dirección de correo electrónico y una cuenta de PayPal para los depósitos de pago. Durante una prueba, se validó una cuenta en cuestión de minutos.
Los nuevos trabajadores deben realizar un curso de formación de una sola vez que les enseña a resolver rápidamente s. También proporciona consejos como cuándo importa el caso y cuándo no. Después de completar la formación con suficiente precisión, el trabajador puede empezar a ganar dinero.
Después de seleccionar «Empezar a trabajar», el trabajador es llevado a la pantalla del espacio de trabajo, que se muestra arriba. A continuación, se proporciona al trabajador una solución y se le pide que la presente. Una vez resuelto correctamente, el dinero se deposita en un «monedero» electrónico, y el trabajador puede solicitar el pago cuando quiera. El número de «s» que aparecen en el espacio de trabajo parece no tener fin, lo que indica una demanda constante del servicio.
2 trabajadores están incentivados para presentar soluciones correctas de forma similar a como se incentiva a un conductor de Uber para que proporcione un servicio excelente: las valoraciones de los clientes. Los clientes de 2 califican la exactitud de las soluciones que han recibido. Si la puntuación de un trabajador 2 cae por debajo de un determinado umbral, será expulsado de la plataforma. Por el contrario, los trabajadores con las calificaciones más altas serán recompensados durante los momentos de baja demanda recibiendo prioridad en la distribución.
Opción 2 – 2 como servicio
Para utilizar 2 como servicio, un cliente (es decir, un atacante) integra la API de 2 en su ataque para crear una cadena de suministro digital, alimentando automáticamente rompecabezas desde el sitio de destino y recibiendo soluciones para introducir en el sitio de destino.
2 proporciona útilmente scripts de ejemplo para generar llamadas a la API en diferentes lenguajes de programación, incluyendo C#, JavaScript, PHP, Python, y más. El código de ejemplo escrito en Python se ha reproducido a continuación:
Integración de 2 en un ataque automatizado
¿Cómo podría un atacante utilizar 2 en un ataque de relleno de credenciales? El siguiente diagrama muestra cómo interactúan las diferentes entidades en un proceso de bypass:
Proceso técnico:
- El atacante solicita la fuente del iframe y la URL utilizada para incrustar la imagen desde el sitio de destino y la guarda localmente
- El atacante solicita el token de la API del sitio web de 2
- El atacante envía el al servicio de 2 utilizando HTTP POST y recibe un ID, que es un ID numérico atribuido con la imagen que se envió a 2. El ID se utiliza en el paso 5 para una solicitud GET de la API a 2 para recuperar el resuelto.
- 2 asigna el a un trabajador que luego lo resuelve y envía la solución a 2.
- El atacante programa un script para hacer ping a 2 utilizando el ID (cada 5 segundos hasta que se resuelva). 2 entonces envía la solución . Si la solución todavía se está resolviendo, el atacante recibe un mensaje de 2 indicando «_NOT_READY» y el programa lo intenta de nuevo 5 segundos después.
- El atacante envía una solicitud de inicio de sesión al sitio objetivo con los campos rellenados (es decir, un conjunto de credenciales de una lista robada) junto con la solución.
- El atacante itera sobre este proceso con cada imagen.
Combinado con frameworks de pruebas web como Selenium o PhantomJS, un atacante puede aparentar que interactúa con el sitio web objetivo de una manera similar a la humana, saltándose de manera efectiva muchas de las medidas de seguridad existentes para lanzar un ataque de relleno de credenciales.
Monetización &Ecosistema delictivo
Con una solución tan elegante, ¿cómo es el ecosistema financiero y cómo gana dinero cada una de las partes?
Monetización: solucionador
Trabajar como solucionador no es nada lucrativo. Basándose en las métricas proporcionadas en el sitio web de 2, es posible calcular la siguiente remuneración:
Suponiendo que se necesitan 6 segundos por , un trabajador puede enviar 10 s por minuto o 600 s por hora. En un día de 8 horas, eso supone 4800 s. Basándonos en lo que se ganó durante nuestra prueba como empleado por 2 (aproximadamente 0,0004 dólares por solución), esto equivale a 1,92 dólares por día.
Esto es una pérdida de tiempo para los individuos de los países desarrollados, pero para aquellos que viven en lugares donde unos pocos dólares al día pueden llegar relativamente lejos, los servicios de solución son una forma fácil de ganar dinero.
Monetización: Atacante
El atacante paga al tercero, 2, por soluciones en paquetes de 1000. Los atacantes pujan por las soluciones, pagando entre 1 y 5 dólares por paquete.
Muchos atacantes utilizan los servicios de solución como un componente de un ataque más amplio de relleno de credenciales, lo que justifica el gasto. Por ejemplo, supongamos que un atacante lanza un ataque para probar un millón de credenciales de Pastebin en un sitio objetivo. En este escenario, el atacante necesita puentear una con cada conjunto de credenciales, lo que costaría aproximadamente 1000 dólares. Asumiendo una tasa de reutilización de credenciales del 1,5%, el atacante puede tomar más de 15.000 cuentas, que pueden ser monetizadas.
Monetización: 2
2 recibe el pago del atacante por cada 1000. Como se mencionó anteriormente, los clientes (es decir, los atacantes) pagan entre 1 y 5 dólares por 1000 s. Los servicios como 2 entonces toman una parte del precio de la oferta y reparten el resto a su fuerza de trabajo humana. Dado que los servicios de resolución se utilizan como solución a escala, los beneficios se acumulan. Incluso si 2 sólo recibe 1 dólar por cada 1.000 s resueltos, obtiene un mínimo de 60 céntimos por paquete. Los propietarios de estos sitios suelen estar en países en vías de desarrollo, por lo que los ingresos, aparentemente bajos, son sustanciales.
¿Qué pasa con el re invisible de Google?
En marzo de este año, Google lanzó una versión mejorada de su re llamada «re invisible». A diferencia de «no re», que requería que todos los usuarios hicieran clic en el infame botón «No soy un robot», Invisible re permite que los usuarios humanos conocidos pasen, mientras que sólo sirve un desafío de imagen re a los usuarios sospechosos.
Podría pensarse que esto dejaría perplejos a los atacantes, ya que no podrían ver cuándo están siendo examinados. Sin embargo, justo un día después de que Google presentara Invisible re, 2 escribió una entrada en su blog sobre cómo vencerlo.
La forma en que Google sabe que un usuario es un humano es si el usuario ha visitado previamente la página solicitada, lo que Google determina comprobando las cookies del navegador. Si el mismo usuario ha empezado a utilizar un nuevo dispositivo o ha borrado recientemente su caché, Google no dispone de esa información y se ve obligado a emitir un nuevo desafío.
Para que un atacante pueda automatizar un ataque de relleno de credenciales utilizando 2, necesita garantizar un desafío. Por lo tanto, una forma de eludir Invisible re es añadir una línea de código al script de ataque que limpie el navegador con cada solicitud, garantizando un re desafío solucionable.
Lo ligeramente complicado de Invisible re es que el desafío está oculto, pero hay una solución. Se puede «encontrar» utilizando la herramienta del navegador «inspeccionar elemento». Así que el atacante puede enviar un POST a 2 que incluya un parámetro que detalle dónde se encuentra lo oculto. Una vez que el atacante recibe la solución de 2, Invisible re puede ser derrotado a través de la automatización en una de dos maneras:
- Acción de JavaScript que llama a una función para suministrar el token resuelto con el formulario de la página submit
- Cambio de código HTML directamente en la página web para sustituir un fragmento de código normal con la entrada del token resuelto.
El hecho de que el Invisible re pueda ser eludido no es porque haya un fallo fatal en el diseño del nuevo . Es que cualquier prueba de Turing inversa es intrínsecamente superable cuando se conocen las condiciones de paso.
Mientras haya s, habrá servicios como el 2 porque la economía juega muy bien en las manos del criminal. Aprovechar la mano de obra humana de bajo coste minimiza el coste del negocio y permite a los ciberdelincuentes obtener beneficios que pueden superar los millones de dólares a escala. Y siempre habrá regiones del mundo con costes de mano de obra baratos, por lo que la demanda constante asegura una oferta constante por parte de 2.
El mundo no necesita desarrollar una mejor , ya que todo este enfoque tiene limitaciones fundamentales. En cambio, deberíamos reconocer esas limitaciones e implementar defensas en las que las condiciones de paso sean desconocidas o, al menos, difíciles de averiguar para los atacantes.
Fuentes
Holmes, Tamara E. «Prepaid Card and Gift Card Statistics». CreditCards.com. Creditcards.com, 01 dic. 2015. Web.
Hunt, Troy. «Rompiendo con los humanos automatizados». Entrada en el blog. Troy Hunt. Troy Hunt, 22 ene. 2012. Web.
Motoyama, Marti, Kirill Levchenko, Chris Kanich y Stefan Savage. Re: s-Understanding -solving Services in an Economic Context. Proc. of 19th USENIX Security Symposium, Washington DC. Print.
Aprenda más
Vea el vídeo, «Aprenda cómo los ciberdelincuentes vencen»
