L’attaque par déni de service (DoS) évolue.
Après l’usage de l’IoT comme levier d’attaque contre le service DynDNS par le « bot Miraï », l’attaque DDoS massive se trouve un nouveau créneau. Il s’agit de l’exploitation des vulnérabilités, notamment d’authentification, découvertes dans les serveurs utilisant le système Memcached et c’est Github qui en fait à nouveau l’amère expérience. Fort heureusement Akamai, a utilisé son expertise pour rétablir rapidement le taux de réponse de la plateforme phare d’hébergement et de gestion de développement de logiciels de l’open source « Github.com ».
L’attaque par déni de service distribuée (DDoS) classique se représente par l’image d’une inondation soudaine d’un réseau afin d’empêcher son fonctionnement et rendant impossible l’accès au serveur. Le serveur est opérationnel. Il envoie et reçoit normalement les paquets. L’attaque DDoS débute par différents biais : surcharge de la bande passante ou épuisement des ressources système. Le réseau est surchargé, le serveur n’arrive plus à traiter les paquets légitimes parmi la masse d’informations entrante.
Cela est rendu possible même avec des ressources limitées contre un réseau moderne de taille importante. Ce type d’attaque dite « asymétrique », est en forte progression du fait de la forte augmentation du nombre d’échanges sur internet et du nombre tout aussi croissant de machines connectées. Ces attaques apparues dès les années 80 se perfectionnent à chaque évènement pour perturber l’activité de sites web, de serveurs de jeux en ligne, de serveurs de vidéo à la demande…
Déjà le 26 mars 2015, Github avait vu son trafic paralysé durant presque une semaine, par une attaque en déni de service d’une intensité jamais égalée constituant l’attaque la plus importante de son histoire jusqu’alors. Des attaques similaires, médiatisées ou non, surviennent chaque jour depuis septembre 1996 où le FAI, Panix a expérimenté l’une des toutes premières DDoS massive. Des exemples de ce type il y en a la pelle ; 2007 la république d’Estonie est ciblée, 2008 les Anonymous tentent de bloquer une partie du web, 2011 c’est au tour de Sony d’y goûter, 2014 une nouvelle attaque massive contre le réseau Playstation. Et en point d’orgue de cette montée en puissance l’attaque de septembre 2016, où le botnet (Miraï) exploitant l’internet des objets (IoT) corrompt les services DynDNS, OVH ainsi que le blog de Brian Krebs avec une attaque coordonnée dont l’ampleur sidère les experts. Le monde réalise alors l’existence de failles tentaculaires dans notre usage du web, la cyber sécurité devient l’affaire de tous.
Pourtant, nouveau coup de semonce ce 28 février 2018, une nouvelle attaque surpassant en volume les attaques jusqu’alors constatées pointe le bout de son nez. La plateforme collaborative Github est à nouveau prise pour cible, subissant « la plus grosse cyberattaque connue depuis l’avènement d’internet » soutenue par un trafic de 1,35 térabit/seconde.
Cette attaque orchestrée par plus d’un millier de systèmes autonomes (ASN) répartis sur des dizaines de milliers de terminaux innove par l’usage de la technique de l’amplification de cette attaque par les systèmes Memcached des serveurs concernés à la manière d’un gigantesque maillage de miroirs. Le point commun à tous ces serveurs utilisés pour formaliser l’attaque, la présence sur tous du service de cache avancé (Memcached), permettant d’effectuer des requêtes sur des données mises en cache directement en mémoire. Ce service de mise en cache est accessible via le protocole UDP, vulnérable à l’usurpation d’adresse IP. Les attaquants ont donc pu réussir à envoyer des requêtes frauduleuses abusives vers ces serveurs mal configurés, en faisant en sorte que les réponses des services Memcached soient directement envoyées vers la cible de l’attaque.
Memcached est un système servant à booster les performances des sites, et via ce dispositif les données sont mises en cache sur un réseau de diffusion de contenu permettant ainsi une exposition moindre des serveurs d’origine (base de données).
Pour répondre aux exigences de disponibilité et de célérité dans la consommation du contenu, le réseau de diffusion de contenu (CDN) est devenu indispensable pour soutenir le volume de trafic. Un CDN, est une plateforme de serveurs optimisée pour l’affichage de contenu sur le serveur le mieux situé pour l’utilisateur final. Il peut tout aussi bien jouer le rôle de proxy et constitue une pierre angulaire de l’infrastructure invisible d’internet. Le réseau de diffusion de contenu (CDN) est l’aiguilleur du trafic, le chef de quai du contenu multimédia web vers tous les terminaux et sous tous les formats.
Akamai, start-up américaine spécialiste de la mise à disposition de serveurs de cache a très vite compris l’ampleur de l’attaque et a soulagé le site web de Github en transférant les requêtes intrusives sur son propre réseau à travers le monde. Josh Shaul interviewé par Wired, explique « n’avoir jamais eu à faire face à 1,5 térabit d’un coup », pour lui il s’agit de la plus importante attaque DDoS divulguée publiquement.
Par rapport à l’ampleur de l’attaque, Github a très bien résisté puisque le site de la plateforme collaborative n’a pas été hors service plus d’un quart d’heure. Il s’agit là d’une performance que peuvent revendiquer Github et Akamai renforçant leur crédibilité dans la gestion de situation de crise, cela leur ayant aussi permis de tester et d’affiner leurs défenses.
Cependant, Akamai s’empresse de rappeler dans une note de blog que le record de l’attaque sur Github ne tiendra pas longtemps. En effet, selon eux « d’autres attaques, potentiellement plus importantes, auront lieu à court terme ».
Malheureusement, cela n’a pas tardé, ce 5 mars 2018 Arbor Networks, spécialiste réseaux et veille américain, rapporte qu’un de ses clients a subi une attaque similaire enregistré a 1,7 térabit/s. C’est l’observatoire Atlas qui confirme l’attaque d’un fournisseur de services basé aux États-Unis. L’attaque utilisait aussi la réflexion avec amplification sur des serveurs configurés avec Memcached toujours avec l’envoi de paquets UDP sur le port 11211. Des chercheurs en sécurité ont par ailleurs alerté sur le fait que les attaques potentiellement paralysantes peuvent s’accompagner d’une demande de rançon pouvant être inséré dans les paquets UDP.
« C’est pourquoi l’information doit absolument remonter aux sysadmins. Il ne fait aucun doute que les sociétés de protection contre les attaques DDoS vont avoir du boulot dans les prochaines semaines notamment en déployant des défenses sur plusieurs niveaux. Elles ont besoin de solutions de protections spécialisées en bordure du réseau afin de se défendre pro-activement contre les attaques applicatives les plus sournoises et complexes, mais aussi d’une protection anti-DDoS dans le cloud à laquelle elles pourront faire appel en cas de montée en puissance d’un assaut. » Comme le préconise Éric Michonnet à travers son article, paru sur le JDN, établissant un historique des DDoS.
Pour prévenir ces failles des contre-mesures doivent être avancées, à commencer par l’installation d’un pare-feu limitant l’accès aux serveurs avec Memcached seulement en local, et l’administrateur réseau doit absolument éviter le trafic externe vers les ports concernés ainsi que désactiver, filtrer ou tout du moins limiter l’arrivée de paquets UDP s’il n’y en a pas l’utilité.
Face à cette menace, OVH fournit un guide pour sécuriser un serveur avec service memcached.
Comment appréhender les conséquences des attaques en déni de service (DoS) au niveau de l’assurance ? Pour répondre à cette question il faut analyser deux volets de l’assurance.
1. Au niveau du risque de Responsabilité Civile.
Lorsque qu’une attaque en déni de service (DoS) a utilisé votre système d’information et que vous êtes mis en cause par un tiers (une victime de l’attaque).
Ce risque peut être couvert avec les assurances de Responsabilité Civile Exploitation et Professionnelle (RCE/RCP) à condition que le risque « fraude informatique et virus ne soit pas exclu ». Si vous ne pouvez pas faire supprimer ce type d’exclusion vous pouvez assurer ce risque dans le volet Responsabilité Civile d’une assurance spécifique dite « Assurance Cyber ».
2. Au niveau du risque de dommages aux biens, pertes financières :
Lorsque vous êtes victime d’une attaque en déni de service (DoS) et que vous subissez des pertes financières.
Ce risque peut être couvert avec une assurance de dommages aux biens et de pertes financières à condition que les causes immatérielles (et les malveillances informatiques) soient prévues à votre contrat. A défaut, ce risque peut être couvert dans le volet Dommages aux biens – pertes financières d’une garantie spécifique dite « Assurance Cyber ».
En conclusion, vous pouvez transférer les pertes financières des cyber risques à des assureurs.
Nous vous conseillons de faire auditer vos contrats d’assurances existant et de mesurer votre interdépendance à vos systèmes d’informations.