Credentials stuffing : premières victimes chez certains fournisseurs VPN

Avant-propos

Nous espérons que les informations partagées dans cet article seront utiles aux fournisseurs de services VPN et aux autres services en ligne. Nous avons fait en sorte de le compléter avec le plus de détails possibles afin de fournir une meilleure vue d’ensemble de la question. Si vous avez été la cible de ce type d’attaque de credentials stuffing et avez besoin de conseils, n’hésitez pas à nous contacter. Nous sommes à votre disposition pour partager nos connaissances avec vous.

Introduction

Par le passé, Le VPN a été la cible d’innombrables attaques DDoS. Mais il y a quelques semaines, nous avons remarqué quelque chose de différent et d’inédit.

Un botnet, qui vise généralement notre système de gestion client, a désormais changé de stratégie pour se concentrer sur notre API. En y regardant de plus près, nous nous sommes aperçus qu’il s’agissait de « credentials stuffing », c’est-à-dire quelqu’un qui utilise une collection d’identifiants précédemment dérobés pour les essayer sur notre base d’utilisateurs.

Le VPN est largement insensible à ce type d’attaque, car nous générons un identifiant unique pour chaque nouvel utilisateur.

La seule exception concerne une fraction de nos utilisateurs qui ont migré vers Le VPN depuis un autre fournisseur.

Cela illustre l’importance d’utiliser des mots de passe différents, tant pour les particuliers qui accèdent à plusieurs sites et services en ligne, que pour les entreprises qui doivent mettre en place des mesures de protection de leurs mots de passe.

Détection de l’attaque

Les demandes émises par ce botnet étaient facilement identifiables, nous les avons donc séparées des demandes d’API authentiques. Plutôt que de transiter par des algorithmes API, les requêtes malveillantes recevaient ainsi un message d’erreur standard et étaient enregistrées dans des journaux pour une analyse ultérieure.

Nous avons rigoureusement vérifié qu’aucun de nos clients ne fut affecté et que ces attaques ne constituaient pas de danger pour notre système.

Nous avons donc décidé de laisser faire le botnet pendant quelques jours afin de recueillir davantage de données.

L’attaque a duré quelques jours à un rythme identique, et il est maintenant temps de faire progresser l’enquête.

Nous souhaitons vous présenter nos observations ci-dessous.

Botnet

Le botnet utilisé pour cette attaque était relativement petit — environ 40 000 à 45 000 bots au total.  Le nombre de bots actifs simultanément était encore plus faible, généralement moins de 10 000.

Selon nos données, le même botnet a été employé tout au long de l’attaque.

Les adresses IP de ces bots étaient principalement localisées en Chine (75 %), en Indonésie (4 %), en Thaïlande (4 %) et au Brésil (4 %), tandis qu’une infime partie provenait d’autres pays. La majorité des bots chinois avaient des IP de Chinanet et de China Unicom.

Rythme de l’attaque

Nous avons décidé de mesurer la fréquence d’attaque du botnet. Nous avons donc désactivé toutes les règles de limitation de débit et de filtrage du trafic sur notre système, et commencé à absorber toutes les demandes du botnet.

Ainsi, le botnet a attaqué au rythme d’environ 3 requêtes par bot et par heure. Cela ne change pas vraiment de la fréquence qu’avait l’attaque quand toutes nos défenses étaient actives.

Nous pensons donc que cette cadence a été réduite intentionnellement, afin de ne pas déclencher nos défenses ce qui aurait pu entrainer un ban des adresses IP des machines du botnet. Néanmoins, nous pensons que cette fréquence peut varier en fonction des défenses de la cible.

Selon nos estimations, un attaquant avec un botnet d’une telle taille peut effectuer environ 500 000 vérifications d’identifiants par jour.

Nombre de requêtes par identifiant

Une autre constatation intéressante est le nombre de requêtes par identifiant. La majorité des couples nom d’utilisateur/mot de passe n’ont été essayés qu’une seule fois, seule une petite portion ayant été testée deux fois. Cela peut indiquer que les essais sont gérés de manière centralisée et probablement synchronisées.

La source des identifiants volés

