OVH NEWS | ACTUALITÉ, INNOVATION ET TENDANCES IT


Découvrir, comprendre et anticiper









Le 05 / 03 / 2018
Partagez

Dossier rédigé par Sébastien Meriot


1,3 Tbps mitigés par le VAC : retour sur l’épisode Memcached


Jeudi 1er mars, aux environs de 2 h du matin (GMT+1), notre VAC a mitigé une attaque DDoS ciblant l’un de nos clients, dépassant les 1,3 Tbps et par la même occasion le record de 1 Tbps détenu jusque-là par MIRAI. Quelques heures plus tôt, c’était Github qui avait été pris pour cible avec, là encore, une attaque atteignant les 1,3 Tbps. Malheureusement, le site de Github est resté inaccessible pendant quelques minutes. Article écrit avec Alban Lecoq de l’équipe VAC



Ces attaques impressionnantes avaient un point commun : l’utilisation à travers le monde de services Memcached mal configurés pour lancer des attaques dites par amplification. Retour sur une semaine riche en émotions et en investigations…



Figure 1 : Attaque de 1,3 Tbps entièrement mitigée par le VAC à destination de l’un de nos clients.


Memcached : une configuration par défaut mise en cause


Memcached est un cache distribué de type « key/value store » open source. Il est généralement utilisé pour améliorer les performances, notamment sur des sites web, pour conserver les résultats de requêtes en base de données, ou encore le rendu d’une page dynamique. Cet outil est très utilisé par les webmestres ainsi que par certains éditeurs qui n’hésitent pas à embarquer Memcached dans leur solution. C’est le cas du service de messagerie en ligne Zimbra par exemple. Mais pourquoi un service tant utilisé se met subitement à dérailler?



Dès 2017, les chercheurs en sécurité de la société chinoise 360 ont identifié la possibilité d’utiliser un défaut de configuration de Memcached pour émettre des attaques par déni de service amplifiées. En effet, 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.



Attaque par amplification : qu’est-ce que c’est?


L’amplification est un phénomène visant à générer une réponse plus importante que la requête. La Figure 2 montre ainsi une amplification de facteur 2 puisque la réponse est deux fois plus volumineuse que la requête.



Figure 2 : Schéma montrant une réponse deux fois plus importante qu’une requête (facteur d’amplification de 2).


Pour tirer la pleine puissance de ce phénomène et l’utiliser dans des attaques par déni de service, les attaquants vont coupler le mécanisme d’amplification au mécanisme de réflexion. La réflexion consiste à usurper une adresse IP afin que la réponse soit envoyée à l’IP usurpée. En effet, un serveur va répondre aveuglément à l’IP source d’un paquet, même si celle-ci a été usurpée. La victime reçoit donc, sans avoir demandé quoi que ce soit, des paquets du serveur.



Figure 3 : Illustration du mécanisme de réflexion combiné à de l’amplification.


La réflexion est monnaie courante en UDP car c’est un protocole en mode dit « non connecté », c’est-à-dire que contrairement à TCP, il n’y a pas de mécanisme de « three-way handshake ». Il suffit donc d’envoyer un seul paquet pour obtenir une réponse de votre correspondant, là ou pour TCP, il faut à minima un échange de 4 paquets entre le client et le serveur, afin que ceux-ci se mettent d’accord sur l’établissement d’une connexion. Si l’IP était usurpée, la réponse du serveur (SYN-ACK) parviendrait à la victime, et l’initiateur de la connexion ne pourrait pas confirmer (ACK) l’établissement de la connexion, empêchant cette dernière de s’établir et donc rendant inefficace toute usurpation d’IP. Pour en savoir plus, rendez-vous sur la page Wikipédia expliquant relativement bien l’établissement d’une connexion TCP.



Plan d’action chez OVH


Suite à cette augmentation anormale d’attaques par amplification utilisant Memcached, nous avons rapidement mis en place un plan d’action nous assurant de résister en cas de très grosses attaques. L’amplification est un vecteur très facile à identifier, ceci dit, il est nécessaire de nous assurer que nos liens d’interconnexion avec les autres opérateurs (« peering ») ne soient pas saturés afin de ne pas perdre en qualité de service. Notre plan d’action a pu rapidement faire ses preuves lorsque, comme le montre la Figure 1, un de nos clients fut ciblé par une attaque de plus de 1,3 Tbps qui a été parfaitement interceptée par le VAC sans interruption de service.



Ce plan veillait également à empêcher que nos clients sujets à une mauvaise configuration du service Memcached se voient malgré eux impliqués dans des attaques. Il nous fallait pour ce faire :



• Communiquer de manière ciblée auprès des clients potentiellement concernés afin de les accompagner dans la configuration de leur service, au travers d’un guide ;



• Ne pas attendre plusieurs heures/jours que nos clients corrigent le problème, en détectant les IPs OVH servant de réflecteurs et agir directement sur le réseau sans dégrader la qualité de service.



