Drive-by downloads : infecté sans un seul clic

Pourquoi aucun clic n'est nécessaire

Le browser n'est pas un simple renderer de pages. C'est un runtime complet : chaque page chargée peut exécuter du JavaScript, envoyer des graphismes à ta GPU, décoder des flux vidéo, faire tourner des binaires WebAssembly en local. Tout ça démarre automatiquement dès que le HTML arrive dans le parser.

Un drive-by download s'engouffre précisément dans cette pipeline. Un bug dans le moteur JavaScript qui laisse un index de tableau déborder, une race condition dans une API Canvas, une frame vidéo malformée qui déclenche un débordement mémoire : autant de portes d'entrée. Le browser exécute le code d'exploit parce que c'est du contenu de page, pas parce que tu as validé quoi que ce soit.

La sandbox du browser bloque beaucoup de tentatives. Les vraiment dangereux, ce sont les exploits chaînés : un bug du moteur JavaScript donne un accès arbitraire à la mémoire, un second bug sort de la sandbox, un troisième élève les droits au niveau système. Ces chaînes coûtent cher aux attaquants, mais on les retrouve régulièrement dans des campagnes à grande échelle.

Où frappent les exploits modernes

JIT JavaScript. Les moteurs modernes comme V8 et SpiderMonkey compilent à la volée les fonctions chaudes en code machine. Un bug dans le compilateur JIT produit du code faux que le browser exécute avec tous les droits. La majorité des bugs de browser exploités ces dernières années sortent de cette couche.

WebGL et WebGPU. Les shaders filent sans filtre vers ta GPU. Les drivers graphiques traînent un long historique de bugs, et les exploits WebGL sont une voie éprouvée pour sortir de la sandbox.

Décodage des médias. Les codecs vidéo et audio traitent d'énormes espaces d'entrée en C ou C++. Une corruption mémoire dans un codec mène souvent droit à l'exécution de code. Le fameux exploit BLASTPASS de 2023 contre iMessage visait un parser d'image, mais la même classe de bugs existe dans le browser.

WebAssembly et Web Workers. Des threads parallèles avec leur propre modèle mémoire, c'est pratique, mais c'est aussi une surface de plus où des bugs mémoire se font exploiter.

Comment la page arrive sur ton écran

Les pages drive-by ne sortent pas de nulle part, elles sont distribuées. Les trois canaux dominants sont le malvertising, les watering hole attacks et les sites légitimes compromis.

Le malvertising, c'est le canal le moins cher. La page piégée vit dans l'iframe d'une bannière pub et atteint toute personne qui charge la page hôte. Pour aller plus loin, voir Malvertising: When the Ad Is the Attack. Les watering hole attacks sont plus ciblées : l'attaquant compromet un site qu'il sait fréquenté par sa cible (un média sectoriel, une doc développeur, un forum communautaire) et y plante l'exploit.

Troisième variante : les sites légitimes directement compromis. Un plugin WordPress piraté, un compte CDN volé, un build hook détourné, il en faut peu pour injecter des scripts dans un site de confiance. Côté visiteurs, rien ne permet de voir la différence.

La fenêtre entre patch et rollout

Chrome, Firefox et Safari patchent les failles critiques en quelques jours. Mais les updates n'arrivent chez toi que quand le browser les récupère et redémarre. Sur desktop, ça prend en général 24 heures, sur Android parfois des semaines, et sur des environnements enterprise managés jusqu'à un mois selon la fenêtre de rollout.

Les attaquants connaissent cette fenêtre par cœur. Ils attendent la disclosure, diffent le patch pour en sortir la vraie modification et montent un exploit en quelques heures. Pendant une période courte mais très lucrative, le public est sciemment vulnérable. Même dans un environnement bien géré, tu es exposé pendant ces heures-là.

Les updates automatiques aident, mais pas totalement. Un browser qui n'a pas redémarré depuis cinq jours tourne encore sur l'ancien build, même si le patch a été téléchargé il y a longtemps.

Contenir, pas éviter

Tu ne peux pas éviter les drive-by downloads de façon fiable tant que tu utilises le web. L'idée que les sites de confiance sont sûrs ne tient pas debout, parce que les régies pub, les attaques de supply chain et les zero-days touchent jusqu'aux plus fiables. L'effort se déplace de l'évitement vers le confinement.

Une session de browser isolée prend toujours l'exploit au sérieux, mais le fait tomber dans un environnement qui n'est pas ton système d'exploitation. Le payload atterrit dans un container jeté à la fin de ta session. Ton laptop reste propre. Combine ça à une cadence d'update rapide sur ton browser du quotidien et à l'idée que les liens inconnus n'ont rien à faire sur ta machine de prod, et ton risque réel chute nettement. Plus de contexte sur le cycle zero-day dans Zero-Day Exploits.