Attaque massive contre la chaîne d'approvisionnement Laravel Lang

Les chercheurs en sécurité ont identifié une campagne d'engagement dans la chaîne d'approvisionnement logicielle qui a profité des versions malveillantes de plusieurs paquets PHP du projet Laravel-Lang pour introduire un puissant cadre de vol d'identité. Les agresseurs ont publié des centaines d'étiquettes en très peu de temps, suggérant qu'il ne s'agissait pas d'une seule version engagée, mais d'une violation du processus de publication de l'organisation : la réutilisation des identifiants d'automatisation ou le contrôle de l'infrastructure de libération permet de repeupler massivement plusieurs dépôts avec des changements malveillants.

Le composant malveillant principal a été caché dans un fichier appelé src / helpers.php, enregistré en compositeur. Json faible autoload.files, donc il fonctionne automatiquement sur chaque requête PHP du projet infecté. De là, la machine est truquée et un serveur externe est contacté pour télécharger une charge utile multiplateforme: sur Windows la chaîne de livraison tire un lanceur dans VBScript exécuté par cscript, et sur Linux / macOS est lancé par exec () appels. Les rapports décrivent un voleur modulaire en PHP - avec des collections spécialisées pour différents types de secrets - qui chiffre les résultats avec AES-256 et exfiltra, éliminant les traces locales après exécution.

La portée technique de l'exfiltré est extraordinaire et explique pourquoi ce type d'intrusion est si dangereux : nous recherchons des identifiants et des jetons auprès des fournisseurs de cloud, des métadonnées d'instance, des identifiants CI / CD et pipelines, des jetons d'enregistrement et de déploiement, des configurations Kubernetes et Helm, des paires de clés SSH, des fichiers .env, des identifiants Git et des gestionnaires de mots de passe et des portefeuilles de cryptomoneda, ainsi que des cookies et des identifiants de navigateur. Avec cette information attaquants peuvent rapidement pivoter d'une application Web compromise à l'infrastructure cloud ou comptes de développeurs, en multipliant les dommages.

Les signaux techniques décrits - plus de 700 versions étiquetées en quelques secondes - indiquent un engagement de niveau organisation/automatisation plutôt qu'un acte isolé. Cela a des conséquences opérationnelles : tout projet qui dépend de ces paquets et qui met automatiquement à jour les dépendances, ou qui se déploie à partir d'environnements ayant accès à des secrets, peut avoir activé le voleur sans intervention humaine. De plus, l'exécution via autoload implique qu'une simple requête HTTP vers une application web déployée pourrait suffire pour déclencher le vol.

Pour les équipes qui maintiennent des projets et pour les gestionnaires qui dépendent de paquets tiers, des mesures urgentes doivent être prises immédiatement. Sur le plan opérationnel, il est essentiel de vérifier les dépôts concernés et les pipelines : d'examiner le journal de publication, de faire pivoter et de révoquer tout titre de compétence associé à l'organisation (jetons d'automatisation, clés CI / CD, justificatifs d'emballage), et de vérifier l'intégrité des images et des dispositifs déployés. Nous devons également vérifier le compositeur. écluse et l'arbre de vente dans les installations existantes, à la recherche de la présence de ces aides. php ou d'autres indicateurs d'engagement, et de réinstaller les dépendances d'origines connues et signées si possible.

Les développeurs et les fournisseurs de services devraient prioriser le confinement dans des environnements productifs : effectuer des analyses médico-légales sur des serveurs Web et construire des serveurs, rechercher des processus et des scripts anormaux (VBScript dans Windows, exec () exécutions inattendues dans Unix), surveiller les sorties réseau vers des domaines suspects et suspendre ou isoler des systèmes avec des preuves de performance. Au niveau des références, la rotation immédiate des clés du fournisseur de cloud, des jetons d'enregistrement et des secrets utilisés par les coureurs et les clés de déploiement est essentielle; dans la mesure du possible, remplacer les secrets permanents par des mécanismes d'identité fédérés (par exemple OIDC) et des politiques d'accès temporaire. Pour orienter les pratiques de défense plus larges, il convient de consulter les ressources sur le durcissement de l'organisation et la sécurité de la chaîne d'approvisionnement, comme la documentation GitHub pour les organisations ( https: / / docs.github.com / fr / organisations / garde-votre-organisation-sécurité / sécurisation-votre-organisation) et les recommandations du projet OWASP sur la sécurité de la chaîne d'approvisionnement des logiciels ( https: / / owasp.org / www-project-software-Supply-chain-security /).

Pour les détenteurs de paquets et les organisations qui publient des artefacts, l'incident rappelle la nécessité de protéger l'infrastructure de diffusion : activer la vérification en deux étapes pour les comptes d'équipement, limiter l'utilisation des jetons à portée minimale, vérifier et faire pivoter les coureurs et les clés d'IC, et mettre en place des contrôles d'approbation manuelle pour les publications de masse. La signature de paquets et l'adoption de mécanismes tels que sigstore / SLSA peuvent atténuer des risques similaires à l'avenir; dans l'intervalle, vérifier que les versions proviennent de processus reproductibles réduit la vulnérabilité aux changements dans la chaîne d'édition. La documentation du compositeur sur la charge automatique et son impact opérationnel est une référence utile pour comprendre comment un fichier inclus dans la charge automatique. les fichiers peuvent devenir un vecteur d'exécution ( https: / / getcomposer.org / doc / 04-schema.md # autoloadfiles).

Si vous maintenez une application qui utilise des paquets Laravel-Lang, agissez en priorité : définissez de bonnes versions connues au lieu d'accepter des mises à jour automatiques, inspectez la vente pour la présence d'assistants ou d'autres fichiers inhabituels, et redéployez à partir de sources propres après des secrets tournants. Si vous détectez des signes d'engagement, coordonnez l'intervention avec votre équipe de sécurité, conservez les dossiers aux fins d'analyse médico-légale et avisez les fournisseurs concernés afin qu'ils puissent révoquer les titres de compétence potentiellement exfiltrés. Il est également recommandé d'activer la détection des intrusions et les systèmes EDR avec des règles qui identifient les exécutions inhabituelles de cscript, les appels suspects () et les connexions sortantes aux domaines d'exfiltration.

Cet incident souligne que la sécurité du développement est non seulement une question de code, mais aussi de processus et de permis : l'automatisation qui accélère les livraisons expose également l'organisation si les jetons et pipelines ne sont pas gérés avec le principe de moins de privilège. Adopter des pratiques de protection de la chaîne d'approvisionnement, vérifier régulièrement l'accès et minimiser les secrets persistants dans les pipelines sont des étapes qui réduisent la probabilité qu'un seul compte engagé entraîne une campagne à plus grande échelle.

Enfin, si vous avez besoin d'informations techniques supplémentaires ou de modèles de réponse, consultez les guides de réponse incidente de votre fournisseur de cloud et les outils d'analyse d'unité tels que les scanners commerciaux et gratuits; et gardez un œil sur les avertissements officiels du projet concerné (par exemple le dépôt). Laravel-Lang / lang) et des équipes d'intervention qui publient les COI et les remèdes spécifiques.