Aikido

Packagist wird jetzt durch Aikido Intel und andere Updates für das PHP-Registry geschützt

Verfasst von
Dania Durnas

Eine Open-Source-Registry zu betreiben bedeutet, ständig Brände zu löschen. Das Konto eines weiteren Betreuers wird gehackt, ein weiteres bösartiges Paket taucht auf. Die Entfernung hinkt immer einen Upload hinterher. Die Arbeit hört nie auf, und die meisten Registries, die von kleinen Teams mit geringen finanziellen Mitteln betrieben werden, sind oft zu überlastet, um viel mehr zu tun, als einfach nur Schritt zu halten. Doch in letzter Zeit beobachten wir zunehmend positive Veränderungen in der Open-Source-Welt: Ökosysteme nehmen strukturelle Änderungen vor, die bestimmte Arten von Angriffen von vornherein unwirksam machen.

Das kleine Team, das Packagist.org und Composer – die Registry und den Paketmanager hinter der PHP-Welt – betreut, hat gezielte, präventive Sicherheitsmaßnahmen ergriffen und bedeutende Verbesserungen vorgenommen. Aikido diese Bemühungen nach Kräften. Der Intel-FeedAikido ermöglicht die Malware-Blockierung bei Downloads über Composer. Er ist standardmäßig für alle Nutzer ab Composer 2.10 aktiviert. Dies ergänzt eine Reihe weiterer Änderungen, die Packagist vorgenommen hat und weiterhin vornimmt, wobei jede einzelne darauf abzielt, ganze Kategorien von Angriffen zu unterbinden, anstatt nur einzelne Pakete zu verfolgen. 

Wir beobachten derzeit diesen Trend zu Verbesserungen in den verschiedenen Paket-Registern und freuen uns, diese Initiativen unterstützen zu können. PHP-Entwickler können nun beruhigt sein, da sie wissen, dass es mehr Sicherheitsvorkehrungen gibt, die verhindern, dass sie versehentlich Malware installieren. 

Malware-Blockierung in Composer

Am einfachsten ist es, zu verhindern, dass Nutzer eine Paketversion installieren, von der bereits bekannt ist, dass sie schädlich ist. Dank Aikido weiß Composer nun, welche Versionen als bedenklich gekennzeichnet wurden, und installiert diese nicht. 

Wenn Aikido eine schädliche Paketversion Aikido , wird diese Kennzeichnung in die Paket-Metadaten aufgenommen, die Composer herunterlädt. Das Framework für Abhängigkeitsrichtlinien von Composer 2.10 entfernt die gekennzeichnete Version aus dem Auflösungspool, sodass sie von den Befehlen `composer update`, `composer require` und `composer create-project` nicht ausgewählt wird. Die wichtigste Überprüfung erfolgt bei `composer install`, da eine Version, die nach dem Erstellen Ihrer Lockdatei markiert wurde, bei der nächsten Installation fehlschlägt. Sollte ein Benutzer aus irgendeinem Grund dennoch ein blockiertes Paket herunterladen wollen, kann er dies manuell überschreiben.

Diese Integration funktioniert, weil sie:

  • Offenheit: Der Feed, Aikido an Packagist Aikido , unterliegt einer CC-BY-Lizenz, sodass der Schutz nicht an einen sechsstelligen Vertrag gebunden ist und die Tür für andere Datenanbieter offen bleibt, sich anzuschließen. Sicherheit, die sich nur finanzstarke Akteure leisten können, schützt uns nicht.
  • Standardmäßig aktiviert: Eine Schutzmaßnahme, für die sich die Nutzer erst aktiv anmelden müssen, schützt fast niemanden (da es schwierig ist, die Nutzer dazu zu bewegen, sich anzumelden). Die Sicherheit eines Ökosystems hängt von den Standardeinstellungen ab, und die Standardeinstellung in Version 2.10 erfordert keinerlei Aufwand seitens der Nutzer, damit diese davon profitieren können.
  • Schnell genug: Schädliche Versionen werden in der Regel innerhalb weniger Stunden entfernt, sodass ein Feed, der sie innerhalb von Minuten kennzeichnet, die Nutzer in der Zeitspanne zwischen Erkennung und Entfernung schützt. Da die Sperre nur funktioniert, wenn etwas erkannt wird, würde eine langsame Erkennung nicht viel helfen.
  • Automatisiert: Da das schädliche Paket blockiert wird, sobald Aikido es Aikido , entsteht keine zusätzliche Verzögerung durch das Warten darauf, dass jemand das Paket manuell auf die Blacklist setzt oder entfernt, sodass die Nutzer schneller geschützt sind.

Die Integration Aikido-Erkennung in jede Installation war nur eine der Verbesserungen, die Packagist kürzlich eingeführt hat.

