[INFO] Les records d’attaques par déni de service distribué dépassés par l’exploitation de services memcached exposés sur Internet, touchant principalement Github

Comme chaque semaine, le CERT-XMCO partage un bulletin publié durant la semaine précédente. Cette fois-ci, nous vous proposons de revenir sur les nouvelles attaques par déni de services distribué (DDOS) utilisant les serveurs Memcached.

Description :

La semaine dernière, d’importantes attaques de déni de service distribué par amplification ont été observées. Ces attaques reposent sur l’exploitation de serveurs hébergeant un service Memcached exposé sans protections sur internet.

Cette attaque a été découverte par l’équipe chinoise « 0Kee Team » et très bien détaillée dans leur présentation [1].

Un déni de service (DoS) est un dommage associé à l’indisponibilité d’un service, la mise hors ligne d’un équipement ou d’une ressource par exemple, la suppression de données peut elle aussi être considérée comme telle. Les vulnérabilités causant des dénis de service sont le plus souvent des bugs résultant en un crash d’un service, d’un logiciel, d’un équipement et donc son indisponibilité temporaire. Ces indisponibilités sont rarement un gain monétaire pour des attaquants, mais peuvent représenter de très lourdes pertes pour les entreprises et ont été depuis plusieurs années un moyen de protester sur la toile.

Un déni de service distribué (DDoS) vise principalement, quant à lui, à exploiter une faiblesse dans le débit d’accès à une ressource, afin de provoquer l’indisponibilité d’un serveur web par exemple. Un attaquant va alors tenter de saturer le réseau en émettant plus de requêtes que le serveur ou l’infrastructure ne peut en gérer. Les requêtes suivantes sont alors abandonnées ou mises en attente. Pour le moment, il s’agit simplement de déni de service, mais pour dépasser les capacités de gestion d’un serveur web (surtout pour des serveurs conçus pour de la haute disponibilité) le poste d’un attaquant seul ne suffira pas.

C’est là que le déni de service devient un déni de service distribué. L’attaquant va faire appel à une flotte d’autres équipements afin de l’assister dans son attaque, le plus souvent, l’attaque reposera sur des milliers voire des millions d’équipements vulnérables et compromis (des réseaux de BotNet affectant des postes de travail compromis ou encore les millions d’objets connectés non sécurisés laissés en proie au premier malfaiteur venu). Les dénis de service distribués sont d’autant plus complexes à arrêter, car l’attaque provient de très nombreuses sources partageant souvent des indicateurs radicalement différents ne permettant pas de les bloquer efficacement (comme l’origine géographique). Pour plus d’informations sur les attaques DDoS, le botnet Mirai visant l’IoT « Internet of Things » ou encore l’internet des objets connectés a fait parler de lui il y a quelque temps (voir CXN-2018-0139 et CXN-2018-0613).

Enfin, une attaque par amplification, comme son nom l’indique, va viser à provoquer une avalanche à partir d’une boule de neige. Ces attaques se basent plus souvent sur des bugs ou des problèmes de logique, de conception ou encore sur la fonctionnalité même d’un produit afin d’amplifier leurs attaques. Ces attaques sont couramment associées au protocole DNS qui peut rapidement, depuis quelques requêtes, en générer plus encore, mais elles ne s’y limitent pas. Ces risques et attaques sont connus depuis longtemps et ressurgissent de temps à autre (voir le bulletin CXN-2014-2128 de 2014 ou CXN-2016-3662 en 2016).

Nous entrons ici dans un cas très intéressant où l’on combine amplification et distribution pour conduire à des dénis de service d’une ampleur encore jamais vue. GitHub [2] a en effet été ciblé par une attaque dépassant 1,35 Tera Bits par seconde. C’est proche de l’équivalent de 67 000 fois un débit ADSL personnel de bonne qualité ou encore 13 500 fois une connexion en fibre ou câble à 100 Mb/s.

La dernière pièce du puzzle, l’outil exploité rendant cela possible est Memcached. Memcached est un service très populaire, gratuit et open source [3]. Il permet de grandement accélérer le service de ressources et de réduire les charges principalement pour les serveurs web. En effet, de nombreux sites web dynamiques reposent lourdement sur des bases de données pour stocker le contenu servi dans leurs pages. À chaque fois qu’un utilisateur demande le contenu d’une page, des requêtes sont effectuées vers la base de données contenant les informations nécessaires.

