Un chercheur révèle de nouvelles techniques pour contourner le pare-feu et la protection DDoS de Cloudflare


Il est apparu que les mécanismes de prévention des attaques par pare-feu et par déni de service distribué (DDoS) dans Cloudflare peuvent être contournés en exploitant les lacunes des contrôles de sécurité entre locataires, ce qui va à l’encontre de l’objectif même de ces protections.

« Les attaquants peuvent utiliser leurs propres comptes Cloudflare pour abuser de la relation de confiance par conception entre Cloudflare et les sites Web des clients, rendant le mécanisme de protection inefficace », a déclaré Stefan Proksch, chercheur à Certitude. dit dans un rapport publié la semaine dernière.

Le problème, selon le cabinet de conseil autrichien, est le résultat d’une infrastructure partagée disponible pour tous les locataires au sein de Cloudflare, qu’ils soient légitimes ou non, permettant ainsi aux acteurs malveillants d’abuser facilement de la confiance implicite associée au service et de vaincre les garde-fous. .

Le premier problème vient du choix d’un certificat Cloudflare partagé pour authentifier les requêtes HTTP(S) entre les proxys inverses du service et le serveur d’origine du client dans le cadre d’une fonctionnalité appelée Tirages d’origine authentifiés.

Comme son nom l’indique, Authenticated Origin Pulls garantit que les requêtes envoyées au serveur d’origine pour récupérer du contenu lorsqu’il n’est pas disponible dans le cache proviennent de Cloudflare et non d’un acteur menaçant.

La cyber-sécurité

Une conséquence d’une telle configuration est qu’un attaquant disposant d’un compte Cloudflare peut envoyer sa charge utile malveillante via la plateforme en profitant du fait que toutes les connexions provenant de Cloudflare sont autorisées, même si le locataire qui initie la connexion est néfaste.

« Un attaquant peut créer un domaine personnalisé avec Cloudflare et pointer l’enregistrement DNS A vers [a] l’adresse IP de la victime », a expliqué Proksch.

« L’attaquant désactive ensuite toutes les fonctionnalités de protection de ce domaine personnalisé dans son locataire et tunnelise ses attaques via l’infrastructure Cloudflare. Cette approche permet aux attaquants de contourner les fonctionnalités de protection par la victime. »

Le deuxième problème concerne l’abus de autoriser les adresses IP Cloudflare sur liste blanche – qui empêche le serveur d’origine de recevoir le trafic des adresses IP des visiteurs individuels et le limite aux adresses IP Cloudflare – pour transmettre des entrées malveillantes et cibler d’autres utilisateurs sur la plate-forme.

Suite à une divulgation responsable le 16 mars 2023, Cloudflare a reconnu que les résultats étaient informatifs, ajoutant un nouvel avertissement dans sa documentation.

« Notez que le certificat que Cloudflare vous fournit pour configurer les Authenticated Origin Pulls n’est pas exclusif à votre compte, garantissant uniquement qu’une demande provient du réseau Cloudflare », Cloudflare maintenant déclare explicitement.

« Pour une sécurité plus stricte, vous devez configurer des tirages d’origine authentifiés avec votre propre certificat et envisager d’autres mesures de sécurité pour votre origine. »

« Le mécanisme de « liste d’autorisation des adresses IP Cloudflare » doit être considéré comme une défense en profondeur et ne doit pas être le seul mécanisme permettant de protéger les serveurs d’origine », a déclaré Proksch. « Le mécanisme ‘Authenticated Origin Pulls’ doit être configuré avec des certificats personnalisés plutôt qu’avec le certificat Cloudflare. »

Certitude auparavant aussi découvert qu’il est possible pour les attaquants d’exploiter les enregistrements DNS « en suspens » pour détourner des sous-domaines appartenant à plus de 1 000 organisations couvrant des gouvernements, des médias, des partis politiques et des universités, et les utilisent probablement pour la distribution de logiciels malveillants, des campagnes de désinformation et des attaques de phishing.

« Dans la plupart des cas, le détournement de sous-domaines pourrait être efficacement empêché par les services cloud grâce à la vérification de la propriété du domaine et au fait de ne pas divulguer immédiatement les identifiants précédemment utilisés pour l’enregistrement », a noté le chercheur en sécurité Florian Schweitzer.

Ces révélations surviennent alors qu’Akamai révèle que les adversaires exploitent de plus en plus d’algorithmes de génération de domaine (DGA) à implantation dynamique pour éviter la détection et compliquer l’analyse, prolongeant ainsi la durée de vie des canaux de communication de commande et de contrôle (C2).

La cyber-sécurité

« Savoir quels domaines DGA seront activés demain nous permet de mettre ces domaines de manière proactive sur nos listes de blocage afin de protéger les utilisateurs finaux des botnets », chercheurs en sécurité Connor Faulkner et Stijn Tilborghs. dit.

« Malheureusement, ce scénario n’est pas possible avec des graines imprévisibles, telles que Google Trends, les températures ou les taux de change. Même si nous disposons du code source de la famille, nous ne sommes pas en mesure de prédire correctement les noms de domaine DGA générés dans le futur. « 

En août dernier, un groupe d’universitaires de l’Université de Californie, d’Irvine et de l’Université Tsinghua démontré une attaque par empoisonnement du DNS appelée MaginotDNS qui exploite les failles du algorithmes de vérification du bailliage pour prendre en charge des zones DNS entières, y compris même des domaines de premier niveau tels que .com et .net.

« La clé de la découverte de MaginotDNS réside dans les implémentations incohérentes du bailliage entre les différents modes DNS », affirment les chercheurs. souligné. « Les vulnérabilités ne nuisent pas aux redirecteurs classiques car ils n’effectuent pas de résolutions de domaine récursives, mais pour les serveurs DNS conditionnels (CDNS), de graves conséquences peuvent en résulter. »

« CDNS est un type de serveur DNS répandu mais pas encore systématiquement étudié. Il est configuré pour agir simultanément comme résolveur récursif et redirecteur, et les différents modes de serveur partagent le même cache global. En conséquence, les attaquants peuvent exploiter les vulnérabilités du redirecteur et ‘ franchir la frontière » – attaquer les résolveurs récursifs sur le même serveur. »

Vous avez trouvé cet article intéressant ? Suivez-nous sur Twitter et LinkedIn pour lire plus de contenu exclusif que nous publions.





ttn-fr-57