Le DDoS « Great Cannon » contre GitHub en 2015 a fait de l’inject

Résumé

GitHub a déclaré qu’une attaque distribuée par déni de service avait commencé vers 02 h 00 UTC le 26 mars 2015 et qu’elle mobilisait les navigateurs de personnes étrangères à l’opération pour envoyer des requêtes vers des pages hébergées sur la plateforme. [1]
GreatFire avait signalé une attaque antérieure contre ses propres services. L’organisation a ensuite affirmé qu’un JavaScript malveillant avait été substitué à des ressources associées à Baidu Analytics et a attribué l’activité aux autorités chinoises. Baidu a nié que ses produits aient été compromis. Ces positions restent des déclarations attribuées, non des faits judiciairement tranchés. [7][8]
Citizen Lab et plusieurs équipes universitaires ont décrit un dispositif placé sur certains trajets réseau, capable d’intercepter des requêtes HTTP non chiffrées, d’injecter une réponse de remplacement et d’amener des navigateurs situés hors de Chine à solliciter répétitivement des cibles. [2][3][4][5]
Les chercheurs ont distingué ce dispositif, baptisé Great Cannon, du Great Firewall, tout en relevant des ressemblances de code et de localisation. Leur évaluation étaye l’hypothèse d’un opérateur étatique probable, sans constituer une attribution juridiquement établie ni identifier une chaîne individuelle de commandement.
Il ne s’agissait ni d’une réflexion fondée sur l’usurpation d’adresse IP ni d’un botnet conventionnel constitué de machines durablement compromises. Les navigateurs émettaient de véritables requêtes depuis leurs propres adresses après avoir exécuté le contenu injecté.
La validation des adresses sources demeure essentielle contre les trafics usurpés, mais elle ne bloque pas directement des connexions authentiques déclenchées par du code substitué dans une réponse web. [11][12][13][14][17]
Le chiffrement authentifié réduit fortement la possibilité d’altérer silencieusement une ressource sur le trajet. Il ne supprime toutefois ni le blocage, ni la compromission d’une extrémité, ni l’analyse du trafic, ni toutes les formes de DDoS. [15][16]
La responsabilité doit être répartie selon le contrôle réel : opérateurs du trajet, éditeurs de ressources tierces, sites qui les intègrent, navigateurs, GitHub, transitaires et prestataires d’atténuation ne possédaient ni les mêmes capacités ni les mêmes preuves.
La leçon durable est celle de la primauté du code en fonctionnement : une adresse, un enregistrement DNS ou un contrat décrit une relation prévue ; seules des observations reproductibles montrent quels octets ont réellement été livrés et exécutés.

En mars 2015, GitHub a été confronté à une attaque dont la caractéristique décisive ne résidait pas seulement dans son ampleur. GitHub l’a alors qualifiée de plus importante attaque DDoS de son histoire. Mais son intérêt durable tient surtout au déplacement du point de contrôle : une infrastructure située sur le trajet d’un trafic web ordinaire aurait transformé des navigateurs appartenant à des personnes sans lien avec l’opération en générateurs de requêtes contre des pages hébergées par GitHub.

Un internaute pouvait consulter un site sans chercher à joindre GitHub. Son navigateur demandait une ressource tierce transmise en HTTP non chiffré. Au lieu du contenu attendu, une réponse substituée pouvait lui parvenir et contenir un programme JavaScript ordonnant des requêtes répétées vers une cible. Le navigateur établissait alors de vraies connexions depuis sa véritable adresse. L’activité nuisible ne provenait ni d’une fausse adresse source ni nécessairement d’une infection persistante de l’appareil. Elle résultait d’une instruction insérée entre la ressource attendue et le code effectivement exécuté.

Cette distinction interdit de réduire l’incident à une formule générique sur les cyberattaques. Le cœur du problème était une capacité d’infrastructure : observer une requête en clair sur un trajet partagé, tenter de remplacer la réponse et exploiter l’exécution normale du navigateur. Enlever de l’analyse le transit, l’intégrité des réponses, le transport authentifié, les dépendances tierces et la défense en bordure de GitHub ferait disparaître la thèse elle-même.

L’affaire constitue ainsi un test de responsabilité des réseaux. Elle oblige à demander non seulement qui a été visé et avec quel objectif supposé, mais aussi qui pouvait modifier le trafic, qui pouvait constater la divergence, qui conservait les traces nécessaires, qui maîtrisait l’exécution du code et qui pouvait maintenir le service sans faire porter la faute sur des usagers privés de choix réel.

Ce que les faits publics permettent d’affirmer

