Ihre Open-Source-Zugangsdaten sicher verwahren

Anfang dieses Monats veröffentlichte ein Forscher namens ChALkeR seine Forschung zu offengelegten Zugangsdaten in npm-Paketen. Die Ergebnisse zeigen, dass Zugangsdaten wie npm- und GitHub-Tokens sowie Passwörter häufig in veröffentlichten npm-Paketen oder GitHub-Repositories enthalten sind. Tatsächlich hängen 13 der 15 beliebtesten npm-Pakete von Paketen ab, in denen Zugangsdaten offengelegt wurden – und setzen damit ihre Nutzer einem Risiko aus.

Der Beitrag von ChALKeR ist lesenswert und die erste Analyse offengelegter Zugangsdaten speziell zu npm, die mir bekannt ist. Das Problem selbst ist jedoch nicht neu. Mit der GitHub-Suche ließen sich schon vor fast drei Jahren leicht private Schlüssel finden (und dabei wurden Berichten zufolge Schlüssel des Chrome-Teams offengelegt), und Google kann allerlei private Informationen zugänglich machen. Je leichter Code auffindbar wird, desto einfacher lassen sich solche Fehler entdecken – ein weiterer Grund, etwas dagegen zu unternehmen.

Laden Sie den Spickzettel von Snyk mit 10 bewährten npm-Sicherheitspraktiken herunter, damit Sie die richtigen Sicherheitsrichtlinien befolgen. Sie erfahren, wie Sie npm sicher nutzen – hilfreich für Node.js- und JavaScript-Entwickler.

Warum offengelegte Zugangsdaten ein Risiko sind

Wer Zugangsdaten offenlegt, macht Geheimnisse zugänglich, mit denen sich auf verschiedene Konten zugreifen lässt.

Am häufigsten werden Passwörter, API-Schlüssel und private SSH-Schlüssel offengelegt. Diese Schlüssel können einem automatisierten Tool – ob Ihrem eigenen oder dem eines Angreifers – bereits ausreichen, um Aktionen auszuführen, etwa eine neue Paketversion zu veröffentlichen oder Code zu löschen. Welche Aktionen mit einem Schlüssel möglich sind, hängt vom jeweiligen Schlüssel und System ab.

Wenn Sie Open-Source-Pakete verwenden, sollten Sie sich besonders vor Zugangsdaten hüten, mit denen sich neuer Code veröffentlichen lässt, etwa einem npm-Token oder einem GitHub-Deploy-Key. Ein Angreifer mit Zugriff darauf kann problemlos eine neue „Fehlerbehebung“-Version mit schädlichem Code veröffentlichen, die Sie oft unbemerkt installieren.

Wenn Sie Ihr Open-Source-Projekt irgendwo hosten, sollten Sie auch darauf achten, keine Informationen über Ihre Laufzeitsysteme preiszugeben. Das betrifft nicht nur npm: Sie könnten Ihre AWS-Schlüssel, privaten SSH-Schlüssel oder Passwörter für verschiedene Systeme offenlegen. Jeder dieser Schlüssel könnte Angreifern Zugriff auf Ihr System verschaffen – etwa um Ihr geistiges Eigentum und Nutzerdaten zu stehlen oder einfach Rechenleistung auf Ihre Kosten zu nutzen (und Ihnen die Rechnung zu überlassen).

Was sollte ich als Open-Source-Entwickler tun?

Neben dem Bewusstsein für die Risiken sollten Sie einige bewährte Praktiken in Ihre Abläufe integrieren und mehrere Schutzebenen einführen, um Fehler zu verhindern. Hier sind einige konkrete Vorschläge:

Vermeiden Sie pauschale git add *-Befehle

Mit Platzhaltern können leicht lokale Dateien erfasst werden, die gar nicht geteilt werden sollen. Das ist besonders wichtig, wenn Sie ganze Unterordner hinzufügen (z. B. git add dirname), denn dabei werden auch versteckte (dot-)Dateien erfasst.

Geben Sie statt Platzhaltern jede Datei, die Sie committen, einzeln an oder verwenden Sie git add -p, um jede hinzugefügte Änderung zu überprüfen.

Führen Sie vertrauliche Dateien in .gitignore und .npmignore auf

Sowohl git als auch npm unterstützen eine lokale Datei, in der Sie festlegen können, welche Dateien von Paketen und Commits ausgeschlossen werden. So können Sie verhindern, dass vertrauliche Dateien versehentlich aufgenommen werden. Wenn Sie keine Ausschlüsse festlegen, wird npm bestimmte Dateien trotzdem ignorieren, git hingegen nimmt alle auf. Unabhängig von den Standardeinstellungen kennt keines der Tools Ihre Anwendung so gut wie Sie. Daher sollten Sie diese Dateien am besten selbst bearbeiten.

Bei folgenden Beispieldateien ist Vorsicht geboten:

• CI-Konfigurationsdateien (z. B. .travis.yml, circle.yml)

• Dockerfile und docker-compose.yml

• Build-Ausgabedateien (z. B. gypi)

• Benutzerdefinierte Deploy-Skripte (z. B. alles unter /deploy/ oder /scripts/).

ChALKeR führt in seinem Beitrag einige weitere Beispiele auf. Weitere Anregungen finden Sie in den Beispieldateien für .gitignore von GitHub.