Afin d’optimiser le temps de réponse, mais aussi la charge sur les bases de données, de nombreux mécanismes de cache existent tels que Memcached. Il permet de stocker les données les plus demandées directement en mémoire afin d’éviter toutes les entrées sorties impactant trop fortement les bases de données. Ainsi, en demandant une ressource au service Memcached, ce dernier pourra répondre rapidement avec des données pouvant atteindre des volumes importants.

C’est ce comportement légitime qui est à l’origine de l’amplification. Trois (parmi d’autres) problèmes de sécurité font que cette fonctionnalité puisse devenir l’instrument d’attaques par amplification :

1. Support du protocole UDP ;
2. Les serveurs memcached sont souvent utilisés sur des réseaux business avec des débits en Gigabits ;
3. Pas d’autorisation ou d’authentification pour accéder au service.

Le premier point concerne l’utilisation du protocole UDP. Ce protocole peut avoir des utilisations parfaitement légitimes, mais demande une attention particulière par rapport à son fonctionnement et son utilisation. En effet, il est bien plus aisé de pratiquer des usurpations d’émetteur au sein de paquets UDP que pour d’autres protocoles comme TCP. Ainsi, un attaquant usurpera l’adresse de sa cible comme adresse d’émission et verra donc le serveur Memcached répondre massivement à destination de la cible. Le protocole UDP est connu pour être très largement abusé et souvent source d’attaques par amplification, rappelle CloudFlare sur son blog [4] en citant entre autres DNS, NTP, Chargen et SSDP.

Second point, pour que la mise en place d’un service memcached soit justifiée, le plus souvent cela nécessite un site ou une infrastructure à forte demande comme pour une entreprise. Aussi, cette infrastructure dispose donc d’un débit réseau privilégié souvent de l’ordre de plusieurs Gigabits par seconde permettant à ces réseaux d’envoyer un volume très important de données/requêtes en très peu de temps.

Enfin, le dernier point porte sur l’ouverture par défaut du port UDP par le service Memcached. Citant la publication d’Akamai [5] « le protocole Memcached n’a jamais été conçu pour être exposé sur internet ». En effet, ces serveurs devraient servir à alléger les requêtes sur une base de données et, à ce titre, fonctionner et être sécurisés comme des bases de données : ne pas être exposés sur internet, ne répondre qu’aux serveurs légitimes demandant des ressources, etc. Si les serveurs utilisés dans les attaques n’étaient pas exposés ou protégés par des pare-feu solidement configurés, les attaquants n’auraient pas pu conduire ces attaques.

Il s’agit d’un exemple idéal d’une chaine de sécurité, un produit doit prendre en compte les problématiques de sécurité durant tout le processus : de la conception jusqu’au post-déploiement.

Quelques points positifs qu’il ne faut pas négliger ressortent de cette passionnante histoire :

•  Les équipes derrière le projet Memcached ont rapidement corrigé le problème. Notamment en désactivant le port et l’utilisation du protocole UDP par défaut dans la dernière version, et laissant aux utilisateurs la possibilité de l’activer si nécessaire.
•  Shodan permet d’identifier quelque 80 000 serveurs exposés et près de 100 000 selon le projet Sonar. Cette quantité représente une menace importante en termes d’amplification et de volumétrie, mais reste tout à fait raisonnable pour constituer des listes de filtrage afin de bloquer les sources potentielles d’attaque par amplification.
•  Malgré l’ampleur de l’attaque, l’indisponibilité sur une infrastructure telle que Github n’a été que de quelques minutes ce qui est la preuve d’une grande efficacité des solutions mises en place pour assurer la disponibilité des services.

Références :

[1] http://powerofcommunity.net/poc2017/shengbao.pdf
[2] https://githubengineering.com/ddos-incident-report/
[2] https://www.wired.com/story/github-ddos-memcached/
[3] https://github.com/memcached/memcached
[4] https://blog.cloudflare.com/memcrashed-major-amplification-attacks-from-port-11211/
[5] https://blogs.akamai.com/2018/02/memcached-udp-reflection-attacks.html

Référence CERT-XMCO :

• CXN-2018-0921