Le communiqué de GitHub est le point de départ le plus sûr pour décrire la frontière opérationnelle de la victime. L’entreprise a indiqué que l’attaque avait commencé aux environs de 02 h 00 UTC le jeudi 26 mars 2015. Elle a évoqué plusieurs vecteurs, dont de nouvelles techniques utilisant les navigateurs de personnes étrangères à l’attaque pour inonder le site. GitHub a aussi expliqué que les informations alors disponibles lui faisaient penser que l’objectif consistait à la pousser à retirer une catégorie déterminée de contenus. [1]

Ce témoignage établit ce que GitHub constatait depuis son propre service ainsi que son interprétation de la pression exercée. Il ne donne pas pour autant un relevé exhaustif de l’événement. Le dossier public ne permet pas d’énoncer un volume total définitif, un nombre exact de navigateurs enrôlés, une perte financière, une durée précise de rétablissement ou l’identité d’une personne ayant ordonné l’opération. L’interprétation de GitHub quant au but recherché ne vaut pas davantage jugement sur son commanditaire.

GreatFire fournit une chronologie complémentaire du côté d’une autre victime. L’organisation avait annoncé que ses services subissaient depuis le 17 mars un important afflux de requêtes. Elle a ensuite affirmé que du JavaScript malveillant avait remplacé des ressources associées à Baidu Analytics afin d’orienter des navigateurs vers du contenu de GreatFire et vers deux pages hébergées par GitHub. GreatFire a attribué l’activité aux autorités chinoises. Dans le même dossier, Baidu a nié que ses produits aient été compromis. [7][8]

Il faut maintenir ces propositions séparées. Le récit de GreatFire est celui d’une organisation affectée, assorti d’une attribution explicite. Le démenti de Baidu porte sur ses propres produits. Une compromission des serveurs de Baidu, une participation consciente, un détournement externe et une substitution sur le trajet sont quatre hypothèses différentes. L’intérêt technique de l’injection sur le trajet est précisément qu’elle peut faire apparaître une ressource légitime comme l’origine d’un code que son éditeur affirme ne jamais avoir servi.

La reconstruction publique la plus détaillée est venue de Citizen Lab, de l’International Computer Science Institute, de chercheurs de l’Université de Californie à Berkeley, de Princeton et de leurs collaborateurs. Ces équipes ont distingué le Great Cannon du Great Firewall tout en relevant des proximités de code et de positionnement réseau. Elles ont décrit un système susceptible de sélectionner des requêtes HTTP non chiffrées, de leur opposer un contenu différent de celui de l’origine et de provoquer des requêtes répétées depuis des navigateurs situés notamment hors de Chine. [2][3][4][5]

Leur raisonnement reposait sur des mesures, des différences observables selon les trajets et des caractéristiques techniques reproductibles. Il soutenait l’évaluation d’un opérateur gouvernemental probable. Cette formulation doit conserver ses limites : elle ne constitue ni une décision de justice, ni la publication d’un ordre opérationnel, ni la preuve d’une responsabilité individuelle. La qualité de l’attribution vient justement de la méthode et de l’expression de l’incertitude, non de la transformation d’une forte hypothèse technique en certitude absolue.

Des travaux universitaires connexes ont approfondi les comportements observables de l’injection et les manières de la caractériser. [6] Ils renforcent l’importance de la localisation technique et des différences de réponse. Ils ne comblent pas automatiquement les lacunes concernant les décisions humaines, les habilitations institutionnelles ou les actions précises de chaque opérateur.

Le socle factuel est donc étroit mais solide : GitHub a subi un DDoS majeur ; GreatFire a documenté une séquence antérieure et formulé sa propre attribution ; des chercheurs ont décrit un dispositif distinct capable de substituer du code à certaines réponses en clair ; des navigateurs ont ensuite généré des requêtes vers les cibles ; Baidu a contesté la compromission de ses produits ; plusieurs éléments opérationnels et institutionnels restent inconnus.

De la ressource demandée au code réellement exécuté

Le mécanisme oblige à distinguer trois identités souvent confondues.

La première est l’identité déclarée de la ressource. Une page mentionne une adresse, le DNS fournit une destination et le navigateur tente d’obtenir un contenu déterminé. Cet ensemble décrit l’intention de la requête, pas nécessairement la provenance authentique des octets reçus.

La deuxième est l’identité du contenu accepté. En HTTP non chiffré, le navigateur ne dispose pas d’une preuve cryptographique garantissant que la réponse n’a pas été modifiée entre l’origine désignée et lui. Un système situé sur le trajet peut observer la demande et tenter de faire accepter une réponse concurrente. Le nom de domaine peut rester correct alors que le contenu exécuté ne correspond plus à celui publié par l’origine.

