Une attaque DDoS memcached établit un nouveau record avec une amplitude de 1,7 Tbps,
Quelques jours seulement après l'attaque contre GitHub

Le , par Stéphane le calme, Chroniqueur Actualités
La semaine dernière, nous apprenions que GitHub a survécu à la plus grosse attaque par déni de service distribué (DDoS) jamais enregistrée jusque là ; l’attaque, qui a frappé le service, avait une magnitude de 1,35 térabit par seconde. Ce qui a donc permis de classer l’attaque contre les infrastructures du fournisseur DNS Dyn, qui a perturbé l’accès à des sites importants comme PayPal, Twitter ou encore Airbnb, en seconde position avec sa magnitude de 1,2 térabit par seconde.

Notons quand même une différence entre les deux : dans le cas de GitHub, les attaquants ne se sont pas appuyés sur la puissance d’un réseau de zombies, contrairement à l’attaque qui a frappé Dyn.

L’infrastructure de GitHub a subi ce qui s’appelle une amplification d’attaque DDoS. Les attaquants usent de divers moyens pour parvenir à donner un effet hyper dévastateur à une attaque par déni de service distribué. Toutefois, l’utilisation de serveurs Memcached permet de porter l’amplification à des puissances jamais obtenues jusqu’ici. D’après les explications de Cloudfare, Memcached est un système distribué de mise en cache des données ; il est open source. Un serveur Memcached fonctionne sur le port TCP ou UDP 1121 et est conçu pour accélérer les applications Web dynamiques en réduisant la charge sur la base de données. Le système est prisé des administrateurs pour améliorer les performances et adapter les applications Web.

Tout le problème ici est que des pirates abusent désormais des serveurs Memcached non protégés. D’après ce que rapporte Wired à ce sujet, on en dénombre 100 000 exposés en ligne et accessibles sans authentification. Une fois en possession de l’adresse IP de sa future victime, il suffit que le cybercriminel envoie une requête à l’un de ceux-ci au travers du port UDP 11211. Selon les chercheurs de Cloudfare, il suffit de quelques octets d’une requête envoyée au serveur libre d’accès pour obtenir une réponse dix mille fois plus grande en direction de la victime.


Le fonctionnement d'une attaque par amplification schématisé par CloudFlare

Cette même technique aurait été utilisée cette fois-ci pour diriger une attaque encore plus grande contre un fournisseur de services américain non identifié.

Selon la société de protection contre les attaques DDoS Arbor Networks, ce fournisseur de services américain a survécu à une attaque qui a atteint un niveau sans précédent de 1,7 térabit par seconde.

Carlos Morales d'Arbor Networks prédit que les attaques memcached ne disparaîtront pas de sitôt en raison du nombre de serveurs memcached exposés.

« Alors que la communauté Internet se réunit pour fermer l'accès aux nombreux serveurs memcached ouverts, le simple nombre de serveurs exécutant memcached ouvertement fera de cette vulnérabilité une vulnérabilité durable que les attaquants exploiteront », a-t-il écrit dans un billet.

Le collègue de Morales, Roland Dobbins, pense que les attaques DDoS memcached ont été initialement utilisées exclusivement par des attaquants qualifiés qui ont lancé des attaques manuellement, mais maintenant elles peuvent être automatisées via des botnets locatifs de type « booter » ou « stressor ».

Il note qu’en 2010, une présentation durant l’édition de cette année à la BlackHat USA indiquait que de nombreux déploiements memcached non sécurisés sur Internet pouvaient être utilisés pour récupérer et éventuellement modifier des bases de données sensibles de services Internet tels que des serveurs Web, des sites de commerce électronique, etc. Et en novembre en 2017, memcached a été identifié comme un vecteur de réflexion/amplification possible par l'équipe de recherche sur la sécurité « 360 Okee » basée en Chine.

En effet, comme l'expliquent les équipes d'OVH, lors de l’installation, Memcached écoute par défaut sur l’interface publique. En l’absence de configuration de règles au niveau du pare-feu, Memcached reste donc accessible depuis l’IP publique d’un serveur à n’importe qui sur Internet. Si le service n’écoutait qu’en TCP, le problème se limiterait à une atteinte à la confidentialité des données, étant donné qu’il n’y a aucun mécanisme d’authentification. Malheureusement, le service écoute également en UDP et c’est là que la situation se complique, puisqu’il devient possible de faire de l’amplification avec un facteur impressionnant pouvant atteindre 51 000, là où NTP n’avait qu’un facteur de 557.

OVH affirme avoir mené de son côté des investigations pour déterminer les origines de l'attaque. Selon eux, les attaques de type memcached ont commencé à être exploitées par un premier service de booter, ces plateformes qui fournissent des attaques ddos « à la demande » avant de rapidement être imitées par la concurrence. Les équipes d’OVH ont ainsi remarqué plusieurs attaques à l’encontre d’une adresse, qu’ils interprètent comme des « tests de puissance » mis en place par des administrateurs de booters.

« En une semaine, les choses ont beaucoup changé : si à l’origine l’idée de l’amplification Memcached semblait provenir d’un seul « booter », d’autres gérants ont rapidement implémenté la fonctionnalité pour la commercialiser auprès de leurs clients. Depuis les premiers cas, nos honeypots ont révélé de très nombreuses façons d’exploiter les services Memcached disponibles sur l’Internet, comme présenté Figure 7. »


Figure 7 : Répartition des commandes Memcached reçues sur nos honeypots.
Source : ArborNetwork (1 et 2), OVH

Voir aussi :

GitHub survit à la plus grosse attaque par déni de service distribué jamais enregistrée et menée sans réseau de zombies


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :