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 in ihrer eigenen Infrastruktur gespeichert. Obwohl der größte 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 Commits für normale Personen kompliziert werden.

Hier werden echte Schritte gegen das Verteilen (oder Bereitstellen) von Code aus einem gefährdeten Repository beschrieben. Wir teilen Erfahrungen und einige Prüfungsinstrumente. Ein solcher Schutz beeinträchtigt normale Workflows in GitHub fast nicht.

Hier betrachten wir das Risiko, ein GitHub-Konto 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, gefährdet.

Das Wesentliche des Problems

GitHub ist ein großartiges Ökosystem mit vielen Erweiterungen oder „Anwendungen“, um bestimmte Workflows zu vereinfachen. Anwendungen erhalten vom Benutzer die Erlaubnis, Aktionen in seinem Namen auszuführen. Sie können Berechtigungen anfordern, einschließlich Ändern oder Hinzufügen zusätzlicher Konten. GitHub zeigt diese Anforderungen deutlich: Der Benutzer muss sie über die Weboberfläche genehmigen, aber nicht jeder kennt die Konsequenzen. Viele verstehen nicht, dass die Berechtigung zum Zugriff auf ein persönliches Repository im Namen des Benutzers denselben Zugriff auf jedes Repository auf GitHub 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, nachträglich ein böswilliges Commit zu bemerken. Weder GitHub noch Git können so konfiguriert werden, dass diese Art von böswilligem Festschreiben verhindert oder markiert wird. Nur externe Überwachung.

Implementierung

Die folgenden Empfehlungen stammen aus unserem Sicherheitssystem . Nur für diesen Artikel wurden bestimmte 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, IM) zur Verfügung (mit GitHub können Sie Kontaktinformationen aus Datenschutzgründen ausblenden).
  • Informieren Sie die Organisation oder den Administrator über mögliche Kompromisse in Ihrem Konto (z. B. über den Diebstahl eines Laptops).

Richtlinien für Repositories

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

Workflow-Empfehlungen

• Bereitstellungen, Releases und andere Ereignisse, die einer Prüfung würdig sind, sollten mit einem Tag versehen werden, das 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 ausgestellt werden.

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



Hier ist ein Prüfungsbeispiel. 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). 

Mit lokal zwischengespeicherten Daten können Sie jetzt 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 können, octo_org/react-starter nur octo_org/react-starter einen Schutz gegen erzwungenes Drücken auf den Produktionszweig. Das Ergebnis ist im CSV-Format, das einfach in eine Tabelle eingefügt werden kann.

Wie können Sie helfen?

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