La troisième est l’identité du client qui contacte ensuite GitHub. Son adresse source peut être parfaitement authentique du point de vue topologique. Elle indique d’où vient la connexion, mais ni l’intention de l’utilisateur ni l’origine de l’instruction. Traiter cette adresse comme la preuve que son titulaire a volontairement participé à l’attaque serait une erreur d’attribution au niveau le plus élémentaire.

Le navigateur n’avait pas besoin d’être enrôlé durablement dans un botnet. Le code pouvait n’exister que dans le contexte temporaire d’une page. Aucune persistance, aucun logiciel malveillant installé à l’avance et aucun contrôle continu de l’appareil ne sont nécessaires pour expliquer le comportement décrit. Parler de « machines compromises » sans nuance masquerait donc la différence entre l’exécution momentanée d’un contenu substitué et la prise de contrôle conventionnelle d’un terminal.

Le mécanisme n’est pas non plus celui d’une réflexion avec adresse usurpée. Dans une attaque réfléchie classique, l’assaillant falsifie souvent l’adresse de la victime afin que des services tiers lui renvoient leurs réponses. Ici, les navigateurs établissaient eux-mêmes des connexions applicatives plausibles. La difficulté de GitHub consistait précisément à distinguer ces demandes nuisibles de communications web ordinaires issues d’utilisateurs qui n’avaient pas choisi la cible.

Cette chaîne déplace la question de responsabilité. Il ne suffit plus de savoir quel domaine figurait dans la page ou quelle adresse avait émis la dernière requête. Il faut déterminer ce qui a été demandé, ce qui a été reçu, sur quel trajet, avec quelle protection de transport, à quel moment et avec quel effet dans le navigateur. L’incident devient une question de garde et d’intégrité du contenu à travers plusieurs domaines administratifs.

La primauté du code en fonctionnement

La thèse Heng.lu apporte ici une règle de lecture décisive : un registre est un grand livre et un dispositif de traçabilité, non une autorité souveraine sur la réalité technique. Les inscriptions administratives sont indispensables pour comprendre les intentions, les responsabilités déclarées et les ressources attribuées. Elles ne peuvent pas, à elles seules, prouver ce que le réseau a effectivement livré.

Un enregistrement DNS peut identifier le service attendu. Une inscription d’adresse peut relier une ressource à une organisation. Une relation de transit peut documenter un lien commercial. Une page d’état peut décrire ce que l’opérateur croit être en train de se produire. Aucun de ces éléments ne démontre isolément que le navigateur a reçu les octets produits par l’origine désignée.

Le Great Cannon rend cette limite concrète. Un navigateur pouvait résoudre le bon nom, emprunter un trajet apparemment cohérent et demander une ressource reconnue, tout en exécutant un contenu qui aurait été inséré en cours de route. L’identité administrative restait visible tandis que le comportement réel divergeait. La responsabilité commence à l’endroit où cette divergence peut être observée, expliquée et reliée à un contrôle.

La primauté du fonctionnement ne signifie pas que les registres sont inutiles. Les données DNS, les annonces BGP, les inscriptions d’adresses, les relations d’interconnexion, les chaînes de certificats, les en-têtes HTTP et les journaux de service constituent des repères essentiels. Leur valeur vient de leur confrontation avec les réponses reçues depuis plusieurs réseaux, les empreintes cryptographiques du contenu, la chronologie des événements, les traces d’exécution du navigateur et les mesures de disponibilité.

Cette approche empêche également de prendre la géolocalisation ou la propriété nominale d’une adresse pour un verdict. Une inscription indique généralement une attribution ou un contact administratif. Elle ne prouve pas quel équipement a produit un comportement à un moment donné, qui le contrôlait, ni si une réponse observée provenait de l’origine ou d’un mécanisme concurrent situé sur le trajet.

La couche de réalité n’est pas un plaidoyer en faveur de GitHub, de GreatFire, de Baidu, d’un gouvernement ou d’une politique universelle de chiffrement. Elle impose des questions plus strictes : quels opérateurs pouvaient altérer le trafic en clair ? Qui pouvait comparer des réponses divergentes ? Quelles décisions ont protégé l’intégrité du service ? Quelles affirmations reposent sur des mesures, et lesquelles restent des appréciations attribuées ?

Répartir la responsabilité selon le contrôle réel

La responsabilité ne peut être attribuée en bloc à l’acteur le plus visible. Chaque participant maîtrisait une partie différente de la chaîne.

GitHub et la frontière de disponibilité

GitHub contrôlait le service ciblé. L’entreprise pouvait classifier les requêtes, ajuster ses limites, répartir la charge, protéger les pages visées, coordonner ses transitaires et son prestataire d’atténuation, puis informer ses utilisateurs. Elle ne pouvait pas directement empêcher un système étranger à son infrastructure de modifier une réponse tierce sur un trajet distant.

