Avec Twitter désactivant l'authentification à deux facteurs par message texte, j'ai pensé qu'il serait amusant d'approfondir le fonctionnement de la fraude par SMS et la manière dont les développeurs d'applications peuvent s'en protéger.
C'est une histoire fascinante d'incitations perverses, de réglementation à courte vue et d'ingéniosité technique.
Allons creuser ! 👇
Pour commencer, récapitulons l'annonce récente de Twitter :
En clair, cela signifie simplement que seuls les utilisateurs de la version payante de Twitter recevront un code envoyé sur leur téléphone lors de la connexion.
La clé pour comprendre la fraude par SMS est de comprendre que certains numéros sont surtaxés . Si vous souhaitez appeler ou envoyer un SMS à ce numéro, cela vous coûtera de l'argent - généralement des dizaines de centimes - et le propriétaire du numéro recevra une partie de ces dizaines de centimes pour lui-même.
Les propriétaires de ces numéros de téléphone proposent généralement des services légitimes qui coûtent de l'argent et offrent de la valeur à leurs utilisateurs, tels que le vote à distance, les rencontres et l'assistance technique.
Cependant, ces numéros peuvent être joués pour un profit facile 🤑
Un mauvais acteur, appelons-le Bob , met la main sur plusieurs numéros de téléphone surtaxés[1]. Bob pourrait être un hacker, ou pourrait être un opérateur de réseau de téléphonie mobile qui a mal tourné.
Bob trouve un service Web qui enverra des messages texte à ses numéros de téléphone surtaxés. Ces messages peuvent être des codes d'authentification à deux facteurs, des mots de passe à usage unique ou tout autre message texte envoyé à l'utilisateur dans le cadre du service (par exemple, partiful.com envoie des rappels d'événements par SMS).
Bob trouve un moyen de faire en sorte que le service envoie des milliers de SMS à ses numéros de téléphone surtaxés. Cela pourrait être très facile. Le service frontal peut être facile à manipuler, et les points de terminaison principaux peuvent être non protégés et faciles à désosser.
Pire encore, de nombreux services utilisent un point de terminaison standardisé pour l'envoi de SMS. Cela permet à Bob de trouver beaucoup plus facilement des sites à attaquer. Par exemple, si le service utilise un tiers pour authentifier les utilisateurs et envoyer des codes 2FA ou OTP, tels que Auth0, alors le point de terminaison pour l'envoi de SMS est principalement connu : tout ce que Bob doit faire est de trouver un moyen de découvrir les Auth0. ID pour un service Web (assez facile, puisque le frontal du service Web fait une demande contenant cet ID), puis ils peuvent attaquer tous les sites qui utilisent ce service tiers.
Enfin, Bob fait en sorte que le service envoie des milliers de SMS vers ses numéros de téléphone premium. Le service web perd 💵💵💵, et Bob profite.
Il n'y a pas de solution miracle pour prévenir la fraude par SMS. Mais voici quelques idées qui pourraient fonctionner :
Si vous utilisez un service tiers pour authentifier les utilisateurs, tel que Auth0, vous pouvez masquer le point de terminaison utilisé pour envoyer des SMS. Bien que cela n'empêche pas une attaque pure et simple, il est beaucoup plus difficile de découvrir qu'une attaque est possible.
Semblable à la façon dont un voleur de vélo cible les vélos les plus faciles à voler, un bon pirate se déplacerait vers des services Web plus faciles à pirater. Mon intuition est que cette approche fonctionnerait assez bien pour la longue traîne des applications.
Bloquez toutes les demandes provenant d'adresses IP provenant de fournisseurs de cloud, de FAI frauduleux ou qui sont autrement sommaires. Cela devrait être assez simple à mettre en œuvre — il existe de nombreux services qui permettent d'évaluer la qualité d'une adresse IP — et serait probablement très efficace.
Ajoutez une limitation de débit basée sur IP au point de terminaison qui envoie des SMS pour bloquer l'attaque de Bob. S'il est configuré correctement, cela n'affectera pas les utilisateurs légitimes. Cependant, cela ne fonctionne que contre une simple attaque. Si Bob conçoit son attaque pour envoyer des requêtes à partir d'une variété d'adresses IP - une attaque distribuée - cela ne fonctionnera pas.
N'envoyez un SMS à un numéro de téléphone spécifique qu'un petit nombre de fois avant de bloquer ce numéro de téléphone pendant une période de réflexion. Nous pourrions le faire sur le front-end, mais si Bob est déterminé, il pourrait trouver le point de terminaison back-end à attaquer à la place. Bloquer le numéro de téléphone sur le backend est plus difficile : cela nécessite de conserver un enregistrement des numéros de téléphone et de leurs tentatives de connexion récentes[2].
Forcer l'utilisateur à résoudre un CAPTCHA avant de lui envoyer un SMS. Bien que cette approche fonctionne bien pour bloquer les attaquants - la résolution du CAPTCHA est difficile et coûteuse à faire à grande échelle - elle dégrade l'expérience de l'utilisateur du service.
Identifiez et bloquez les numéros de téléphone surtaxés à l'aide de libphonenumber . Bien que cela semble prometteur, je ne sais pas à quel point les données sont fiables et à quel point cette approche est efficace.
N'envoyez des SMS qu'à des comptes payants. C'est l'approche que Twitter a adoptée. Ce n'est pas une mauvaise option, mais comme vous pouvez le voir dans la liste ci-dessus, vous pouvez adopter de nombreuses autres approches.
Bloquer les opérateurs de réseau de téléphonie mobile avec un nombre élevé d'utilisateurs frauduleux. Cela bloquerait clairement les mauvais opérateurs de réseau, mais ne fonctionnerait pas bien si le réseau compte de nombreux utilisateurs légitimes.
Utilisez plutôt WhatsApp pour envoyer des messages. WhatsApp est gratuit contrairement aux SMS, mais tous les utilisateurs du monde n'utilisent pas WhatsApp[3].
Une bonne solution utiliserait suffisamment des approches ci-dessus, en priorisant l'investissement en temps et l'efficacité, jusqu'à ce que les attaquants se déplacent vers des cibles plus faciles.
J'ai une expérience personnelle de la mise en œuvre des mesures ci-dessus et j'ai une ou deux histoires à partager sur la façon dont mon équipe a géré les retombées. Mais c'est une histoire pour une autre fois… 👨💻
Cela m'amène à mon dernier point :
IMO, Twilio - une API SMS dominante - a une énorme opportunité d'offrir une protection contre la fraude par SMS en tant que module complémentaire (gratuit ? 🙏) à leurs API standard.
Étant donné que Twilio dispose de données sur les numéros de téléphone et les opérateurs frauduleux sur tous leurs comptes, Twilio est dans une position unique pour bloquer rapidement les mauvais numéros et les opérateurs, avant qu'ils ne deviennent un gros problème pour plusieurs services Web.
Twilio peut même détecter directement les numéros de téléphone invalides à l'aide de Silent Network Auth - un mécanisme d'authentification de nouvelle génération - et il semble que cet utilitaire doit être partagé entre leurs utilisateurs.
J'aimerais entendre d'autres pensées, idées et approches que les gens ont utilisées - veuillez partager en écrivant un commentaire ci-dessous, et nous pouvons tous apprendre.
C'est tout pour l'instant — protégez ces endpoints et passez une bonne semaine !
Il y a une excellente discussion sur HackerNews.
[1] Notez que ces numéros de téléphone premium n'ont même pas besoin de fonctionner : ils n'ont pas besoin d'être connectés à une carte SIM qui fonctionne et qui est enregistrée sur un téléphone. Tant qu'ils peuvent être acheminés vers, ils peuvent être utilisés dans cette attaque.
[2] Je suis curieux de savoir s'il existe une bonne structure de données et un bon algorithme pour rendre cela efficace et fonctionner à grande échelle. Merci de partager si vous en connaissez un !
[3] Crédit à @csharpminor sur HN pour leur suggestion .
Je suis Apu , CTO de koodos et ingénieur.
Cet article est apparu à l'origine sur mon blog personnel - abonnez-vous pour en avoir plus!