Eine kürzlich entdeckte Schwachstelle auf GitHub könnte Sicherheitsberichte offenlegen und Angreifern die Möglichkeit geben, Codefehler auszunutzen, bevor Benutzer Zeit haben, Patches anzuwenden.
Justin Cappos, Professor am Department of Computer Science and Engineering der New York University, entdeckte die Sicherheitslücke, indem er einen Patch auf das Repository eines anderen Kontos anwendete. Er erklärt, dass er bemerkt habe, dass seine Sicherheitsberichte an den Kontoinhaber weitergegeben worden seien … Justin Cappos entdeckte die Schwachstelle am 13. März und meldete sie am 20. März über sein Bug-Bounty-Programm mit HackerOne an GitHub, seitdem wurde jedoch kein CVE zugewiesen.
Justin Cappos teilte uns mit, dass es sich bei dem Angriffsvektor um .github-Repositorys handelt, die security.md-Dateien enthalten, in denen Benutzer Anweisungen zum Melden einer in ihren Repositorys entdeckten Schwachstelle speichern. Security.md-Dateien sollten daher öffentlich sein. Die Sicherheitslücke wird ausgelöst, wenn Ein Benutzer versucht, einen Fix für ein Problem zu implementieren, das er in einem anderen Repository entdeckt hat.
Der Zugriff auf die Datei „Security.md“ könne Sicherheitslücken im .github-Repository eines anderen Benutzers aufdecken, sagte Cappos, Bedrohungsakteure müssten die Probleme jedoch dennoch ausnutzen, um Angriffe zu starten. Das Risiko ist daher in der zweiten Absicht real.
„Was passiert, ist, dass die Datei security.md einen Link dazu enthält, wo die Schwachstellen gemeldet werden, sodass die für meine Software gemeldeten Schwachstellen an den Angreifer weitergegeben werden“, erklärte er. „Eine kompetente Person könnte so erkennen, dass jeder, der meine Reporting-Software nutzt, Gefahr läuft, aufgrund eines Fehlers mehr Leute zu informieren.“ Wenn sie mir Von einem Problem erzählen, gehen diese Informationen an den Hacker. Letzterer kann dann alle meine Benutzer kompromittieren, wenn er weiß, wie er das gemeldete Problem schnell ausnutzen kann.“
Tatsächlich werden GitHub-Benutzer, wenn sie einen Fehler entdecken, aufgefordert, das Repository zu forken, das das Problem enthält, und dieses Repository erhält dann die Bezeichnung .github. Anschließend senden sie eine Pull-Anfrage an das neue .github-Repository, um den Benutzer über den Fix zu informieren. Wenn das gespaltene .github-Repository security.md-Dateien enthält, werden für alle Projekte des Benutzers, die kein .github-Repository haben, ihre Sicherheitslückenberichte an den Melder gesendet.
Die Schwachstelle kann unabhängig davon ausgelöst werden, ob Benutzer den Pull-Request zusammenführen oder nicht, warnt Justin Cappos. Er forderte GitHub auf, den Angriff schwieriger zu starten.
„Wenn Sie die .github-Datei einer anderen Person teilen, wird alles, was diese Person für die Sicherheitsberichterstattung gesagt hat, automatisch auf alle Ihre Repositories angewendet. Hierzu gibt es keine Warnung. Es gibt keine Benachrichtigung“, warnt Justin Cappos. „Grundsätzlich stellen Sie als Benutzer, der nur versucht, etwas Gutes zu tun, beispielsweise einen Tippfehler oder einen Fehler zu beheben, plötzlich fest, dass Sie alle Ihre Sicherheitsberichte an Dritte weitergeben, auch wenn dies in böser Absicht geschieht.“ »
Justin Cappos spricht viele heikle Punkte im Zusammenhang mit dieser Sicherheitslücke an. Security.md-Dateien in .github-Repositorys können eine Reihe vertraulicher Informationen enthalten. Wenn ein Benutzer das Repository eines anderen Benutzers übernimmt, um Änderungen vorzunehmen, wird die Datei security.md auf alle .github-Repositorys dieses Benutzers angewendet. Anschließend kann ein GitHub-Benutzer die Datei nach der Verzweigung nicht mehr ändern. Der Fork enthält den gesamten Inhalt der Dateien zu diesem Zeitpunkt.
Ein weiteres Problem: Der Fehler kann äußerst sichere Repositories in einer Weise beeinträchtigen, die Benutzer nicht erwarten. Justin Cappos betont jedoch, dass die Angriffe nur legitime Benutzer betreffen würden, die Fehler in Code oder Projekten korrigieren möchten, die auf GitHub geteilt werden.
Justin Cappos erklärt, dass er bisher keine Beweise dafür gesehen habe, dass es zu solchen Angriffen gekommen sei. Aber es analysierte GitHub-Repositories und stellte fest, dass Tausende von Benutzern versehentlich ihre security.md-Dateien geleakt hatten. Es wird darauf hingewiesen, dass die Sicherheitsinformationen einiger beliebter Projekte geändert wurden, ohne zu wissen, ob diese Änderungen absichtlich, versehentlich oder böswillig erfolgten. Er fügt hinzu, dass die meisten betroffenen Repositories nicht als kritisch gelten.
Laut Justin Cappos ist der Fehler leicht auszunutzen, die gezielte Ausrichtung bereitet jedoch Schwierigkeiten. Bedrohungsakteure könnten jedoch Benutzer anlocken, indem sie absichtlich Fehler in ihren Code einbauen, es gibt jedoch keine Garantie dafür, dass sie reagieren.
Während des Prozesses zur Offenlegung der Sicherheitslücke bei HackerOne am 20. März wurde Justin Cappos bestätigt, dass sie über eine Dokumentation des Problems verfügen. GitHub nimmt den Fehler ernst, scheint aber gleichzeitig nicht sicher zu sein, dass es sich um eine echte Schwachstelle handelt, die einen Patch erfordert.
„Ich stimme der Einschätzung von GitHub einigermaßen zu, dass dies nicht besonders schwerwiegend ist. Obwohl Ihr Issue-Tracker es als kritisch (höchste Kategorie) eingestuft hat – vor allem, weil Sie Zugriff auf sehr sensible Informationen haben und diese sich auf eine Vielzahl von Repositories auswirkt –, ist die Tatsache, dass jemand in erster Linie ein barmherziger Samariter sein muss, und Ihre Verzweigung „Das Senden einer Pull-Anfrage an das Repository macht es schwieriger, den Angriff auf einen bestimmten Teil zu zielen“, gibt Justin Cappos zu. „Für einen Angreifer, der einfach nur Projekte im Allgemeinen kompromittieren möchte, ist dies jedoch ein ernstes Problem.“
Bisher wurde dieser Schwachstelle kein CVE oder Patch zugewiesen und Justin Cappos fordert Benutzer dringend auf, sich zu schützen, indem sie ein leeres .github-Repository erstellen.
„Wenn Sie Ihr eigenes .github-Repository erstellt haben, hat dies keine Auswirkungen auf Sie, da Sie Ihr eigenes nicht überschreiben können, wenn Sie das eines anderen Repositorys forken. Aber wenn man keine erstellt hat, was die meisten Leute nicht tun, weil sie nicht sehr beliebt sind, dann ist man verwundbar“, erklärt er.
Von der Redaktion von TechTarget (Muttergesellschaft von MagIT) kontaktiert, verpflichtet sich GitHub, die gemeldeten Sicherheitsprobleme zu untersuchen und erklärt: „Wir haben diesen im Rahmen des GitHub-Bug-Bounty-Programms eingereichten Bericht zur Kenntnis genommen und ihn als gering sicherheitsrelevant eingestuft.“ Risiko und geringe Wahrscheinlichkeit einer Ausbeutung. Wir investieren weiterhin in die Verbesserung der Sicherheit von GitHub und unseren Produkten und suchen nach Möglichkeiten, dieses Verhalten beim Bearbeiten von Sicherheitsrichtliniendateien deutlicher zu machen. »
Dennoch haben die jüngsten Angriffe auf GitHub-Benutzer die Beliebtheit der Entwicklungsplattform für Bedrohungsakteure sowie die Risiken für die Lieferkette von Open-Source-Software deutlich gemacht. Anfang des Monats entdeckte Checkmarx, dass Angreifer GitHub-Freigaben und die Stargazing-Funktion manipulierten, um Entwickler zum Hochladen von Schadcode zu verleiten. Checkmarx enthüllte im März eine weitere Angriffskampagne, bei der Angreifer mehrere beliebte GitHub-Code-Repositories vergifteten, darunter Top.gg, das für die Suche und Entdeckung auf der Discord-Plattform verwendet wird.
