Home Articles techniques Comment protéger votre service OTT contre une attaque Credential stuffing
Applications

Comment protéger votre service OTT contre une attaque Credential stuffing

About The Author

Outline

La menace posée par les attaques de bourrage d’informations d’identification sur les services de streaming OTT est devenue très claire récemment. Quelques heures après le lancement hyper-hyper d’un service de streaming populaire, les comptes d’utilisateurs ont été piratés et offerts à la vente à prix réduit. Cette brèche s’est transformée en un défi de relations publiques alors que des milliers d’abonnés se sont tournés vers les médias sociaux pour dissiper leurs frustrations concernant l’accès au compte verrouillé et les problèmes d’accessibilité des services.

Comme le montre cette expérience, les attaques de bourrage d’informations d’identification constituent un défi émergent pour les équipes de sécurité OTT. Les abonnements aux services de streaming, motivés par des essais gratuits, des coupures de fil et du contenu exclusif, ont généré de vastes collections d’informations sur les utilisateurs, faisant des services OTT des cibles de plus en plus attrayantes pour le vol de données. Revendre l’accès à des comptes violés n’est pas le seul motif pour les pirates. Ils peuvent également supprimer des détails privés précieux des comptes d’utilisateur violés, tels que les adresses, l’historique de téléphone et de navigation, et les données de carte de crédit. Le pirate informatique peut ensuite vendre ces informations sur le dark web ou causer des dommages supplémentaires par le biais d’attaques d’ingénierie sociale et de phishing.

La zone de dommages d’une attaque de bourrage d’informations d’identification va bien au-delà de l’impact sur la vie privée et les finances d’un utilisateur. Les attaques de bourrage d’informations d’identification utilisent des botnets capables d’automatiser des millions de demandes de connexion par heure, ce qui fait des ravages sur l’infrastructure applicative. Même avec un faible taux de réussite, un tel volume de demandes peut augmenter le coût d’exploitation de la plateforme de streaming. Les cycles CPU supplémentaires, la mémoire et les frais d’entrée/sortie de données augmentent avec le temps. Compte tenu du coût relativement élevé de la gestion des backends applicatifs, en particulier dans le cloud, les demandes de connexion, qui dépendent fortement des systèmes backend, constituent l’attaque la plus coûteuse. En fin de compte, un niveau élevé d’activité néfaste non contrôlée dégrade le service pour les utilisateurs légitimes qui tentent d’authentifier, de parcourir et de diffuser du contenu.

Comment un service de streaming peut-il neutraliser cette menace croissante ? Cet article technique examinera ce qui est nécessaire pour gérer les bots dans le monde d’aujourd’hui et ce qu’il faut pour qu’un service de streaming minimise l’impact – et réduit la probabilité – d’une attaque de bourrage d’informations d’identification.

L’anatomie d’une attaque de bourrage de justificatifs d’identité

Les cybercriminels peuvent lancer une attaque de bourrage d’informations d’identification en obtenant des informations d’identification volées par plusieurs moyens, notamment la découverte de bases de données mal configurées, des attaques de phishing, l’infection des appareils des utilisateurs avec des logiciels malveillants ou l’achat d’informations d’identification piratées sur le dark web. Ensuite, les attaquants acheminent d’innombrables demandes de connexion via des serveurs proxy distribués pour masquer l’origine de l’attaque et amplifier les demandes. Les criminels peuvent acheter l’accès à des services proxy, à des tarifs horaires abordables, auprès de bots Herders sur des forums web sombres. Enfin, les attaquants créent des scripts pour automatiser les demandes d’authentification à l’aide de la liste des informations d’identification violées, généralement en s’appuyant sur des mots de passe réutilisés ou simplistes, pour accéder aux services. Les attaquants peuvent également acheter des kits d’outils sur le dark web, tels que des solveurs CAPTCHA, des émulateurs de navigateur ou des scripts d’usurpation d’empreintes digitales, pour aider à contrer les défenses existantes.

Défense contre les attaques de bourrage d’informations d’identification

Arrêter de telles attaques nécessite la capacité de distinguer les robots des humains. Malheureusement, les opérateurs de bot trouvent continuellement de nouvelles façons de contourner les méthodes de détection de bot. La dernière génération de bots est presque indiscernable des humains.

