Schützen von GitHub-Repositorys vor böswilligen Commits

Ursprünglicher Autor: Hal Wine
  • Übersetzung
Mozilla versucht, seine Repositorys auf GitHub vor böswilligen Änderungen zu schützen. Wie der jüngste Gentoo-Vorfall gezeigt hat , sind solche Angriffe real.


Mozilla verwendete GitHub ursprünglich als Backup-Hosting. Wie bei Gentoo wurden die ursprünglichen Repositorys auf einer eigenen Infrastruktur gespeichert. Obwohl der Großteil des Firefox-Codes immer noch mit einer eigenen Infrastruktur verteilt wird, existieren viele Projekte nur auf GitHub. Einige sind nur Experimente, während andere in der Produktion verwendet werden (z . B. Firefox-Konten ). Solche "sensiblen" Repositorys müssen vor böswilligen Änderungen geschützt werden, ohne dass dies die Commits für normale Personen erschwert.

Die tatsächlichen Schritte zum Verteilen (oder Bereitstellen) von Code aus einem gefährdeten Repository werden hier beschrieben. Wir teilen Erfahrungen und einige Prüfungsinstrumente. Ein solcher Schutz beeinträchtigt die normalen Arbeitsabläufe in GitHub kaum.

Hier betrachten wir das Risiko, einen GitHub-Account durch die einzigartigen Mechanismen dieser Site zu hacken. Wie der Gentoo-Fall und andere Vorfälle gezeigt haben, ist im Falle eines Hacks der gesamte Code, auf den der Benutzer Zugriff hat, kompromittiert.

Das Wesen des Problems


GitHub ist ein großartiges Ökosystem mit vielen Erweiterungen oder „Anwendungen“, um bestimmte Workflows zu vereinfachen. Anwendungen erhalten vom Benutzer die Berechtigung, Aktionen in seinem Namen auszuführen. Sie können Berechtigungen anfordern, einschließlich des Änderns oder Hinzufügens zusätzlicher Konten. GitHub zeigt diese Anforderungen explizit an: Der Benutzer muss sie über die Weboberfläche genehmigen, aber nicht jeder kennt die Konsequenzen. Viele Leute verstehen nicht, dass die Berechtigung zum Zugriff auf ein persönliches Repository den gleichen Zugriff auf ein beliebiges Repository in GitHub im Namen des Benutzers gewährt.

Übermäßige Berechtigungen gefährden Repositorys mit vertraulichen Informationen, während der Administrator des Repositorys nichts sieht. Das Beste, was er tun kann, ist, eine böswillige Tat nachträglich zu bemerken. Weder GitHub noch Git können so konfiguriert werden, dass diese Art von böswilligem Commit verhindert oder markiert wird. Nur externe Überwachung.

Implementierung


Die folgenden Empfehlungen stammen aus unserem Sicherheitssystem , nur für diesen Artikel wurden die spezifischen Funktionen von Mozilla entfernt. Wir leihen uns so viel wie möglich die Best Practices des Internets aus, nutzen die Funktionen von GitHub und versuchen, das Leben der Entwickler nicht zu sehr zu verkomplizieren.

Empfehlungen für Organisationen


  • Obligatorische 2FA für alle Mitarbeiter.
  • An alle oder zumindest Benutzer mit höheren Berechtigungen:
    • Stellen Sie der Organisation oder dem Administrator Kontakt (E-Mail, Sofortnachrichten) zur Verfügung (GitHub ermöglicht Ihnen, Kontaktinformationen aus Datenschutzgründen auszublenden).
    • Informieren Sie die Organisation oder den Administrator unbedingt über die mögliche Gefährdung Ihres Kontos (z. B. über den Diebstahl eines Laptops).

Richtlinien für Repositorys


  • Wichtige Repositorys sollten nur in einer Organisation gehostet werden, die den obigen Empfehlungen entspricht.
  • Produktionszweige definieren und konfigurieren:
    • Ban zwangsweise schieben.
    • Erlaubnis, nur eine kleine Anzahl von Benutzern zu verpflichten.
    • Wenden Sie diese Einschränkungen auch für Administratoren und Eigentümer an.
    • Unterschreiben Sie alle Commits mit zuvor bekannten GPG-Schlüsseln.

Workflow-Empfehlungen


  • Bereitstellungen, Releases und andere Ereignisse, die einer Prüfung wert sind, sollten mit einem Tag versehen werden, der mit einem zuvor bekannten GPG-Schlüssel signiert ist.
  • Alle Bereitstellungen und Releases sollten erst nach einer Überprüfung aller signierten Commits und Tags auf die richtigen Schlüssel ausgegeben werden.

Die Umsetzung dieser Schutzmaßnahmen ist insbesondere im Zusammenhang mit der Unterzeichnung von Commits mit gewissen Kosten verbunden. Wir haben Tools für die Prüfung von Konfigurationen entwickelt und planen, Tools für die Prüfung von Commits freizugeben. Alle von ihnen sind in unserem Repository .



Hier ist ein Beispiel für ein Audit. Zuerst erhalten wir eine lokale Kopie der Daten für die Organisation octo_org, und dann wird für jedes Repository ein Bericht erstellt:

$ ./get_branch_protections.py octo_org
2018-07-06 13:52:40,584 INFO: Running as ms_octo_cat
2018-07-06 13:52:40,854 INFO: Gathering branch protection data. (calls remaining 4992).
2018-07-06 13:52:41,117 INFO: Starting on org octo_org. (calls remaining 4992).
2018-07-06 13:52:59,116 INFO: Finished gathering branch protection data (calls remaining 4947).

Jetzt können Sie mit lokal zwischengespeicherten Daten beliebige Berichte erstellen. Ein Bericht zeigt beispielsweise die Einhaltung der oben genannten Empfehlungen:

$ ./report_branch_status.py --header octo_org.db.json
name,protected,restricted,enforcement,signed,team_used
octo_org/react-starter,True,False,False,False,False
octo_org/node-starter,False,False,False,False,False

Wie Sie sehen, haben wir gerade octo_org/react-starterden Schutz gegen erzwungenes Drücken auf den Produktionszweig aktiviert. Das Ergebnis ist im CSV-Format zum einfachen Einfügen in eine Tabelle.

Wie können Sie helfen?


Wir setzen diese Empfehlungen immer noch um und lernen dabei. Wenn Sie der Meinung sind, dass unsere Sicherheitsempfehlungen für das Repository die richtige für Sie sind, vereinfachen Sie die Implementierung. Teilen Sie Ihre Erfahrungen auf der Tippseite mit oder öffnen Sie ein Ticket im GitHub-Audit- Repository .

Jetzt auch beliebt: