Con Twitter deshabilitando la autenticación de dos factores de mensajes de texto, pensé que sería divertido profundizar en cómo funciona el fraude por SMS y cómo los desarrolladores de aplicaciones pueden protegerse contra él.
Es una historia fascinante de incentivos perversos, regulación miope e ingenio técnico.
¡Vamos a profundizar en! 👇
Para empezar, recapitulemos el reciente anuncio de Twitter:
En lenguaje sencillo, esto simplemente significa que solo los usuarios de la versión paga de Twitter recibirán un código enviado a su teléfono durante el inicio de sesión.
La clave para comprender el fraude por SMS es entender que algunos números son premium . Si desea llamar o enviar un SMS a este número, le costará algo de dinero, generalmente decenas de centavos, y el propietario del número se queda con una parte de esas decenas de centavos.
Los propietarios de estos números de teléfono suelen ofrecer servicios legítimos que cuestan dinero y ofrecen valor a sus usuarios, como tele-voto, citas y soporte técnico.
Sin embargo, estos números se pueden jugar para obtener ganancias fáciles 🤑
Un mal actor, llamémosle Bob , consigue varios números de teléfono premium[1]. Bob podría ser un pirata informático o podría ser un operador de red de telefonía móvil que salió mal.
Bob encuentra un servicio web que enviará mensajes de texto a sus números de teléfono premium. Estos mensajes pueden ser códigos de autenticación de dos factores, contraseñas de un solo uso o cualquier otro mensaje de texto enviado al usuario como parte del servicio (por ejemplo, partiful.com envía recordatorios de eventos a través de SMS).
Bob encuentra una manera de hacer que el servicio envíe miles de SMS a sus números de teléfono premium. Esto podría ser muy fácil. El servicio de front-end puede ser fácil de manipular, y los puntos finales de back-end pueden estar desprotegidos y fáciles de aplicar ingeniería inversa.
Peor aún, muchos servicios utilizan un punto final estandarizado para enviar SMS. Esto hace que sea mucho más fácil para Bob encontrar sitios para atacar. Por ejemplo, si el servicio utiliza un tercero para autenticar a los usuarios y enviar códigos 2FA u OTP, como Auth0, entonces el punto final para enviar SMS es mayormente conocido: todo lo que Bob necesita hacer es encontrar una manera de descubrir los Auth0. ID para un servicio web (bastante fácil, ya que el front-end del servicio web realiza una solicitud que contiene esta ID), y luego pueden atacar todos los sitios que usan ese servicio de terceros.
Finalmente, Bob hace que el servicio envíe miles de SMS a sus números de teléfono premium. El servicio web pierde 💵💵💵 y Bob gana.
No existe una panacea para prevenir el fraude por SMS. Pero aquí hay algunas ideas que podrían funcionar:
Si utiliza un servicio de terceros para autenticar a los usuarios, como Auth0, podría ofuscar el punto final utilizado para enviar SMS. Si bien esto no evitará un ataque por completo, hace que sea mucho más difícil descubrir que un ataque es posible.
De manera similar a como un ladrón de bicicletas se enfoca en las bicicletas más fáciles de robar, un buen hacker pasaría a los servicios web que son más fáciles de piratear. Mi corazonada es que este enfoque funcionaría lo suficientemente bien para la larga lista de aplicaciones.
Bloquee todas las solicitudes de IP que se originen en proveedores de la nube, ISP fraudulentos o que sean incompletas. Esto debería ser bastante simple de implementar (existen muchos servicios que le permiten calificar la calidad de una dirección IP) y probablemente sería muy efectivo.
Agregue limitación de velocidad basada en IP al punto final que envía SMS para bloquear el ataque de Bob. Si se configura correctamente, esto no afectará a los usuarios legítimos. Sin embargo, esto solo funciona contra un ataque simple. Si Bob diseña su ataque para enviar solicitudes desde una variedad de direcciones IP (un ataque distribuido ), entonces esto no funcionaría.
Solo envíe un SMS a un número de teléfono específico unas pocas veces antes de bloquear ese número de teléfono durante un período de reflexión. Podríamos hacer esto en el front-end, pero si Bob está decidido, podría descubrir el punto final del back-end para atacar en su lugar. Bloquear el número de teléfono en el backend es más difícil: requiere mantener un registro de los números de teléfono y sus intentos de inicio de sesión recientes[2].
Obligar al usuario a resolver un CAPTCHA antes de enviarle un SMS. Si bien este enfoque funciona bien para bloquear a los atacantes (resolver el CAPTCHA es difícil y costoso de hacer a escala), degrada la experiencia del usuario con el servicio.
Identifique y bloquee los números de teléfono con tarifas especiales mediante libphonenumber . Si bien esto parece prometedor, no sé qué tan confiables son los datos y qué tan efectivo es este enfoque.
Solo envíe mensajes de texto a cuentas pagas. Este es el enfoque con el que se ha ido Twitter. No es una mala opción, pero como puede ver en la lista anterior, hay muchos otros enfoques que podría tomar.
Bloquear operadores de red de telefonía móvil con un alto número de usuarios fraudulentos. Esto bloquearía a los operadores de red claramente malos, pero no funcionaría bien si la red tiene muchos usuarios legítimos.
Utilice WhatsApp para enviar mensajes en su lugar. WhatsApp es gratuito a diferencia de los SMS, pero no todos los usuarios del mundo usan WhatsApp[3].
Una buena solución haría uso de suficientes enfoques anteriores, priorizando por inversión de tiempo y efectividad, hasta que los atacantes se muevan hacia objetivos más fáciles.
Tengo algo de experiencia personal en la implementación de las medidas anteriores y tengo una o dos historias para compartir sobre cómo mi equipo manejó las consecuencias. Pero esa es una historia para otro momento… 👨💻
Esto me lleva a mi punto final:
En mi opinión, Twilio, una API de SMS dominante, tiene una gran oportunidad de ofrecer protección contra el fraude de SMS como un complemento (¿gratis? 🙏) a sus API estándar.
Dado que Twilio tiene datos sobre números de teléfono y operadores fraudulentos en todas sus cuentas, Twilio está en una posición única para bloquear números y operadores incorrectos rápidamente , antes de que se conviertan en un gran problema para múltiples servicios web.
Twilio puede incluso detectar directamente números de teléfono no válidos mediante Silent Network Auth , un mecanismo de autenticación de próxima generación, y parece que esta utilidad debería compartirse entre sus usuarios.
Me encantaría escuchar otros pensamientos, ideas y enfoques que la gente haya usado. Por favor, comparta escribiendo un comentario a continuación, y todos podemos aprender.
Eso es todo por ahora: ¡proteja esos terminales y tenga una excelente semana!
Hay una excelente discusión en HackerNews.
[1] Tenga en cuenta que estos números de teléfono premium ni siquiera necesitan funcionar: no necesitan estar conectados a una tarjeta SIM que funcione y registrada en un teléfono. Siempre que se puedan enrutar, se pueden usar en este ataque.
[2] Tengo curiosidad por saber si hay una buena estructura de datos y un algoritmo para hacer que esto sea eficiente y funcione a escala. ¡Por favor comparte si conoces uno!
[3] Crédito a @csharpminor en HN por su sugerencia .
Soy Apu , CTO de koodos e ingeniero.
Esta publicación apareció originalmente en mi blog personal . ¡Suscríbete para recibir más publicaciones como esta!