Un texte antérieur de GitHub consacré à la défense contre les dénis de service décrit une approche en couches : réglage de la pile réseau, limitations au niveau des répartiteurs, équipements de filtrage et coopération avec un prestataire externe. [9] Ce document fournit un contexte d’architecture, pas la preuve que chaque contrôle était actif, configuré de la même manière ou efficace pendant l’événement de mars 2015.

Une trace responsable du côté de GitHub aurait dû relier les changements de filtrage aux effets mesurés sur le service : chemins sollicités, santé de la bordure et des applications, erreurs visibles, saturation, transferts vers l’atténuation, faux positifs et conséquences pour le trafic légitime. Les informations publiques ne dévoilent pas l’intégralité de ces décisions. Ce silence doit rester une inconnue, non servir à inventer une réussite parfaite ou une négligence.

Le problème de classification était particulièrement délicat. Les requêtes pouvaient ressembler à du trafic web valide. Bloquer automatiquement chaque adresse active risquait de pénaliser des internautes qui partageaient une connexion ou dont le navigateur avait été utilisé à leur insu. Retirer les pages ciblées aurait peut-être modifié l’incitation de l’assaillant, mais aurait aussi transféré à la pression réseau une partie du pouvoir de décision sur l’hébergement.

Les opérateurs du trajet

Un système capable d’observer et de modifier une réponse en clair détient un pouvoir technique supérieur à celui d’un simple relais aveugle. Ce pouvoir crée une obligation de preuve : règles autorisant la fonction, interfaces concernées, changements de configuration, rôles habilités, horodatages, mécanismes d’intégrité et restrictions contre les usages non autorisés.

Cette exigence ne rend pas chaque transitaire responsable de toute altération. Les trajets traversent plusieurs domaines et peuvent changer pendant un incident. Certains opérateurs ne voient qu’une portion du trafic ; d’autres n’ont aucune capacité applicative. La responsabilité doit suivre la faculté réelle d’observer, d’altérer ou de conserver des éléments vérifiables.

Les observations BGP peuvent préciser quels systèmes autonomes annonçaient la destination et quels chemins étaient visibles depuis certains points. Elles ne suffisent généralement pas à localiser une substitution de contenu. Un trajet interne, une politique invisible depuis l’extérieur ou une course entre deux réponses peuvent échapper aux données publiques de routage. Il faut donc associer le contexte de contrôle de route aux mesures actives et aux différences de contenu.

Les relations d’interconnexion et de transit ajoutent une difficulté commerciale. Les contrats et les architectures sont rarement publics dans leur intégralité. Cela ne supprime pas l’obligation de conserver des identifiants d’interface, des instantanés de route, des autorisations de changement et des empreintes d’événements. Un opérateur peut protéger des détails sensibles tout en produisant des conclusions bornées et vérifiables.

Les éditeurs de ressources et les sites intégrateurs

L’éditeur d’une ressource tierce contrôle son mode de distribution, l’activation du transport authentifié, certaines règles de cache et sa capacité à rechercher pourquoi des clients ont reçu des contenus différents. Le site qui intègre cette ressource décide s’il introduit une dépendance exécutable en clair dans la page. Ces responsabilités sont réelles, mais elles ne prouvent aucune participation à l’attaque.

Le démenti de Baidu doit rester visible : l’entreprise a nié que ses produits aient été compromis. [8] Une analyse loyale doit comparer les journaux de l’origine, les contenus reçus depuis plusieurs trajets, les protections de transport et les empreintes disponibles. La présence du nom d’un éditeur dans une adresse ne permet pas d’affirmer qu’il a produit, approuvé ou même observé le code substitué.

L’inventaire des dépendances est ici une mesure de responsabilité. Un site devrait connaître chaque script externe qu’il fait charger, le protocole utilisé, l’organisation qui le publie, sa méthode de mise à jour et son comportement en cas d’échec. Une ressource capable d’exécuter du code mérite un contrôle plus strict qu’un contenu purement décoratif.

Les navigateurs et les plateformes

Le navigateur se trouve à la frontière entre contenu reçu et action réseau. Il décide d’exécuter le script, applique les règles d’origine, traite les contenus mixtes, valide les certificats et peut limiter certaines activités en arrière-plan. Ces décisions dépendent à la fois des standards, des éditeurs, des auteurs de sites et des réglages locaux.

Un navigateur ne peut pas conclure que toute succession de requêtes est malveillante. Les applications web légitimes produisent elles aussi de nombreux échanges asynchrones. Des limites trop sévères casseraient des services normaux ; des limites trop permissives peuvent laisser une page consommer la bande passante ou solliciter massivement une cible. La responsabilité des navigateurs consiste donc à réduire l’enrôlement silencieux sans prétendre résoudre seuls un problème qui traverse plusieurs couches.