Beachten Sie, dass die umfangreicheren Standardausschlüsse von npm erst mit npm@2.14.1 eingeführt wurden. Aktualisieren Sie daher auf diese oder eine neuere Version.

Verschlüsseln Sie Schlüssel oder verwenden Sie Umgebungsvariablen für Veröffentlichungen aus der CI

Wenn Sie über Ihre CI auf npm veröffentlichen, muss die CI auf Ihr npm-Token zugreifen können. Dieses Token versehentlich in CI-Konfigurationsdateien aufzunehmen und offenzulegen, ist leicht passiert.

Verwenden Sie stattdessen nach Möglichkeit eine Umgebungsvariable für das Token. So bleibt es aus der Versionsverwaltung heraus und wird in der Ausgabe unkenntlich gemacht (zumindest bei Travis und Circle). Falls Sie aus irgendeinem Grund einen Schlüssel in Ihre Versionsverwaltung aufnehmen müssen (zum Beispiel, wenn Sie Inhalte zurück in GitHub committen möchten), sollten Sie ihn unbedingt verschlüsseln.

git-secrets: Git-Hook verhindert das Committen von Zugangsdaten

Michael Dowling von AWS Labs hat kürzlich ein nützliches Tool namens git-secrets veröffentlicht. Das Tool wird bei git commit ausgeführt und bricht den Commit ab, wenn dieser Muster enthält, die auf Zugangsdaten hindeuten. Das ist eine gute zusätzliche Schutzmaßnahme, die Inhalte prüft und den zuvor empfohlenen Schutz anhand von Dateinamen ergänzt.

Wichtig ist, dass Sie diese Informationen vor dem Commit (oder genauer: vor dem Push) erkennen müssen, so wie es dieses Tool tut. Bei Open-Source-Projekten kommt eine Prüfung in der CI oder im Pull-Request-Prozess zu spät – die Zugangsdaten wurden dann bereits offengelegt.

Offengelegte Zugangsdaten ungültig machen

Wenn Sie schließlich erfahren, dass Sie bereits einen Schlüssel oder ein Passwort offengelegt haben, sollten Sie diese Tokens umgehend ungültig machen.

Es reicht nicht, das Token aus dem neuesten Release oder Branch zu entfernen. Selbst wenn Sie historische Verweise löschen: Kopien Ihres Schlüssels bleiben im Umlauf, auch wenn Sie ihn inzwischen aus GitHub und npm entfernt haben – das Internet vergisst nie. Es empfiehlt sich außerdem, Ihre Systeme zu überprüfen und festzustellen, ob jemand den Schlüssel zwischenzeitlich genutzt hat, um schädlichen Code zu veröffentlichen oder auf Ihre Systeme zuzugreifen.

Was kann ich als Nutzer von Open Source tun?

Als Nutzer von Open-Source-Paketen können Sie nicht viel tun. Wenn Sie ein Paket verwenden, vertrauen Sie ihm ausdrücklich und zugleich implizit seinen Abhängigkeiten. Sicherheitsfehler in diesen Abhängigkeiten können Ihre eigenen Systeme gefährden – seien es offengelegte Zugangsdaten oder Sicherheitslücken (letztere können Sie mit Snyk beheben). ChALKeR zufolge wurden die von ihm entdeckten Zugangsdaten inzwischen von GitHub beziehungsweise npm ungültig gemacht. Ungültige Zugangsdaten stellen kein Sicherheitsrisiko mehr dar – vorausgesetzt, sie wurden bis dahin nicht missbraucht.

Wenn Sie dennoch aktiv werden möchten, können Sie Ihre eigenen Abhängigkeiten überprüfen und feststellen, ob sie Informationen preisgeben, die Ihrer Meinung nach vertraulich bleiben sollten. Mit etwas Bash-Know-how lassen sich relevante Punktdateien in Ihren Abhängigkeiten finden. Anschließend können Sie selbst entscheiden, ob sie private Informationen enthalten.

Mit diesem Bash-Befehl für Mac/Linux können Sie loslegen. Er findet einige dieser Dateien, entfernt Duplikate und gibt sie zusammen mit dem Dateinamen aus:

find . \( -name '*.gypi' -o -name '.npmrc' -o -name '.travis.yml' \) | xargs md5 -r | sort | awk '{print $2" "$1}' | uniq -f1 | sort | awk '{print "echo "$1";cat "$1}'

Zusammenfassung

Open Source zu entwickeln ist großartig, aber nicht alles ist zum Teilen gedacht. Offen gelegte Zugangsdaten gefährden Ihre Nutzer und dadurch auch deren Nutzer.

Trennen Sie Ihre Zugangsdaten vom Code und sensibilisieren Sie alle Beteiligten für dieses Risiko. Achten Sie bei Code-Reviews auf offengelegte Daten und nehmen Sie entsprechende Prüfungen in Ihre Standardabläufe auf. Ergänzen Sie Ihre Prozesse außerdem um die oben beschriebenen Schutzmaßnahmen, um menschliche Fehler abzufangen. Wenn Sie dennoch etwas offenlegen, reagieren Sie richtig: Machen Sie die Tokens ungültig, informieren Sie Ihre Nutzer und untersuchen Sie Ihren Code auf Spuren schädlicher Aktivitäten.