Nombreux sont les professionnels de la sécurité qui alertent depuis des mois. L'arrivée de la 5G va faire peser une menace qui n'est certes pas nouvelle, mais qui sera amplifiée, celle des dénis de service qui pourraient accompagner l'apparition de millions de dispositifs connectés et directement accessibles sur le Net, là où ils étaient jusque là "au chaud", sur nos LANs.
Le principe d'un déni de service reste toujours le même : saturer les ressources d'une cible afin de la rendre inaccessible ou de la ralentir significativement. La variété de ces attaques pose aujourd'hui de nouveaux défis aux infrastructures. Les dénis de services impactent la disponibilité, et pour certains (les cybercommerçants notamment), ils attaquent directement le portefeuille. Les conséquences de l'indisponibilité peuvent s'avérer dramatiques. Des chercheurs ont par exemple estimé à quelques milliers de dollars par semaine l'investissement pour ralentir Tor de manière significative et détourner ses utilisateurs de ce réseau.
Trin00 : le premier d'un nouveau genre
Les dénis de service distribués ont plus de 20 ans. En juillet 1999, une université du Minnesota aux USA retrouvait sur plus d'une centaine de machines un script alors baptisé Trin00 .
Les plus anciens se souviendront, quelques mois après cet épisode resté relativement confidentiel, de l'attaque contre Amazon et Ebay en 2000, menée par "Mafiaboy" qui révélait au grand public ce qui allait devenir une des plaies du net (après le SPAM).
Mirai : IoT based DDoS et attaques amplifiées et réfléchies
Mirai ) est le nom d'un logiciel malveillant destiné à prendre le contrôle d'objets connectés. Il ciblait alors une architecture CPU particulière ( ARC ), que l'on retrouve sur une multitude d'objets connectés (notamment des caméras de vidéosurveillance). Son fonctionnement est relativement simple : il recherche sur le Net des cibles vulnérables (entendez dont les utilisateurs n'ont pas pris soin de changer les identifiants/mot de passe par défaut), et s'y connecte pour en prendre le contrôle. C'est ce qui a constitué le gros de ce botnet hors normes de plusieurs centaines de milliers de devices. En multipliant ce nombre par leur capacité respective en bande passante, vous obtenez le parfait cybercanon pour paralyser tout et n'importe quoi.
Plus récemment, c'est OVH qui croulait sous plus d'un terrabit de trafic, un DDoS qu'il a su contrer, et fait remarquable, avec une solution technique maison, le VAC, dont il détaille le fonctionnement ici et qui protège aujourd'hui toute son infrastructure. On prend aisément la mesure des travaux d'OVH sur le sujet, point capital pour lui puisqu'il héberge un très grand nombre de serveurs de jeux que l'on sait être des cibles privilégiées pour rediriger des attaques d'envergure (des machines OVH abusées par des attaquants ont déjà servi à relayer des attaques d'ampleur, notamment sur le site impots.gouv.fr en 2011).
Enfin, on se souviendra également du déni de service sur Github dont le vecteur n'était autre que Memcached . L'attaque, baptisée Memcrashed avait alors culminé à 1,35tb.
En plus de 20 ans, les dénis de service ont beaucoup évolué (on en recense presque une quarantaine avec des spécificités qui leur sont propres). Les derniers dénis de service réseau médiatiques ont dépassé allègrement le terrabit de données. De tels flux sont possibles en utilisant par exemple un DrDos (dénis de service amplifié par réflexion) qui consiste à envoyer une requête d'une poignée de ko dont la réponse, beaucoup plus lourde sera dirigée sur la cible). Notez qu'il est aisé pour l'attaquant de forger ses requêtes en usurpant une adresse source pour masquer la source réelle et surtout une adresse de destination (celle de la victime, qui devra encaisser le flot de réponses aux requêtes qu'elle n'a pas envoyé), c'est ce que l'on appelle le spoofing.
En matière de dénis de service, les DNS demeurent une cible de choix . En innondant de requêtes un domaine, on est asssuré de paralyser tous les services qui y sont attachés, aussi certaines attaques assez spectaculaires enregistrées ces dernières années ciblaient régulièrement ce protocole, spectaculaires car ils impactent par effet domino de très nombreux services en ligne. Un déni de service par amplification sur les DNS peut aisément atteindre un ratio de 1 à 50 .
Size matters (mais pas toujours)
Bien qu'ils puissent être appliqués à toutes la couches du modèle OSI (de la bonne vieille batte de baseball sur le routeur ou d'un coup de bêche bien senti sur une fibre, aux dénis de service sur la couche applicative), les dénis de service peuvent réclamer beaucoup de bande passante pour dégrader un service. Et c'est bien ce constat qui effraie tous les spécialistes avec l'arrivée de la 5G. Mirai n'était qu'un coup de semonce, un proof of concept.
Les denis de services ne sont pas toujours aussi simples à détecter qu'un flux massif, pour exemple, si votre serveur se retrouve avec un très grand nombre de connexions ouvertes et qu'il peine à les fermer, c'est peut-être que vous êtes la cible d'une attaque par déni de service de type slowloris , une attaque vieille de plus de 10 ans. Peu coûteuse en ressources, slowloris saturera vos sockets et votre serveur Apache n'arrivera plus à servir les connexions légitimes... une seule machine sera en mesure de menacer la disponibilité de votre serveur.
Une nouvelle tendance lourde
Nous avons vu que l'Internet des objets offraient une plus grande surface d'attaque aux assaillants, et c'est un protocole, WS-Discovery , qui est la cible de prédilection pour lancer des attaque amplifiées et réfléchies. Un simple scanner de ports comme masscan ...
exemple :
$ masscan -p 3702 --exclude 255.255.255.255 0.0.0.0/0 ... vous fera vite prendre conscience de l'ampleur du problème (attention cette commande scanne tout Internet, votre opérateur pourrait trouver votre intérêt soudain et massif pour les objets connectés un peu suspect). Vous pouvez également consulter Shodan et découvrir de nombreux objets parfois un peu trop connectés.
Mais comme c'est dans les vieux ports que l'on fait les meilleurs floods, ce sont toujours les protocoles SNMP et SSDP qui demeurent les principales autoroutes à dénis de service, ils sont à ce jour les protocoles les plus prisés des assaillants.
DDoS as Service
Nous avons vu apparaitre ces dernières années des botnets mis à disposition du public moyennant quelques bitcoins.
Pour se créer un botnet à moindre coût, des vulnérabilités sur à peu près tout ce qui est connecté sont exploitées pour transformer machines ou objets connectés en "zombies", à même de relayer les attaques. Si les objets connectés représentent une cible de choix, c'est principalement parce qu'ils sont désespérément faillibles : mots de passe administrateurs laissés inchangés par les utilisateurs (qui ignorent même souvent que l'objet connecté en question dispose d'une interface accessible sur le Net), portes dérobées (backdoors) implémentée par les fabricants eux-mêmes, ou vulnérabilités identifiées pour lesquelles les fabricants ne livreront jamais de correctif.
Il y a probablement à ce titre, matière à réguler la prolifération de ces objets connectés en instaurant une date de "déconnexion" à partir du moment où les mises à jour ne sont plus assurées par leur fabricant. Sommes nous prêts à accepter que nos matériels soient rendus innopérants ? N'y a t-il pas des compromis à trouver comme par exemple pousser un industriel ne souhaitant plus assurer les mises à jour à ouvrir son code ? Faudrait-il imposer une déconnexion des services et dispositifs connectés trop anciens, et ainsi renforcer par la loi l'obsolescence programmée qui pose déjà tant de problèmes ? Il faut avoir conscience que chaque objet connecté est comme un débris dans l'espace : ils constituent une menace que nous nous trainerons des années, et leur nombre qui croit à une vitesse effrénée posera tôt ou tard de sérieux problèmes. La 5G est la promesse faite à tout ces objets de s'affranchir du NAT, de se retrouver directement connecté au Net. Le "gain" évoqué, c'est la facilité de configuration... au détriment de la sécurité. C'est d'autant plus surprenant que techniquement on sait router n'importe quoi en TLS grace à SNI , chose que fait HTTP depuis des lustres, et que surtout, la tendance lourde est à cacher ses services derrière Cloudflare et Google , son smartphone derriere 1.1.1.1 (Cloudflare encore) que l'on sait en mesure d'absorber des attaques massives.
Responsabiliser les opérateurs
L'un des paradoxes des DDoS c'est qu'ils ne sont pas rentables que pour l'attaquant. Les volumes échangés d'AS en AS ne sont pas perdus pour tout le monde : comme les opérateurs facturent la bande passante, vous comprendrez que certains ont tout intérêt à laisser faire. Tant que leur infrastructure n'est pas impactée, ils seront naturellement tentés de fermer les yeux parfois même en invoquant le principe de "neutralité".
How to deal with ?
C'est donc aux organisations d'adopter une stratégie pour essayer de s'en prémunir ou d'en atténuer le plus possible les effets, et pour ça, il y a de bons réflexes à adopter avant même de songer à l'étoile noire qu'est rapidement devenue Cloudflare, tant ses services "clic & play" de mitigation des DDoS et de firewalling applicatif sont plébiscitées des utilisateurs. Souvenez vous qu'il est loin d'être anodin de faire passer tout son trafic Internet par l'AS d'une société tierce, et américaine. Cloudflare représente un nouveau point de centralisation, pire, il contribue à rendre SSL à peu près inutile.
Du firewall applicatif aux appliances très coûteuses, une multitude de solutions permettent de se prémunir dans une certaine mesure de ces attaques. Si les attaques amplifiées réfléchies demeurent complexes à contrer et le choix d'un hébergement solide sur une infrastructure robuste sera souvent votre meilleur allié. Des professionnels peuvent vous aider à organiser votre résillience. La grande variété des techniques utilisées de nos jours contraint à la définition de réelles stratégies globales et à appliquer un ensemble de contremesures pour durcir son système d'information.
Bearstech peut vous accompagner dans un plan de reprise d'activité après une attaque, ou en amont en identifiant les points faibles de votre infrastructure et en vous soumettant un ensemble de mesures de durcissement sur les couches applicatives et réseau.
Pour aller plus loin :