Pourquoi l’anti-usurpation ne suffisait pas

Les recommandations relatives à la validation des adresses sources répondent à un problème fondamental d’Internet. BCP 38 et les textes associés demandent aux opérateurs de filtrer les adresses qui ne devraient pas provenir d’une interface donnée. Les approches de type uRPF adaptées aux chemins multiples tentent de rendre cette vérification déployable dans des réseaux réels. Les recommandations du NIST inscrivent ces mécanismes dans une stratégie plus large associant sécurité du routage et atténuation des DDoS. [12][13][14][17]

Ces contrôles limitent les attaques dans lesquelles l’émetteur prétend utiliser l’adresse de sa victime. Ils réduisent notamment certaines possibilités de réflexion et d’amplification. Leur déploiement reste indispensable.

Le mécanisme attribué au Great Cannon se situait ailleurs. Après avoir exécuté le JavaScript injecté, le navigateur ouvrait une connexion depuis une adresse qui lui appartenait effectivement. Pour un filtre topologique, la source pouvait être parfaitement plausible. Le caractère nuisible provenait de l’instruction applicative à l’origine de la connexion, non d’une falsification du champ d’adresse.

Cela ne rend pas l’anti-usurpation inutile pendant un incident complexe. Plusieurs vecteurs peuvent coexister, et la suppression du trafic forgé préserve les capacités d’atténuation. Mais prétendre que la seule validation des sources aurait arrêté l’enrôlement des navigateurs reviendrait à appliquer un contrôle à une propriété qu’il ne modifie pas.

Chaque défense doit être reliée à sa fonction exacte. L’anti-usurpation traite les fausses adresses. Le transport authentifié protège l’intégrité de la communication entre extrémités authentifiées. Les politiques du navigateur encadrent l’exécution et les demandes transversales. Le filtrage en bordure limite la consommation de ressources. La capacité, la mise en cache et l’atténuation protègent la disponibilité. Aucun mécanisme ne couvre seul la chaîne entière.

Le transport authentifié change la possibilité d’injection

HTTP en clair ne fournit pas au navigateur de garantie cryptographique sur l’intégrité de la réponse. Un système ayant accès au trajet peut observer la demande et tenter d’introduire un contenu différent. Le scénario du Great Cannon exploitait cette propriété.

Un canal TLS correctement authentifié modifie profondément la situation. Le navigateur attend une identité vérifiable et une communication protégée contre l’altération dans le cadre prévu par le protocole. RFC 7258 traite la surveillance généralisée et la subversion des communications comme des attaques auxquelles la conception des protocoles doit résister. TLS 1.3 formalise un canal authentifié et chiffré destiné notamment à empêcher l’écoute, la falsification et la modification silencieuse. [15][16]

Lorsque la validation fonctionne et que l’extrémité n’est pas compromise, un opérateur placé sur le trajet ne peut plus simplement remplacer une réponse tout en la faisant accepter comme authentique. Une tentative d’altération devrait produire un échec visible plutôt qu’un programme exécuté sous l’identité attendue. Le chiffrement authentifié augmente donc fortement le coût de l’injection et améliore la qualité des indices disponibles.

Sa portée doit néanmoins rester précise. HTTPS n’empêche pas de bloquer une connexion, de réinitialiser un échange ou de manipuler un trajet. Il ne protège pas une origine déjà compromise, ne garantit pas l’innocuité du code légitime, n’absorbe pas un afflux massif et ne supprime pas l’analyse des métadonnées. Il ne constitue ni un remède universel contre la censure ni une protection complète contre tous les DDoS.

La conclusion raisonnable est plus étroite : l’authentification du transport réduit directement l’occasion de substituer sans alerte une ressource exécutable. Une défense responsable doit donc documenter les ressources encore accessibles en clair, les dépendances mixtes, le comportement de validation des navigateurs et les différences constatées selon les trajets.

Mesurer depuis plusieurs réseaux

Une infrastructure d’injection peut agir sélectivement. Elle peut viser un nom, un chemin de ressource, une chaîne de requête, une destination, une origine géographique ou une période. Elle peut intervenir sur certains trajets et rester invisible sur d’autres. Une observation unique ne permet pas de distinguer sûrement une anomalie de l’origine, une altération intermédiaire et un problème local.

Des mesures depuis plusieurs réseaux permettent de comparer la même ressource dans des conditions différentes. Les chercheurs peuvent confronter les octets reçus, leurs empreintes, les en-têtes, le résultat de la validation cryptographique, la résolution de noms, la route approximative et la chronologie. Lorsqu’un point reçoit un contenu modifié tandis qu’un autre obtient la réponse attendue, la différence réduit l’espace des hypothèses.

