Un trafic suspect pourrait tester l’évasion du CDN, selon un expert

C’est la conclusion de Johannes Ullrich, doyen de la recherche à l’Institut SANS, qui a déclaré cette semaine que les pots de miel de son organisation avaient détecté le mois dernier une curieuse quantité de trafic avec des requêtes de serveur incluant des en-têtes liés au CDN.

Peut-être, dit-il, quelqu’un teste-t-il une tactique pour échapper aux défenses du CDN en lançant soit une attaque ciblée, soit une attaque par déni de service distribué (DDoS) généralisée sur un site.

Par exemple, les pots de miel ont vu des en-têtes sur le trafic qui incluent :

• « Cf-Warp-Tag-Id », qui est associé au service Warp VPN de Cloudflare ;
• « X-Fastly-Request-Id », qui est associé au Fastly CDN ;
• « X-Akamai-Transformed », un en-tête ajouté par Akamai ;
• et un casse-tête : « X-T0Ken-Inf0 ». Ullrich pense qu’il pourrait contenir une forme de jeton d’authentification, mais n’en est pas sûr.

Dans une interview, il a déclaré qu’une des explications était qu’un acteur malveillant tentait de contourner les filtres d’un CDN en créant des requêtes de page incluant un en-tête lié au CDN.

Une autre explication possible est que ces demandes transitent simplement par un CDN, mais, a déclaré Ullrich, « les demandes que nous voyons ne ressemblent pas vraiment à cela ».

Les requêtes Internet sont des messages envoyés par un client tel qu’un navigateur Web à un serveur Web, demandant une page Web. Une vague de requêtes peut constituer une attaque DDoS ou masquer un autre type d’attaque.

De nos jours, de nombreuses organisations utilisent des CDN ou des fournisseurs de cloud pour la protection DDoS de base et le filtrage des robots, en plus de l’équilibrage de charge. Dans une configuration typique, a expliqué Ullrich, le DNS est utilisé pour diriger les clients vers le CDN, qui transmet ensuite la demande au serveur Web du client.

Cependant, il y a un problème : si un attaquant parvient à identifier l’adresse IP du serveur Web réel, il parvient souvent à contourner le CDN et à atteindre directement le serveur Web. Les utilisateurs disposent de plusieurs moyens pour empêcher cela. Par exemple, en fonction du CDN sélectionné, il peut être possible d’autoriser l’accès uniquement à partir de l’espace d’adressage IP du CDN. Cependant, pour certains des plus grands fournisseurs, cette liste d’adresses peut être longue et très dynamique.

Une autre option consiste à ajouter des en-têtes personnalisés. Certains CDN proposent des en-têtes personnalisés spéciaux avec des valeurs aléatoires pour identifier les demandes transmises via le CDN. Et une option moins sécurisée consiste à rechercher tout en-tête identifiant le CDN. Cependant, a noté Ullrich, il faut éviter de simplement rechercher un en-tête, car les attaquants peuvent facilement inclure cet en-tête dans leur trafic. Cela semble être l’activité que connaît le pot de miel SANS depuis novembre.

Un porte-parole de l’agence de relations publiques de CDN Cloudflare a déclaré qu’un commentaire ne pouvait pas être organisé dans les délais.

Contenu associé : Comment un fichier de gestion de robots a paralysé le réseau mondial de Cloudflare

Kellman Meghu, architecte en chef de la sécurité chez DeepCove Security, affirme que l’activité observée par les pots de miel de l’Institut SANS n’est pas nouvelle. Mais, a-t-il ajouté, cela ne devient un problème que lorsque le contrôle d’accès est inapproprié ou que les contrôles échouent.

« Les serveurs Web Origin doivent être déployés avec des contrôles d’accès, qu’il s’agisse de groupes de sécurité ou de règles de pare-feu, pour autoriser uniquement la communication avec le service CDN », a-t-il déclaré dans un e-mail. « Le simple fait de déployer votre application Web de manière à ce qu’elle soit accessible au monde entier, puis de superposer un CDN pour faire office de frontal semble être un terrible gaspillage d’argent et d’efforts. Dans le monde actuel de l’infrastructure en tant que code, cela peut et doit être facile à gérer et à atténuer en ce qui concerne les risques. « 

Aditya Sood, vice-président de l’ingénierie de sécurité et de la stratégie d’IA chez Aryaka, a déclaré dans un e-mail qu’une augmentation des demandes incluant des en-têtes liés au CDN « est clairement une expérimentation de la part des acteurs de la menace, et l’usurpation d’identité n’est pas seulement un bruit aléatoire, sa reconnaissance. Les attaques cherchent à découvrir la faible validation de l’origine dans les organisations qui font confiance à la simple présence d’un en-tête spécifique au CDN au lieu d’appliquer des contrôles appropriés tels que les listes autorisées IP, le peering de réseau privé ou la validation cryptographique. Lorsque vous voyez plusieurs empreintes digitales CDN usurpées à peu près en même temps, cela signifie généralement que de nouveaux outils ou des scanners automatisés sont déployés dans la nature.

Un renforcement adéquat de l’origine, qui inclut des listes autorisées IP strictes, des jetons validés ou une connectivité privée, est essentiel pour protéger les sites Web, a-t-il déclaré. « Se fier uniquement à la présence d’en-têtes spécifiques au CDN n’est plus viable, et les organisations qui n’ont pas complètement verrouillé leur infrastructure backend peuvent déjà être exposées. »

Ullrich a ajouté que les CDN et autres services de filtrage du trafic attribueront une valeur unique à chaque client comme preuve que le trafic a transité par son service. Les administrateurs Web doivent donc configurer leurs serveurs Web ou leurs pare-feu de nouvelle génération pour n’accepter que les demandes ayant cette valeur unique.

L’activité observée par SANS est « certainement quelque chose qui devrait être considéré comme un avertissement concernant quelque chose qui pourrait devenir plus important que ce qu’il est actuellement », a-t-il déclaré. « Maintenant, ce n’est qu’une curiosité, mais cela pourrait facilement devenir davantage. Vous (les administrateurs) devez suivre les conseils de votre réseau de diffusion de contenu pour protéger votre serveur Web contre des attaques de ce type. »