Les bots étant de plus en plus sophistiqués, les stratégies d’atténuation simples qui auraient pu fonctionner dans le passé, comme bloquer la requête du bot, l’adresse IP ou l’agent utilisateur (UA), ne sont plus suffisantes. Aujourd’hui, les attaquants utilisent très probablement l’un des services proxy IP rotatifs bon marché et abondants au lieu d’attaquer à partir d’adresses IP statiques, ce qui les aide à contourner la limitation de débit et la protection par liste de contrôle d’accès (ACL) simple. De plus, le blocage n’est pas conseillé car il sert de mécanisme de rétroaction utile pour les opérateurs de bot, leur disant de faire évoluer leur automatisation pour vaincre la méthode de détection.

Les techniques de détection des bots ont dû devenir plus sophistiquées pour correspondre à la sophistication croissante des attaques de bots. Les techniques de détection de bots de pointe d’aujourd’hui impliquent trois formes d’analyse à la fois côté serveur et côté client. Il s ‘ agit de :

  1. Demander la prise d’empreintes digitales
  2. Empreinte digitale du client
  3. Empreinte comportementale

Vous aurez besoin d’une combinaison des trois pour vaincre les attaques sophistiquées de bourrage d’informations d’identification.

Méthode de détection d’attaque 1 : demande d’empreintes digitales

L’empreinte digitale des requêtes est généralement effectuée côté serveur dès que le serveur reçoit toutes les informations demandées du client. Une requête client consiste généralement en une combinaison d’un réseau (IP), d’une connexion, d’un cryptage et d’autres métadonnées HTTP analysées et utilisées pour générer une empreinte digitale de requête. Cette empreinte digitale inclut des détails de base tels que l’adresse IP, l’établissement de liaison TCP, l’établissement de liaison TLS (c’est-à-dire le protocole TLS, les chiffrements, et extensions), les en-têtes HTTP et les ordres d’en-tête, ainsi que d’autres informations dérivées des métadonnées telles que l’ASN et le type de périphérique. Lorsqu’elles sont réunies, ces caractéristiques de demande peuvent produire une signature ou une empreinte digitale unique pour chaque client.

Figure 1. Un petit échantillon de caractéristiques de demande qui peuvent fonctionner ensemble pour créer une empreinte de demande unique.

À partir de l’empreinte digitale, nous pouvons commencer à rechercher des anomalies. Par exemple, si une requête prétend provenir d’un Chrome UA, inclut-elle des en-têtes dans l’ordre prévu dans cette version du navigateur Chrome, comme indiqué dans l’agent utilisateur ? Utilise-t-il les protocoles HTTP et TLS typiques ? Le message ClientHello contient-il le protocole et le chiffrement avec l’ordre préféré typique de cette version de Chrome ? En plus d’analyser les métadonnées des requêtes, le serveur peut également effectuer une analyse de comportement limitée, comme le nombre de requêtes et leur fréquence et s’il existe un modèle de navigation qui pourrait aider à déterminer si les requêtes sont automatisées.

La demande de prise d’empreintes digitales est une première étape nécessaire, mais elle ne suffit pas à elle seule.

Méthode de détection d’attaque 2 : empreinte digitale du client

Le défi avec l’empreinte digitale des requêtes est que les attaquants peuvent désormais usurper les empreintes digitales des requêtes qui, le plus souvent, sembleront identiques à 100% à celles du client réel. Si les attaquants commettent une erreur, les empreintes digitales de demande identifieront ces erreurs, mais vous ne pouvez pas compter que cela se produise régulièrement.

Fondamentalement, les empreintes digitales de demande ne disent que la moitié de l’histoire. Le serveur doit voir ce qui se passe du côté client et générer une empreinte client pour compléter l’empreinte de la requête afin d’obtenir plus d’informations. Cela donne aux systèmes de détection des bots une image plus complète du client et rend plus difficile pour les attaquants d’éviter la détection.