La temporalité compte autant que la géographie. Si une première réponse anormale précède une réponse conforme, l’ordre d’arrivée peut étayer l’hypothèse d’une injection par course. Si l’origine ne conserve aucune trace du contenu substitué, une compromission du serveur devient moins probable, sans être automatiquement exclue. Si plusieurs réseaux observent la même divergence au même moment, la localisation possible se resserre encore.

Les observations brutes doivent rester distinctes des inférences. Les premières comprennent les horaires, la ressource demandée, les contenus reçus, les empreintes, les résultats de validation, les traces réseau, le comportement du résolveur et le contexte de route. Les secondes portent sur l’emplacement probable de l’injecteur, ses ressemblances avec une autre infrastructure et l’identité vraisemblable de l’opérateur.

La qualité des horloges est déterminante. Relier la récupération d’une ressource, l’exécution du code et les requêtes ultérieures vers GitHub exige des horaires comparables. Il faut connaître les sources de temps, les écarts possibles, les retards de collecte et les conversions de fuseau. Une chronologie visuellement convaincante peut être trompeuse si ses horloges ne sont pas maîtrisées.

La conservation doit en outre respecter la vie privée. Les traces de navigateur peuvent révéler des habitudes personnelles et les enregistrements réseau contenir des données sans rapport avec l’incident. Une enquête responsable limite la collecte, contrôle les accès, produit des empreintes des éléments utiles et élimine ce qui n’est pas nécessaire. La protection des personnes n’interdit pas la preuve ; elle en définit la proportion.

Un socle minimal de preuves opérationnelles

Face à une injection comparable, une organisation devrait être capable de constituer huit ensembles cohérents.

1. Identité de l’événement et intégrité temporelle

Un identifiant stable doit relier les premières anomalies, la confirmation, chaque mesure d’atténuation, la stabilisation et la clôture. Les horaires d’occurrence et de collecte, les sources de temps et les écarts connus doivent être conservés.

2. Identité de la ressource et du transport

Il faut enregistrer l’adresse demandée, le protocole, le nom d’hôte, le résultat DNS, l’origine attendue, les détails du certificat lorsqu’ils existent, les en-têtes, l’empreinte du contenu et la décision du navigateur. Le nom seul ne prouve jamais les octets.

3. Contexte de trajet depuis plusieurs points

Chaque observation doit préciser son réseau, son emplacement approximatif, son résolveur et le contexte de route connu. Les données publiques de routage et les instantanés des opérateurs complètent l’analyse sans prétendre localiser seuls l’injection.

4. Exécution dans le navigateur

La trace doit montrer le comportement du programme, les destinations sollicitées, la répétition des demandes, la version du navigateur, les règles de sécurité pertinentes et la nécessité éventuelle d’une action de l’utilisateur. L’exécution temporaire doit rester distincte d’une compromission persistante.

5. État du service victime

GitHub et ses partenaires devaient pouvoir relier les chemins ciblés, la santé de la bordure, la charge applicative, les actions de filtrage, les changements de capacité, les erreurs et les effets collatéraux. Chaque décision devrait avoir un résultat observable et une condition de retour arrière.

6. Contrôle de l’opérateur

Toute interface capable d’inspection ou d’altération devrait être associée à une autorisation, une configuration, un propriétaire opérationnel, des journaux d’accès et des garanties d’intégrité. Un démenti est plus convaincant lorsqu’il s’accompagne d’éléments indépendamment vérifiables.

7. Appréciation de l’attribution

Les faits observés, les déductions, le niveau de confiance et les autres explications possibles doivent apparaître séparément. Les déclarations de GitHub, GreatFire, Baidu et des chercheurs ne doivent pas être fondues artificiellement dans une version unanime.

8. Divulgation et conservation

Les organisations doivent définir ce qui peut être rendu public, ce qui nécessite un accès restreint, combien de temps les éléments sont conservés et comment les données personnelles sont protégées. Toute nouvelle information importante doit compléter la chronologie sans réécrire silencieusement les incertitudes initiales.

Ce socle transforme la responsabilité en capacité de reproduction. Il permet à un hébergeur, un transitaire, un éditeur de ressources, un navigateur ou une autorité compétente de vérifier qu’une affirmation suit bien les observations disponibles.

Atténuer sans fabriquer de fausses équivalences

Les recommandations générales sur les DDoS traitent de l’épuisement des ressources, de l’amplification, de la robustesse des protocoles et de la coordination opérationnelle. [11] Elles expliquent pourquoi un service a besoin de limites, de capacité, de filtrage et de plans de continuité. Elles ne prouvent pas le vecteur exact de mars 2015.

