GitHub survit à la plus grosse attaque par déni de service distribué jamais enregistrée

Version imprimable

02/03/2018, 08h38
Patrick Ruiz

2 pièce(s) jointe(s)

GitHub survit à la plus grosse attaque par déni de service distribué jamais enregistrée

GitHub survit à la plus grosse attaque par déni de service distribué jamais enregistrée
Et menée sans réseau de zombies

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.

Pièce jointe 356344

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.

Pièce jointe 356345

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

:fleche: Quelle politique de mitigation des attaques par déni de service distribué implémentez-vous sur les parcs dont vous êtes responsable ? Partagez votre expérience.

Voir aussi

:fleche: OVH victime de la plus violente attaque DDoS jamais enregistrée par un botnet de caméras connectées qui n'étaient pas sécurisées
02/03/2018, 09h17
tmcuh

Le jour où les système s'auto-mettrons à jour via un système blockchain on aura fait un pas de géant dans la sécurité
02/03/2018, 09h45
Vulcania

@tmcuh et un pas immense à reculons sur la stabilité et la maîtrise des prods....
02/03/2018, 09h55
Freem

Citation:

Envoyé par tmcuh

Le jour où les système s'auto-mettrons à jour via un système blockchain on aura fait un pas de géant dans la sécurité

Les 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.
02/03/2018, 10h15
transgohan

La 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.
02/03/2018, 10h44
MikeRowSoft

Pauvre madame Michou...
Elle connait pas WSUS Offline...
Ou encore faire sa propre ISO de Windows personnalisée avec clé de produit, MAJ et applications pré-installés...

Sinon, sur le sujet, j'analyserai bien les comportements des firewalls en plus des logs traceroute...
02/03/2018, 11h23
Invité

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).
02/03/2018, 11h41
spyserver

Tout ce foin pour 5 minutes d'indispo ...
02/03/2018, 16h19
vizivir

@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êt
02/03/2018, 23h00
abriotde

Motivation

Citation:

Je me demande bien quelle est la motivation de cette attaque

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.
03/03/2018, 09h57
Invité

Citation:

Envoyé par abriotde

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 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.
03/03/2018, 10h11
Marco46

Citation:

Envoyé par SimonDecoline

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.

Effectivement ç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.
03/03/2018, 17h08
koyosama

Citation:

Envoyé par SimonDecoline

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).

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.
04/03/2018, 12h53
Garfaz

Citation:

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.

Heu... je suis pas sûr la majorité des développeurs soient assez vigilent sur ce point... surtout lorsque il y a beaucoup de monde sur un seul projet.
04/03/2018, 15h01
Marco46

Si tu modifies le dépôt en ajoutant un commit ou en rebasant et en forçant le push sur un commit existant ça va se voir dès le premier git pull, soit en ajoutant un commit sur ta branche locale soit en créant une désynchronisation d'historique et en t'empêchant de pull.
05/03/2018, 09h29
sergio_is_back

Citation:

Envoyé par MikeRowSoft

Pauvre madame Michou...
Elle connait pas WSUS Offline...
Ou encore faire sa propre ISO de Windows personnalisée avec clé de produit, MAJ et applications pré-installés...

Sinon, sur le sujet, j'analyserai bien les comportements des firewalls en plus des logs traceroute...

Dommage que les serveurs github ne tournent pas sous Windows !!!!!
:mouarf::mouarf::mouarf: