Alarm: Laravel Packagist Pakete bringen Backdoor und Fernzugriff

In den letzten Wochen haben Sicherheitsforscher eine Kampagne entdeckt, die die eigene Infrastruktur des PHP-Ökosystems nutzt, um Malware in Laravel-Projekten zu bauen: mehrere Pakete, die in Packagist veröffentlicht wurden, wurden als legitime Dienstprogramme verwendet und tatsächlich aktivierten persistenten Fernzugriff auf die betroffenen Maschinen. Das Team, das die Auffindung berichtete, veröffentlichte eine detaillierte Analyse, die Sie auf ihrem Blog konsultieren können ( Sockel), und die Seiten der Pakete sind noch im öffentlichen Register zugänglich ( Autorenprofil in Packagist und individuelle Pakete wie nhattuanbl / lara-helper, nhattuanbl / einfach-queue und nhattuanbl / lara-swagger)

Die Taktik war nicht trivial: einige der Pakete enthielten nicht böswilligen Code direkt, sondern stellte eine Abhängigkeit, die tat. Insbesondere eine der Pakete fungiert als Brücke und bewirkt, dass eine weitere Buchhandlung als Einheit von Composer - der Standard-Einheitsmanager in PHP - installiert wird, mit allem, was sie mit sich bringt ( Composer Dokumentation) Diese zweite Buchhandlung enthält eine affuscierte PHP-Datei, die nach der Anwendung eine Kommunikation mit einem Steuer- und Steuerserver (C2) herstellt und eine Hintertür öffnet.

Analysten beschreiben, dass der böswillige Code entworfen ist, um die Analyse schwierig zu machen: der Autor benutzte Steuerungsablauf-Techniken, Funktionsnamen und zufällige Variablen, sowie Kodierung Routen und Domänen. Wenn die Nutzlast ausgeführt wird, sammelt sie Informationen aus dem System und hält eine Verbindung mit der C2 über TCP-Sockets mit PHP-Eigenfunktionen (z. Strom _ Steckdose _ Client ()), warten auf Befehle, die Befehlsausführung, Dateiübertragung, Screenshots und PowerShell unter Windows-Systemen enthalten können.

Das Risiko geht über ein einfaches Skript hinaus, das läuft: wie der Code aktiviert wird - wenn Sie die Laravel-Anwendung durch einen Dienstleister oder durch Autoload starten - Malware läuft innerhalb des gleichen Prozesses wie die Web-Anwendung. Dies bedeutet, dass es die Berechtigungen und Umgebungsvariablen der Anwendung erbt und somit Zugriff auf in .env gespeicherte Anmeldeinformationen, Datenbankschlüssel, APIs und andere Geheimnisse, die das Projekt zur Verfügung hat.

Die untersuchte Probe versuchte, kontinuierlich wieder zu verbinden, wenn sie keine Antwort vom C2-Server fand, was sie persistent macht und in der Lage ist, die Kommunikation wieder herzustellen, sobald der Angreifer seine Infrastruktur wieder aktiviert hat. Obwohl zum Zeitpunkt des Berichts der Befehlsserver außer Betrieb war, stellt die Anwesenheit des Codes in Produktionssystemen eine echte und dauerhafte Bedrohung dar, wenn er nicht agiert wird.

Wenn Ihr Projekt Pakete von Drittanbietern verwendet, und insbesondere wenn Sie von wenig bekannten Autorenpaketen abhängen, müssen Sie eine defensive Haltung einnehmen. Zuerst müssen Sie schnell identifizieren, ob eine der genannten Pakete im Abhängigkeitsbaum vorhanden sind, indem Sie den Komponisten überprüfen. json und Komponist. sperren und scannen Sie den Verkaufsordner für verdächtige Dateien wie opussed helpers. Wenn Kompromisscode erscheint, ist es klug, die betroffene Abhängigkeit zu beseitigen, aber das ist nur der Anfang.

Angenommen, es gab Verpflichtung: jedes System, das den schädlichen Code geladen hat, sollte als potenziell kontrolliert betrachtet werden. Es ist notwendig, alle Anmeldeinformationen zu drehen, die von der Anwendung (Datenbanken, Serviceschlüssel, Drittanbieter-Tokens) zugänglich sind, Netzwerkausgänge auf der Suche nach Verbindungen zu ungewöhnlichen Domains oder PIs zu prüfen und Protokolle zu überprüfen, um Remote-Aktivität zu erkennen. Es ist auch angebracht, Integrität und Berechtigungen von sensiblen Dateien zu überprüfen und, falls es Zweifel gibt, Wiederherstellen von zuverlässiger Sicherung und reinigen Sie die Umgebung, bevor sie wieder produziert.

Dieser Vorfall passt in das breitere Muster der Angriffe auf die Software-Versorgungskette: bösartige Schauspieler veröffentlichen Pakete mit legitimem Aussehen für Entwickler, ohne Verdacht zu installieren. Organisationen und Entwickler können das Risiko reduzieren, indem Praktiken wie sorgfältige Überprüfung der Herkunft der Abhängigkeiten, setzen Komponist. schloss Versionen, audiating neue Pakete vor der Aufnahme und mit automatisierten Scan-Tools, die verdächtige Verhaltensweisen erkennen. Experten-Projekte und Sicherheitsführer auf der Lieferkette bieten praktische Empfehlungen, die verfolgt werden sollen, z.B. hält die OWASP-Community Sicherheitsressourcen in der Software-Versorgungskette ( OWASP Lieferkette)

Für PHP-Administratoren und -Entwickler ist es auch nützlich, PHP-Einstellungen zu kennen, die Angriffsvektoren begrenzen, wie die RichtlinieDeaktivieren _ Funktionenin php.ini, obwohl die Malware erkannt versucht, diese Schutzmaßnahmen zu umgehen, indem mehrere Methoden getestet, um Befehle auszuführen. Die offizielle PHP-Seite dokumentiert diese und andere relevante Funktionen ( disable _ Funktionen in PHP-Dokumentation)

Die Lektion ist klar: Der Komfort der Installation eines Dienstprogramms aus dem Datensatz kann keine minimale Sorgfalt ersetzen. Um den Ruf des Autors zu überprüfen, den Inhalt des Pakets zu überprüfen, bevor es in produktiven Umgebungen installiert wird und geheime Rotationspolitiken zu erhalten, sind Maßnahmen, die nicht mehr optional sind. Wenn Sie glauben, dass Sie irgendwelche der Pakete verwendet haben, handeln Sie schnell, dokumentieren Sie die Aktionen und, falls erforderlich, suchen Sie professionelle Hilfe bei der Reaktion auf Vorfälle.

Bei der Analyse von Forschern ( Sockel), und Paketeinträge können in Packagist ( Profil des Autors und die Seiten jedes Pakets). Um die Auswirkungen der Lieferkette und der Verteidigungspraktiken besser zu verstehen, konsultieren Sie bitte auch die Gemeinschaftsmittel und -führer wie OWASP und die offizielle Dokumentation von Composer ( Composer)