GitHub survit à la plus grosse attaque par déni de service distribué jamais enregistrée
Et menée sans réseau de zombies
Le 2018-03-02 08:38:48, par Patrick Ruiz, Chroniqueur Actualités
GitHub a survécu à la plus grosse attaque par déni de service distribué (DDoS) jamais enregistrée jusqu’ici ; c’est ce que rapporte le mensuel américain Wired dans une publication parue hier. La plateforme a été frappée de plein fouet par un tsunami de 1,35 térabit par seconde dès 17 heures 21 minutes (GMT) le 28 février. Wired rapporte que les attaquants n’ont pas fait usage d’un réseau de zombies. « Le service Web d’hébergement et de gestion de développements de logiciels était totalement indisponible entre 17 heures 21 minutes et 17 heures 26 minutes avant de l’être par intermittence pour les 5 minutes suivantes », précise un responsable de la plateforme dans un billet paru hier.
D’après ce que rapporte le mensuel Wired, la plateforme a pu tenir le coup grâce à Akamai Prolexic – son service de mitigation d’attaques DDoS – qui a pris le relais passé les dix premières minutes de l’assaut. L’attaque a duré 8 minutes après l’entrée en scène du service puis s’est estompée, rapporte Wired. En termes de chiffres, l’attaque contre les infrastructures de Dyn en 2016 est désormais connue comme la deuxième la plus foudroyante avec un trafic de 1,2 térabit par seconde.
Pas de botnet, mais des serveurs Memcached en toile de fond
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.
D’après les chercheurs de Qihoo 360, DNS et NTP demeurent les protocoles les plus utilisés pour l’amplification des attaques par déni de service distribué. On devrait toutefois s’attendre à une démultiplication des attaques basées sur l’exploitation des serveurs Memcached compte tenu de la force de frappe qu’elle confère aux cybercriminels.
Sources
Wired
Billet GitHub
Cloudfare
Votre opinion
Voir aussi
D’après ce que rapporte le mensuel Wired, la plateforme a pu tenir le coup grâce à Akamai Prolexic – son service de mitigation d’attaques DDoS – qui a pris le relais passé les dix premières minutes de l’assaut. L’attaque a duré 8 minutes après l’entrée en scène du service puis s’est estompée, rapporte Wired. En termes de chiffres, l’attaque contre les infrastructures de Dyn en 2016 est désormais connue comme la deuxième la plus foudroyante avec un trafic de 1,2 térabit par seconde.
Pas de botnet, mais des serveurs Memcached en toile de fond
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.
D’après les chercheurs de Qihoo 360, DNS et NTP demeurent les protocoles les plus utilisés pour l’amplification des attaques par déni de service distribué. On devrait toutefois s’attendre à une démultiplication des attaques basées sur l’exploitation des serveurs Memcached compte tenu de la force de frappe qu’elle confère aux cybercriminels.
Sources
Wired
Billet GitHub
Cloudfare
Votre opinion
Voir aussi
-
transgohanExpert éminentLa mise à jour automatique est l'un des pires fléaux d'une entreprise... Ce n'est absolument pas contrôlé. Quand on a un seul logiciel passe encore, mais ce n'est jamais le cas, on imbrique des logiciels ensemble pour former un système.
Il y a eu des précédents dans une grande imprimerie française où les machines de productions se sont mises à jour automatiquement suite à une modification de maintenance où le prestataire a cru bien faire.
Résultat ? Chaîne de production contenant un logiciel non compatible avec le reste qui entraînait un arrêt total de l'usine.
Impossible de remettre facilement l'ancienne version, il a fallut faire un backup de toutes les données (manuellement pour certaines choses) et réinstaller tout le système.
4 jours d'arrêt et des pertes colossales.
La mise à jour automatique c'est bien chez madame Michou.
Mais en entreprise cela ne se fait pas car on veut maîtriser le système et son déploiement.le 02/03/2018 à 10:15 -
Je me demande bien quelle est la motivation de cette attaque. Attaquer un gouvernement ou des banques, je vois un peu l'idée mais github je ne comprends pas : les dépôts et releases sont dupliqués (donc pas de pertes ou de blocages réels) et github n'est pas éthiquement la pire entreprise du monde (on peut même dire qu'elle joue un rôle significatif dans l'open-source).le 02/03/2018 à 11:23
-
VulcaniaMembre éclairé@tmcuh et un pas immense à reculons sur la stabilité et la maîtrise des prods....le 02/03/2018 à 9:45
-
abriotdeMembre chevronnéUne attaque DDos ne sert pas simplement a mettre HS un service. Il sert surtout a noyer les infrastructures de sécurité. En fait il crée du bruit qui rends HS les analyseur du réseau (MelPot, sniffeur, pare-feu...). Et les pirates en profitent pour mener en parallèle une attaque beaucoup plus difficile qui sinon serait repéré. GitHub représente un enjeux titanesque car il représente la potentialité d'arriver a compromettre un code source de logiciels hyper utiliser. Imaginez que pendant cette attaque vous ayez mis une backdoor très discrète (dont la date de modification est enregistrée comme très ancienne) dans par exemple WordPress... Bien sur ce que je dis est techniquement très difficile mais potentiellement faisable et une attaque DDoS sur Github a sans doute coûté près de 100 000 euros.Je me demande bien quelle est la motivation de cette attaquele 02/03/2018 à 23:00
-
vizivirMembre du Club@simondecoline , sa peux servir de test pour savoir à quelle point ton attaque est violente pour ensuite attaquer un gouvernement ou une banque . mais sinon je suis comme toi je vois pas vraiment l’intérêtle 02/03/2018 à 16:19
-
FreemMembre émériteLes mise à jour automatique, c'est génial pour la sécurité.
En effet, un système de sécurité est, par définition, parfait, donc personne ne peut insérer de mise à jour malicieuse. Du coup, fatalement, une telle MàJ malicieuse ne pouvant exister, si les opérateurs techniques utilisent la bonne quantité de poudre verte pour nettoyer les bugs, enlever les fonctionnalités non désirées qui mettraient à genoux des machines un peu vieilles mais pourtant fonctionnelles (et pas données, par exemple pour une machine d'atelier de découpe automatique) et adapter la configuration au besoin local, en effet, ça sera un pas de géant pour l'informatique.
En fait, si le personnel technique combine la poudre verte avec une méthodologie certifiée par l'IILaR on atteindrait même le nirvana de l'IT. Je me demande pourquoi personne n'y a pensé avant.le 02/03/2018 à 9:55 -
sergio_is_backExpert confirméle 05/03/2018 à 9:29
-
Je ne connais pas grand chose à la sécurité mais une attaque DDOS de github pour installer une backdoor dans un dépôt, ça me parait difficile car il faut accéder au dépôt pendant l'attaque malgré l'indispo et les sécurités encore présentes (droit d'accès, etc). Et même si tu arrives à modifier le dépôt principal, ça se verra très vite car il y aura certainement des problèmes lorsqu'un dev se synchronisera, et les sommes de contrôle des releases auront changé ce qui sera vite détecté par les mainteneurs de packages des distribs.
Par contre, une attaque DDOS pour cacher une autre attaque, c'est peut-être l'idée effectivement.le 03/03/2018 à 9:57 -
Marco46Expert éminent séniorEffectivement ça tiendrait pas 5 minutes.
Pour ma part je vois plutôt ces attaques comme des PoC. Un comme quand tu les USA et l'URSS faisaient péter des bombes A d'essais dans les années 50. Pour moi c'est de la mise au point et du test d'armements cyber à grand échelle.le 03/03/2018 à 10:11 -
koyosamaMembre éprouvé
Oui pour les meilleurs entreprises. Mais même les meilleurs, ça peut être fatal. Le cas le plus concret je dirais que c'est nodejs. Node JS a des dépendances monstrueuses qui dépend de dépôt github fait par des non-entreprises. Par example, je travaillais avec une entreprise qui dépendait de github. Rappelle toi de MegaUpload quand il a crashé, beaucoup d'entreprise comptait dessus. Certaines entreprise n'ont pas encore cette management de code efficace. Certains code sont des projets d'étudiants aussi qu'on utilise comme dépendance.
J'ai décovert beaucoup de choses horrible lors de mes voyages. Et tout les développeurs ne connaissent pas les outils non plus.
Moi par example, homebrew dépend exclusivement de github, je ne peux plus faire de mise à jour par exemple. Je le sais parce que mon little snitch sniff toutes les sorties et entrée. Après attaqué github c'est peut-être pour attauqer et détuire une autre entreprise qui est basé sur ce modèle, github a une partie pro aussi. C'est pas vraiment la duplication qui vise, mais l'inaccessbilité temporaire. L'art du hacking c'est l'art de la guerre après tout.
En tout, cas je dis bravo à Github. Et puis je me rapelle en cours de sécurité, on prenait des sites comme ça, juste pour s'entrainer. Peut-être que c'était un bon exercice par un étudiant, apprenti-hacker ou même experts, puisqu'il sait que le github a les moyens de se protéger.le 03/03/2018 à 17:08