Türen schließen, statt Löcher zu flicken

Als Nächstes: das Umtaggen. Das Veröffentlichen auf Packagist bedeutete schon immer das Pushen eines Git-Tags, und die Registry ruft das ab, worauf dieses Tag verweist. Dieses System ermöglichte es Angreifern, die ein vertrauenswürdiges Konto gekapert hatten, eine veröffentlichte Version neu zu taggen und sie auf bösartigen Code zu verweisen, sodass die Versionsnummer nun eine Art Payload enthält (wie wir beim jüngsten Angriff auf Laravel-Lang gesehen haben). Die Antwort von Packagist – die Unveränderlichkeit stabiler Versionen – bedeutet, dass eine veröffentlichte stabile Version nicht mehr umgeschrieben werden kann. Damit sind Re-Tagging-Angriffe insgesamt ein für alle Mal beendet. GitHub verfügt über eine entsprechende Funktion, hat diese jedoch als Opt-in-Option gestaltet. Packagist hat sie hingegen verbindlich vorgeschrieben.

Schließlich ist der Versuch, Nutzer dazu zu bewegen, ihre Software zu aktualisieren, ein mühsames Unterfangen. Eine standardmäßige Sperre hilft nur denjenigen, die eine aktuelle Composer-Version verwenden – und das tun viele nicht. Ein CI-Image oder ein KI-Agent läuft oft mit einer Version, die schon Jahre alt ist; daher kann Private Packagist für die Verbindung eine aktuelle Composer-Version voraussetzen. Außerdem weigert es sich, die Dateien einer als problematisch markierten Version an irgendeinen Client auszuliefern – egal, ob alt oder neu.

Packagist.org ist noch nicht fertig, und es stehen einige Sicherheitsverbesserungen an. Geplant ist die Einführung eines Mindestalters für Releases, wodurch Angriffe abgewehrt werden könnten, die auf ein kurzes Zeitfenster setzen, bevor sie entdeckt werden (in der Zwischenzeit können Sie mit Aikido Chain, das ebenfalls kostenlos ist, einen ähnlichen Schutz erhalten). Außerdem wird ein organisatorisches Eigentumsrecht eingeführt, das eine obligatorische MFA ermöglicht, sowie gestaffelte Releases, die npm kürzlich eingeführt hat.

Auf dem Weg zu sichereren Paketregistern

Dies ist nicht nur eine PHP-Geschichte. Wie bereits erwähnt, schlägt npm mit der stufenweisen Veröffentlichung denselben Weg ein, deaktiviert aber auch automatische Installationsskripte. PyPI hat die Zwei-Faktor-Authentifizierung (2FA) verbindlich vorgeschrieben und ein Quarantänesystem eingerichtet, während crates.io und RubyGems die vertrauenswürdige Veröffentlichung auf Basis eines gemeinsamen OpenSSF-Entwurfs eingeführt haben. Die Ökosysteme bewegen sich in die richtige Richtung. Wir wünschen uns, dass dies noch viel häufiger und schneller geschieht, und wir werden dies weiterhin unterstützen, wo immer wir können. 

Sind Sie PHP-Entwickler? Composer-Clients älter als Version 2.10 verfügen nicht über diese Funktion. Führen Sie daher noch heute ein Update durch, falls Sie dies noch nicht getan haben. Sie verwenden kein PHP? Aikido Chain ist ein Open-Source-Tool, das ebenfalls verhindert, dass neue oder schädliche Pakete auf Ihrem Gerät installiert werden, bevor sie tatsächlich installiert werden.

Unabhängig davon, auf welche Ökosysteme Sie angewiesen sind, können Sie sich ansehen, was Aikido im Internet aufgreift. Der Feed ist öffentlich und kostenlos unter intel.aikido.dev verfügbar.

Teilen:

https://www.aikido.dev/blog/composer-protected-aikido-packagist

Nachrichten abonnieren

4.7/5
Falschpositive Ergebnisse leid?

Probieren Sie Aikido, wie 100.000 andere.
Jetzt starten
Erhalten Sie eine personalisierte Führung

Von über 100.000 Teams vertraut

Jetzt buchen
Scannen Sie Ihre App nach IDORs und realen Angriffspfaden

Von über 100.000 Teams vertraut

Scan starten
Erfahren Sie, wie KI-Penetrationstests Ihre App testen

Von über 100.000 Teams vertraut

Testen starten

Sicherheit jetzt implementieren

Sichern Sie Ihren Code, Ihre Cloud und Ihre Laufzeit in einem zentralen System.
Finden und beheben Sie Schwachstellen schnell und automatisch.

Keine Kreditkarte erforderlich | Scan-Ergebnisse in 32 Sek.