Un autre aspect de l’enquête consistait à identifier la source de ces fuites. Nous avons sélectionné un échantillon représentatif des identifiants utilisés dans cette attaque et nous les avons soigneusement analysés. La quasi-totalité d’entre eux est présente dans la « Collection » (https://en.wikipedia.org/wiki/Collection_No._1), ce qui nous laisse penser qu’il s’agit de la principale source de ces données.

Cependant, nous estimons qu’une attaque utilise de 10 à 15 millions d’identifiants, et non la « Collection » dans son ensemble.

Nous estimons que le temps total nécessaire pour mener à bien cette attaque avec cette fréquence et avec la taille du dictionnaire mentionnés ci-dessus est de 20 à 30 jours environ.

Qui est derrière tout cela ?

Nous avons voulu aller plus loin et recueillir davantage de données sur notre agresseur. Nous avons donc configuré notre API pour qu’elle renvoi, de manière aléatoire, une réponse positive à certaines requêtes. Cette approche a généré une liste de faux identifiants, que les cybercriminels peuvent tenter de distribuer ou d’utiliser sur nos serveurs AAA.

L’objectif était de voir où cette liste apparaitrait et d’ainsi pouvoir faire le lien. Dès cette ruse déployée, nous avons commencé à surveiller le Web.

Résultats inattendus

Les résultats ont été rapides et surprenants.

Nous avons trouvé plus de 1 000 identifiants VPN censés être liés à l’un des grands fournisseurs de VPN. Certains ont été publiés fin avril et d’autres début mai 2020. Toutes ces fuites ont été diffusées publiquement et gratuitement dans une communauté en ligne reliée à l’Iran.

Nous avons immédiatement soumis nos conclusions au fournisseur de VPN concerné et avons demandé à son assistance technique d’informer l’équipe de cybersécurité de cet incident dans les plus brefs délais. Nous sommes toujours dans l’attente de leur réaction.

La même attaque de credentials stuffing ?

Après avoir averti le fournisseur, nous avons poursuivi l’analyse des données qui ont fait l’objet d’une fuite.

Nous avons consulté les identifiants exposés et avons été surpris de constater que la plupart d’entre eux étaient présents dans la « Collection » mentionnée ci-dessus, la même source d’identifiants piratés utilisée contre notre API.

Certains éléments étaient présents dans d’autres listes d’identifiants volés. Mais quoi qu’il en soit, tous les identifiants que nous avons testés se trouvaient dans un ensemble de données volées ou dans un autre.

De plus, l’une des listes d’identifiants VPN contenait une date et une heure d’expiration avec les minutes et secondes exactes, ce qui ressemble à la réponse d’une API.

Il est impossible de recenser le nombre total d’identifiants compromis, car de nouvelles listes continuent d’apparaître de façon régulière.

Comment tout cela s’est-il terminé ? (Pour l’instant…)

Chez Le VPN, nous prenons la sécurité au sérieux, et à chaque attaque, nous nous préparons donc au pire.

Le botnet qui nous a frappés était relativement petit. Nous avons donc cherché à simuler notre réponse pour un scénario qui impliquerait un botnet beaucoup plus important.

Cela signifie couper toute connexion avec le botnet dès que nous l’avions identifié. Dans ce scénario, les agresseurs ne reçoivent aucune réponse de notre API et la charge sur nos serveurs API est donc réduite au minimum.

Peu après avoir commencé à mettre en place cette solution, un pirate a décidé d’interrompe toute nouvelle attaque par credentials stuffing et a tenté un ultime DDoS, court et infructueux, sur notre frontend. Depuis lors, les attaques ne se sont plus reproduites.

Remarques finales

De nombreuses questions restent encore sans réponses.

Même si l’origine du botnet en lui-même se situe très probablement en Chine, le groupe ou l’individu qui l’a loué pourrait se trouver au Moyen-Orient.

Nous ne savons pas si le même auteur attaque plusieurs services VPN ou s’il s’agit d’une nouvelle tendance adoptée par différents groupes.

Nous pensons que les comptes dérobés pourraient être distribués dans des pays comme l’Iran, où le degré de censure est important et où les services VPN ne sont généralement pas disponibles en raison des restrictions internationales.

Pour ce type d’attaque, les services VPN avec les plus grandes bases d’utilisateurs constituent la cible la plus facile, car le nombre de clients actifs augmente la probabilité de trouver des identifiants piratés. De plus, il est plus facile de dissimuler l’activité du botnet derrière un plus grand nombre de requêtes à l’API.

Nous attendons toujours que le service VPN dont les comptes ont été exposés prenne des mesures. Si aucune action n’est entreprise, nous essaierons d’en informer nous-mêmes les utilisateurs concernés.

Nous mettrons à jour cet article si nous avons de plus amples détails à ce sujet.