Après concertation, nous avons pris le parti de ne pas bloquer le port UDP/11211 (le port utilisé par Memcached) sur notre réseau, puisque celui-ci peut également être utilisé pour initier des communications en tant que port « client ». Le bloquer pourrait avoir une incidence négative sur la qualité de service, notamment pour les jeux en ligne, la voix sur IP (VOIP), la diffusion en continu et autres services utilisant UDP. Nous avons ainsi favorisé une approche différente, consistant à placer sous mitigation permanente les IPs recevant un très grand nombre de requêtes Memcached par seconde et donc identifiées comme contribuant à des attaques par déni de service. En nettoyant ces requêtes malicieuses en entrée, nous nous assurions que le service de notre client ne servait pas de réflecteur.



Investigations menées


Le 26 février 2018, les premières attaques que nous avons observées étaient générées par des requêtes de type « gets » comme le montre la Figure 4. Tout comme Cloudflare, nous avons constaté que cette commande permettait de lire une clé contenant un fichier « zip », lequel était protégé par mot de passe et contenait un fichier « gif ».



Figure 4 : Requêtes sur le port UDP/11211 (Memcached) reçues dans nos honeypots le 27/02/2018.


Que faisait ce fichier «   zip   » dans ces caches  ? Nous avons tout de suite pensé que les services ciblés avaient été préparés avant les attaques pour ensuite être utilisés, et nous tentons actuellement d’en identifier la source. À l’heure actuelle nous savons que Memcached était déjà utilisé depuis plusieurs jours pour faire de l’amplification. Les graphiques en Figure 5 illustrent la bande passante pour le serveur de l’un de nos clients, lequel était utilisé depuis le 24 février 2018 pour envoyer des attaques contre l’IP chinoise «  59.56.19.xxx  » (nous masquons volontairement le dernier octet).



Figure 5 : Amplification constatée via le port UDP/11211 depuis le serveur d’un de nos clients le 24/02/2018 (fuseau GMT+1).


Nous nous sommes rendu compte que cette IP était régulièrement attaquée par des machines de notre réseau de façon très synchronisée via le phénomène d’amplification (LDAP, NTP, SNMP, etc.). Il existe plusieurs explications à ce phénomène : soit cette IP héberge un service suscitant beaucoup de haine, soit c’est une IP qui a servi de test dans la préparation des attaques par amplification Memcached.



En y regardant de plus près, les attaques contre cette IP sont généralement très courtes : de quelques dizaines de secondes à quelques minutes tout au mieux, alors que les autres attaques durent généralement de longues minutes, la plus significative observée ayant duré 3 heures. Beaucoup d’éléments nous incitent donc à croire que cette IP est un «   dstat   », c’est-à-dire une IP permettant de mesurer en temps réel l’efficacité d’un DDoS.



Cela nous permet d’envisager l’hypothèse que les administrateurs du «  booter  » (plateforme de vente de DDoS) ont probablement voulu comparer leurs différentes attaques par amplification avec l’amplification Memcached. Parmi les tests qui ont tous été menés dans la même tranche horaire, nous observons NTP (UDP/123), LDAP (UDP/389), SSDP (UDP/1900) et BitTorrent.



En continuant nos recherches sur les forums spécialisés du DDoS, nous avons finalement mis la main sur un échange pour le moins explicite comme présenté à la Figure 6 où, un utilisateur reconnaît que sa plateforme de vente de DDoS est la première à avoir mis à disposition l’amplification Memcached.



Figure 6 : Un utilisateur annonce publiquement être l’auteur du script permettant de faire de l’amplification Memcache


Évolution de la menace


En une semaine, les choses ont beaucoup changé : si à l’origine l’idée de l’amplification Memcached semble 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 pièges à pirates ont révélé de très nombreuses façons d’exploiter les services Memcached disponibles sur l’Internet, comme présenté à la Figure 7.



Figure 7 : Répartition des commandes Memcached reçues sur nos  pièges à pirates.


Pour certains services, le fichier « zip » contenu dans la clé «  a  » fait maintenant place à une chaîne «  abcdefghij  » qui se répète des milliers de fois sans que nous y voyions de tentative d’écritures :



Figure 8 : Exemple d’un Memcached avec une clé « a » contenant un bout d’alphabet répété de très nombreuses fois.


Nous avons également observé des clés contenant des messages demandant de payer 50 XMR, une cryptomonnaie populaire également connue sous le nom de Monéro. Serait-ce une tentative de rançon sur des bases de données ne stockant par définition que des données temporaires? Ou bien juste un moyen de remplir le cache pour augmenter le facteur d’amplification?



Figure 9 : Clé « a » d’un service Memcached contenant un message demandant de payer 50 XMR.


Si un petit nombre de services Memcached ouverts a rapidement été corrigé, ils sont encore très nombreux à demeurer utilisables pour commettre des attaques.

À l’instar de NTP, il semblerait que la menace de Memcached soit partie pour durer dans le temps. Même si les protections mises en place par les hébergeurs ont drastiquement réduit la taille des attaques — la majorité est à présent inférieure à 100 Gbps, la correction de la configuration par les utilisateurs reste la clé. Or, le cas NTP nous a montré que, même 5 ans après, des serveurs sont toujours vulnérables, et ce, malgré les correctifs disponibles.

Alors en achevant la lecture de cet article, pourquoi ne pas vérifier l’état de votre pare-feu et jeter un œil aux services que vous exposez sur l’Internet?