Un serveur d’empreintes digitales client peut injecter un petit morceau de JavaScript (JS) à exécuter côté client en réécrivant le code HTML en réponse à la page demandée. Alternativement, le serveur peut injecter une balise de script qui pointe vers un JS distant que le client peut télécharger lors du chargement de la page de connexion. Le JS peut effectuer des vérifications côté client et collecter des informations sur l’appareil telles que si JS ou les cookies sont activés, et examine le système d’exploitation, la toile, le moteur de rendu, le navigateur, le moteur JS, et plus encore pour générer une empreinte client complète.

Un navigateur normal est censé avoir la prise en charge des cookies et être activé JS (afin qu’ils puissent correctement se connecter et utiliser vos services de streaming) ; ne pas l’avoir activé peut provoquer des soupçons. Les empreintes digitales des clients peuvent identifier d’autres éléments suspects non typiques de l’appareil annoncé qui peuvent indiquer un faux client potentiel, comme un UA de navigateur Safari avec Blink (moteur de navigateur) ou Chrome avec un moteur SpiderMonkey JS.

Ces informations sont collectées et peuvent être transmises à un serveur distant sous forme d’appels API pour une analyse plus approfondie ou être cryptées et définies comme un cookie ou un en-tête à envoyer au serveur pour analyse dans les requêtes ultérieures du client. Les techniques ci-dessus pour collecter et générer des empreintes digitales de clients peuvent également être adoptées pour des applications de streaming non-navigateur telles que les applications iPhone/Android, Roku ou les téléviseurs Samsung via différents SDK.

Figure 2. Un petit échantillon de caractéristiques qui peuvent fonctionner ensemble pour créer une empreinte client unique.

Alors que la combinaison de la demande et de la prise d’empreintes digitales des clients était efficace avec les bots de première génération, les bots plus avancés sont basés sur les mêmes clients que les humains, y compris Chrome, Firefox et Safari. Ils peuvent également employer des navigateurs sans tête comme Headless Chrome. Contrairement aux bots de base qui peuvent manquer de fonctionnalités, telles que la prise en charge de JavaScript et des cookies, les bots plus avancés peuvent utiliser le navigateur approprié et le moteur JS pour effectuer des requêtes TCP et TLS et HTTP correctement formées, en cohérence avec leur type d’appareil.

Les attaques faibles et lentes peuvent être effectuées en distribuant les requêtes via des milliers d’adresses IP, annulant ainsi toute méthode de détection basée sur le débit. Pour aggraver encore le problème, de vrais navigateurs à partir de vrais appareils utilisateurs peuvent être piratés et utilisés pour des activités de bourrage d’informations d’identification, et de telles attaques sont presque certaines d’être manquées avec ces seules approches.

Méthode de détection d’attaque 3 : empreinte comportementale

Pour vraiment battre le bourrage d’informations d’identification, vous devez ajouter l’empreinte comportementale intelligente. Lorsque les utilisateurs interagissent avec un service de streaming, ils ne se contentent pas de faire des demandes de contenu, ils se déplacent, cliquent, tapotent et naviguent dans l’application. Les empreintes comportementales étudient ces actions en collectant les données de télémétrie des utilisateurs côté client, généralement via JS. Ceux-ci peuvent inclure les modèles de mouvement de la souris, les frappes au clavier, la synchronisation d’une action, ou même taper sur des capteurs de l’appareil tels que des accéléromètres de téléphone ou des gyroscopes pour mesurer le modèle de mouvement et le positionnement d’un utilisateur.

Sur la base des données collectées, des empreintes comportementales sont générées et envoyées pour une analyse en temps réel ou hors ligne. L’utilisateur présente-t-il un motif aléatoire ou non organique ? La souris se déplace-t-elle selon des motifs linéaires, ou la vitesse de défilement est-elle plus rapide qu’un être humain pourrait atteindre ? Le téléphone se trouve-t-il toujours à un angle fixe pendant toute la durée de la session de navigation ? Le nombre de demandes de connexion par seconde est-il humainement possible ?

C’est le champ de bataille des scientifiques et des chercheurs qui doivent employer des techniques d’apprentissage automatique pour analyser continuellement les données et obtenir des renseignements sur l’automatisation d’une demande. Cela est dû en partie à la croissance exponentielle de la combinaison de requêtes, de périphériques et d’attributs comportementaux collectés. Comme les bots ont amélioré leur capacité à imiter le comportement humain via le détournement comportemental, s’appuyer sur des caractéristiques comportementales de base telles que les mouvements de souris n’est plus adéquat et peut augmenter le taux de faux positifs et impacter l’expérience des utilisateurs réels.