Des requêtes provenant de navigateurs réels exigent une défense à plusieurs niveaux. La bordure peut répartir ou absorber une partie de la charge. La couche transport peut limiter certaines pressions de connexion. L’application peut repérer des chemins répétitifs ou coûteux. La mise en cache peut réduire le travail nécessaire pour produire une réponse sûre. Les opérateurs peuvent coordonner les annonces et les capacités d’atténuation.

Chaque choix entraîne un coût. Un filtrage agressif bloque des usagers légitimes. Une épreuve supplémentaire peut nuire à l’accessibilité ou à la vie privée. Une limite trop générale pénalise les réseaux partagés. Un déplacement du trafic peut saturer une autre destination. Le retrait du contenu ciblé peut récompenser l’usage de la pression sur la disponibilité. Une trace crédible doit exposer ces arbitrages au lieu d’annoncer simplement que « l’attaque a été atténuée ».

Les prestataires spécialisés détiennent eux aussi des informations décisives : comportement avant et après filtrage, critères de classification, modifications de route, charge de la capacité de nettoyage et faux positifs. Le contrat devrait garantir à la victime l’accès aux éléments nécessaires, leur intégrité temporelle et leur conservation. Externaliser l’atténuation n’externalise pas la responsabilité.

Il faut aussi séparer l’attribution de la réponse immédiate. GitHub devait maintenir son service avant de connaître avec certitude l’opérateur du système. Les mesures de défense pouvaient s’appuyer sur les destinations, la répétition, les coûts applicatifs et la santé du service. Leur efficacité ne prouvait pas l’identité de l’assaillant. Inversement, une hypothèse géopolitique forte ne dispensait pas de caractériser le trafic.

Les observations ultérieures restent des événements distincts

Des analyses publiées après 2015 ont évoqué de nouvelles utilisations d’outils qualifiés de Great Cannon. Une étude technique de NTT apporte un éclairage indépendant sur le dispositif et sur les défenses contre les DDoS. [10] Un rapport ultérieur d’AT&T Alien Labs décrit une réapparition de techniques associées à cette appellation. [18]

Ces éléments justifient un investissement durable dans la détection multi-réseaux, le transport authentifié et l’échange de preuves entre opérateurs. Ils ne démontrent pas que les observations postérieures partageaient exactement les mêmes infrastructures, cibles, responsables ou autorités de commandement que l’attaque de mars 2015.

Chaque événement doit conserver ses propres dates, destinations, comportements et niveaux de confiance. Une appellation commune peut signaler une ressemblance technique sans établir une continuité institutionnelle parfaite. Réunir toutes les occurrences dans un récit unique ferait disparaître les différences précisément nécessaires à une attribution responsable.

Des contrefactuels utiles, mais bornés

Demander ce qu’un contrôle aurait changé peut améliorer la résilience, à condition de ne pas prétendre connaître un passé qui n’a pas eu lieu.

Si toutes les ressources exécutables concernées avaient été servies par un canal correctement authentifié, la substitution directe sur le trajet aurait été beaucoup plus difficile. Cela ne prouve pas que l’attaquant aurait renoncé : il aurait pu bloquer les connexions, rechercher une extrémité vulnérable ou employer un autre vecteur.

Si les navigateurs avaient imposé des limites plus sévères aux requêtes répétées en arrière-plan, la charge produite aurait peut-être diminué. De telles limites auraient aussi risqué de perturber des applications normales et auraient pu être contournées par une variation des intervalles ou des destinations.

Si GitHub avait possédé davantage de capacité, il aurait peut-être mieux absorbé l’afflux. Aucun élément public ne permet de chiffrer la capacité supplémentaire requise. Surtout, une bordure plus large n’aurait pas corrigé l’altération distante de la ressource.

Si l’anti-usurpation avait été universel, de nombreuses attaques réfléchies auraient été plus difficiles. Les connexions des navigateurs décrites ici auraient néanmoins conservé des adresses plausibles.

Si les opérateurs avaient partagé plus rapidement des observations réalisées depuis plusieurs réseaux, l’injection aurait peut-être été localisée plus tôt. La mesure n’empêche pas à elle seule l’altération et doit rester proportionnée afin de protéger les utilisateurs.

Un contrefactuel sérieux nomme donc la propriété modifiée, les éléments qui permettraient de vérifier son effet et les voies d’attaque restantes. Il sert à concevoir des défenses, pas à distribuer rétrospectivement une faute simpliste.

Une norme de responsabilité pour l’injection sur le trajet

L’affaire GitHub permet de formuler une norme opérationnelle en huit points.

Premièrement, toute ressource exécutable devrait être authentifiée et inventoriée. Les dépendances tierces en clair créent une occasion de substitution qui ne peut pas être compensée uniquement par la capacité de la cible.

