Comment les acteurs malicieux contournent vos protections Web
Je sors d’une présentation dans laquelle il était sujet de protection contre les attaques de type « déni de service distribué ». Malgré que la principale solution exposée par les présentateurs m’était déjà connue, j’ai tout de suite réfléchi à comment il m’avait été possible dans le passé de trouver l’adresse IP réelle d’une application Web malgré qu’elle était derrière un CDN (Content Delivery Network) ou encore un WAF (Web Application Firewall) et d’ainsi avoir le champ libre pour l’attaquer directement selon les paramètres établis au préalable avec le client, cela va de soi 😉
Pourquoi l’exposition de l’adresse IP de votre application Web peut potentiellement causer un danger pour votre organisation? En la possédant, l’acteur malicieux est en mesure de prendre des actions sur celle-ci et les services qui y sont rattachés sans passer par votre CDN/WAF qui normalement va protéger ceux-ci. Les méthodes de protection communes peuvent être:
- Contrôle du débit; (Rate Control)
- Protection contre les requêtes malicieuses communes; (ex: Injection SQL, XSS, XXE, etc.)
- Protection contre le trafic provenant de source à faible réputation;
- Protection contre les attaques abusant des systèmes d’authentification.
Attention: Un CDN n’offre pas nécéssairement des fonctionnalités de protection d’un WAF.
Afin de permettre de comprendre le concept, voici un exemple avec la plateforme CFQ. Lorsque vous tentez d’accéder au site Web, les adresses IP fournies sont celle de Cloudflare et non celle du véritable serveur qui héberge l’application. Lorsque votre requête passe via Cloudflare, elle sera analysée et advenant que celle-ci ne corresponde à aucune règle de blocage en place, elle sera redirigé vers le serveur qui lui est connu de Cloudflare. Ceci est transparent pour l’utilisateur et limite votre exposition en plus de servir votre application plus rapidement et d’assurer une couche de protection supplémentaire.
Trouver l'IP du service Web
Tout ce contexte pour en venir à un problème bien répandu, la mauvaise cyberhygiène en lien avec vos sous-domaines! (Parce qu’on sait que c’est toujours la faute des DNS 🤡)
Il existe des outils permettant d’essayer des centaines, milliers, millions de sous-domaines en lien avec votre nom de domaine et cela permet d’obtenir la liste des adresses IP liées à vos services.
Fort probablement que votre organisation utilise des sous-domaines dans le style: dev.votredomaine.ca, www.votredomaine.ca, mail.votredomaine.ca, ftp.votredomaine.ca, etc.
Bien souvent, les organisations vont protéger leurs sous-domaines principaux qui permettent d’accéder au site Web (ex.: www.votredomaine.ca et votredomaine.ca), mais ne vont pas ajouter les autres comme « ftp ». Ceci va permettre à un acteur malicieux de trouver l’adresse IP de l’un de vos systèmes et à partir de là, selon la complexité de votre infrastructure, il pourrait suffire de quelques minutes pour confirmer qu’il s’agit également de celle utilisée par votre site Web.
Bon, pas de jugement svp 😉 ça fait longtemps que je suis passé du côté défensif et cet outil date un peu (Gobuster), mais il reste mon arme de prédilection si je dois effectuer des actions de découvertes sur un site Web ou sur un domaine.
Il est possible à l’aide d’une liste de mot (dictionnaire) de lancer une recherche sur l’ensemble des mots fournis et d’ensuite résoudre ces sous-domaines afin d’obtenir leur adresse IP. Voici un exemple avec google.com.
Conclusion
Maintenant, vous serez mieux équipé pour comprendre l’une des techniques utilisées par les acteurs malicieux afin de contourner vos mesures de protections offertes par votre CDN (exposition) et/ou votre WAF (protection). En forçant ses outils vers votre serveur directement sans passer par le CDN/WAF, l’attaquant s’assure que ses requêtes passent sans problème vers votre application.
L’impact pourrait être limité en s’assurant de garder une bonne hygiène au niveau de vos entrées DNS (sous-domaines) et de protéger l’ensemble de vos sous-domaines lorsque possible, par le CDN/WAF. Une bonne règle de pouce pourrait être de réviser celles-ci annuellement.
Profitez de cet article pour en discuter avec vos équipes et vérifier comment votre organisation limite son exposition et protège au maximum ses services exposés.