Ces types de bots présentent le défi le plus difficile pour atténuer le bourrage d’informations d’identification. Arrêter les bots les plus sophistiqués nécessite plus de données, telles que le comportement de navigation du client tout au long de la session, pour analyser l’intention du client et ainsi identifier si la requête est malveillante. Par exemple, est-ce un comportement normal lorsqu’un utilisateur visite directement la page de connexion d’un service de streaming sans passer par la page d’accueil ? Est-il normal qu’un utilisateur accède immédiatement à la page du compte après s’être connecté au service de streaming et n’effectue aucune autre action ? Ces points de données peuvent identifier précisément l’intention des bots. L’interaction de l’utilisateur avec le service de diffusion en continu tout au long de la session et d’autres données comportementales peut produire une empreinte digitale plus riche et plus complète avec moins de risques de faux positifs.

Gérer les bots

Une fois que vous avez détecté avec succès un bot tentant de faire une demande de connexion, quelle est la bonne réponse ? Est-ce pour bloquer le bot et espérer qu’il disparaisse ? Dans la plupart des cas, c’est la mauvaise action. Supposons que vous répondiez avec une erreur 4xx, telle qu’une réponse non autorisée 401. Les attaquants connaissent les techniques inadéquates actuelles et mettent à jour leurs outils d’automatisation pour surmonter votre mécanisme de détection par essais et erreurs. Dans ce cas, vous avez par inadvertance aidé les attaquants en leur fournissant une boucle de rétroaction pour les alerter de faire évoluer leur méthode.

Bien qu’il soit inévitable que les opérateurs de bots sophistiqués détectent éventuellement qu’ils sont atténués et fassent évoluer leurs méthodes, il existe certaines bonnes pratiques pour éviter ou retarder ces efforts. Lorsqu’il est détecté, au lieu de bloquer les requêtes de bot, le serveur peut envoyer un code de réponse standard attendu lorsqu’une tentative de connexion est réussie, tel que 200 OK, couplé à une réponse standard statique qui n’expose pas les données sensibles.

Les opérateurs de bot sont plus susceptibles qu’autrement de supposer qu’une réponse réussie indique que leur méthode actuelle est réussie. Et que les informations d’identification volées sont utiles même si ce n’est peut-être pas le cas, gardant l’attaquant dans l’ignorance. Une autre option consiste à tartiner la requête du bot en ne fournissant aucune réponse, laissant la requête du bot suspendue jusqu’à ce qu’elle expire. Cela peut être fait si vous utilisez une grande plate-forme distribuée dans le monde entier avec une grande capacité de serveur, comme un réseau de diffusion de contenu (CDN). Ces méthodes de désinformation sont probablement plus efficaces que le simple blocage des requêtes de bot.

Une autre stratégie de gestion des bots, qui a moins d’impact sur l’expérience utilisateur en cas de faux positif, nécessite qu’un bot suspect résolve un CAPTCHA. Ce n’est qu’après avoir terminé le CAPTCHA que la connexion sera réussie. Cela permet aux utilisateurs réels de continuer même s’ils sont mal identifiés comme un bot. Il fournit également des informations précieuses pour ajuster votre méthode de détection afin de réduire les faux positifs.

Protégez la diffusion

La prévention des attaques de bourrage d’informations d’identification est une priorité importante pour tout service de streaming OTT. Au fur et à mesure que ces services gagnent en popularité, il en va de même des risques de sécurité. Une approche multicouche de la sécurité des applications et de la gestion des bots peut identifier avec précision les bots les plus sophistiqués utilisés pour alimenter les attaques de bourrage d’informations d’identification et empêcher de telles attaques d’affecter votre expérience client ou votre réputation.

Découvrez comment nos fonctionnalités de sécurité cloud peuvent protéger votre présence en ligne contre les attaques de bourrage d’informations d’identification, les attaques DDoS, et bien plus encore.