Alerte : Les paquets Laravel Packagist apportent un accès à distance et de retour

Ces dernières semaines, des chercheurs en sécurité ont détecté une campagne qui utilise la propre infrastructure de l'écosystème PHP pour construire des logiciels malveillants dans les projets Laravel : plusieurs paquets publiés dans Packagist ont été utilisés comme utilitaires légitimes et ont effectivement activé un accès à distance persistant aux machines touchées. L'équipe qui a signalé la découverte a publié une analyse détaillée que vous pouvez consulter sur leur blog ( Socket) et les pages des paquets sont toujours accessibles dans le registre public ( profil de l'auteur en Packagist et des colis individuels comme nhattuanbl / Lara-helper, nhattuanbl / simple file et nhattuanbl / lara-swagger).

La tactique n'était pas banale : certains paquets ne contenaient pas de code malveillant directement, mais introduisaient une dépendance qui le faisait. En particulier, un des paquets agit comme un pont et provoque l'installation d'une autre librairie en tant qu'unité de Compositeur - le gestionnaire d'unité standard en PHP - avec tout ce qu'il implique ( Documentation du compositeur). Cette deuxième librairie comprend un fichier PHP affusé qui, une fois chargé par l'application, établit la communication avec un serveur de contrôle et de contrôle (C2) et ouvre une porte arrière.

Les analystes décrivent que le code malveillant est conçu pour rendre l'analyse difficile : l'auteur a utilisé des techniques de sortie de flux de contrôle, des noms de fonctions et des variables aléatoires, ainsi que des itinéraires de codage et des domaines. Lorsque la charge utile est exécutée, elle recueille des informations du système et maintient une connexion au C2 en utilisant les sockets TCP en utilisant les propres fonctions de PHP (par exemple, flux _ socket _ client ()), en attendant des commandes qui peuvent inclure l'exécution de commandes, le transfert de fichiers, des captures d'écran et PowerShell fonctionnant sur les systèmes Windows.

Le risque va au-delà d'un script simple qui fonctionne : par la façon dont le code est activé - lorsque vous démarrez l'application Laravel par l'intermédiaire d'un fournisseur de services ou en chargeant automatiquement - malware fonctionne dans le même processus que l'application Web. Cela signifie qu'il hérite des permissions et variables d'environnement de l'application, et peut donc accéder aux identifiants stockés dans .env, clés de base de données, API et autres secrets que le projet a disponibles.

L'échantillon examiné a essayé de se reconnecter continuellement s'il n'a pas trouvé de réponse du serveur C2, ce qui le rend persistant et capable de rétablir la communication dès que l'attaquant a réactivé son infrastructure. Bien qu'au moment du rapport le serveur de commande était hors de ligne, la présence du code dans les systèmes de production représente une menace réelle et durable si elle n'est pas appliquée.

Si votre projet utilise des paquets tiers, et en particulier si vous dépendez de paquets d'auteurs peu connus, vous devez prendre une position défensive. Tout d'abord, vous devez rapidement identifier si l'un des paquets mentionnés sont présents dans l'arbre de dépendance en examinant compositeur. Json et compositeur. verrouiller et scanner le dossier de vente pour les fichiers suspects tels que les aides opussées. Si le code compromis apparaît, la chose sage est d'éliminer la dépendance affectée, mais ce n'est que le début.

Supposons qu'il y ait un engagement : tout système qui a chargé le code malveillant doit être considéré comme potentiellement contrôlé. Il est nécessaire de faire pivoter toutes les références qui ont pu être accessibles de l'application (bases de données, clés de service, jetons tiers), à la vérification des sorties réseau à la recherche de connexions à des domaines ou PI inhabituels et à l'examen des journaux pour détecter l'activité à distance. Il est également approprié de vérifier l'intégrité et les permissions des fichiers sensibles et, en cas de doute, de restaurer de sauvegarde fiable et de nettoyer l'environnement avant de les reproduire.

Cet incident s'inscrit dans le modèle plus large d'attaques sur la chaîne d'approvisionnement du logiciel: les acteurs malveillants publient des paquets avec apparence légitime pour les développeurs à installer sans soupçon. Les organisations et les développeurs peuvent réduire le risque en prenant des pratiques telles que l'examen attentif de l'origine des dépendances, la mise en place du compositeur. verrouiller les versions, en étudiant de nouveaux paquets avant l'inclusion et en utilisant des outils de numérisation automatisés qui détectent les comportements suspects. Les projets d'experts et les guides de sécurité sur la chaîne d'approvisionnement offrent des recommandations pratiques à suivre, par exemple, la communauté OWASP maintient des ressources en matière de sécurité dans la chaîne d'approvisionnement des logiciels ( OWASP Chaîne d'approvisionnement).

Pour les administrateurs et développeurs PHP, il est également utile de connaître les paramètres PHP qui limitent les vecteurs d'attaque, comme la directivedésactiver les fonctions _dans php.ini, bien que le malware détecté tente de contourner ces protections en testant plusieurs méthodes pour exécuter des commandes. La page officielle PHP documente ces fonctions et d'autres ( désactiver les fonctions _ dans la documentation PHP).

La leçon est claire : le confort d'installer un utilitaire à partir du disque ne peut remplacer une diligence minimale. Revoir la réputation de l'auteur, vérifier le contenu du paquet avant de l'installer dans des environnements productifs et maintenir des politiques de rotation secrètes sont des mesures qui ne sont plus facultatives. Si vous pensez avoir utilisé l'un des paquets en cause, agissez rapidement, documentez les actions et, au besoin, demandez l'aide d'un professionnel pour répondre aux incidents.

Si vous souhaitez approfondir le rapport technique, la rupture de campagne et des recommandations spécifiques sont disponibles dans l'analyse des chercheurs ( Socket) et les entrées de paquets peuvent être revues publiquement dans Packagist ( profil de l'auteur et les pages de chaque paquet). Afin de mieux comprendre les implications de la chaîne d'approvisionnement et des pratiques de défense, veuillez également consulter les ressources et guides communautaires tels que: OWASP et la documentation officielle du compositeur ( Compositeur).