Deuxièmement, les services doivent être observés depuis plusieurs réseaux. Les journaux de l’origine ne montrent pas nécessairement ce qu’un client a reçu.

Troisièmement, le contrôle doit être cartographié par couche : publication de la ressource, DNS, routage, transit, exécution du navigateur, bordure de la cible, atténuation et communication de service.

Quatrièmement, chaque action importante doit être reliée à un propriétaire, un horaire, une justification, un effet attendu, un résultat mesuré et une condition de retour arrière.

Cinquièmement, le niveau de confiance de l’attribution doit rester visible. Une localisation technique convaincante et des ressemblances de code peuvent soutenir une évaluation probable sans établir une chaîne individuelle de commandement.

Sixièmement, l’atténuation doit protéger les utilisateurs involontairement enrôlés. Une adresse à l’origine d’une requête ne suffit pas à transformer son titulaire en attaquant volontaire.

Septièmement, la continuité doit être testée sans abandonner automatiquement la politique d’hébergement à celui qui impose le coût du trafic.

Huitièmement, les registres et contrats doivent être réconciliés avec la réalité du service. Ils indiquent ce qui devait se produire ; les mesures montrent ce qui s’est produit.

Questions à poser aux opérateurs et aux dirigeants

Quelles ressources tierces pouvaient exécuter du code dans les navigateurs, et étaient-elles toutes transmises par un canal authentifié ?
Quels éléments permettraient de distinguer une compromission de l’origine, une substitution sur le trajet, un problème local et le comportement normal de l’éditeur ?
Quels réseaux ont reçu des réponses divergentes, et lesquels ont obtenu les octets attendus ?
Les horaires, empreintes, résultats de validation, résolutions DNS et observations de route peuvent-ils être réunis dans une chronologie cohérente ?
Quel acteur pouvait modifier l’interface suspectée, et quelles traces vérifiables documentent ce contrôle ?
Comment GitHub pouvait-il classifier les requêtes sans supposer que chaque utilisateur à leur origine participait volontairement à l’attaque ?
Quels changements de filtrage, de capacité, de cache ou de route ont été appliqués, et quel effet mesuré a suivi chacun d’eux ?
Quels utilisateurs légitimes ou services sans rapport ont subi les conséquences de l’atténuation ?
Quels faits soutiennent l’évaluation d’un opérateur probable, quelles autres explications subsistent et quel niveau de confiance est justifié ?
Les déclarations de GreatFire, le constat de GitHub, le démenti de Baidu et les mesures indépendantes sont-ils restés distincts ?
Quels contrôles répondent à l’usurpation d’adresse, lesquels protègent l’intégrité du contenu et lesquels maintiennent la disponibilité ?
Un tiers qualifié pourrait-il reconstruire l’incident sans devoir se fier uniquement à l’autorité déclarée des organisations concernées ?

Conclusion

Le DDoS de 2015 contre GitHub fut un test de responsabilité des réseaux parce que le point de contrôle rapporté se trouvait entre une ressource web attendue et le code finalement exécuté par le navigateur. L’attaque a emprunté des clients ordinaires, de vraies adresses et des trajets partagés. Elle a révélé les limites d’une lecture fondée uniquement sur les noms de domaine, les adresses sources ou les inscriptions administratives.

La conclusion publique doit rester soigneusement bornée. GitHub a subi une attaque majeure interprétée comme une pression visant certains contenus. GreatFire a décrit une séquence antérieure et attribué l’opération aux autorités chinoises. Des chercheurs ont mesuré un système capable d’injecter sélectivement du contenu dans des réponses HTTP et ont formulé l’évaluation d’un opérateur étatique probable. Baidu a nié la compromission de ses produits. Le volume total, le coût, l’heure exacte de rétablissement et une éventuelle chaîne individuelle de commandement ne sont pas établis publiquement.

La responsabilité suit le contrôle concret. Les opérateurs du trajet doivent conserver des éléments vérifiables sur les systèmes capables d’altération. Les éditeurs et intégrateurs doivent maîtriser leurs dépendances exécutables. Les navigateurs doivent réduire les possibilités d’enrôlement silencieux. GitHub et ses partenaires d’atténuation doivent relier leurs décisions aux effets réellement constatés. Les chercheurs et autorités doivent distinguer observation, inférence et attribution.

La règle durable est exigeante : le réseau doit être jugé sur les contenus, trajets et comportements de service qu’il a effectivement produits. Les registres décrivent l’autorité prévue. Le code en fonctionnement révèle si cette autorité a tenu. Quand une attaque exploite l’écart entre les deux, rendre cet écart observable est le premier acte de responsabilité.

Le DDoS « Great Cannon » contre GitHub en 2015 a fait de l’injection sur le trajet un test de responsabilité des réseaux