Umgehung des Branch-Schutzes

Was ist Umgehung des Branch-Schutzes?

Die Umgehung des Branch-Schutzes ist ein Versagen von Governance und Prozesskontrolle: Fehlt dem Default-Branch eines Repositorys der Branch-Schutz, kann jeder mit Push-Rechten direkt darauf committen oder seine Historie per Force Push überschreiben — vorbei am Pull-Request-Review und an den Continuous-Integration-Checks, auf die sich das Team verlässt. Weil Merges auf den Default-Branch oft ein automatisches Deployment auslösen, kann ein einziger Push ungeprüften Code in die Produktion bringen. Das unterscheidet sich von einem Secrets-Leak oder einem Angriff mit gefälschter Autorschaft: Hier wird nichts aus dem Repository gestohlen und nichts auf Commit-Ebene gefälscht. Die Schwachstelle ist, dass der Branch schlicht alles annimmt, was auf ihn gepusht wird. Diese Übung zeigt Ihnen beide Seiten. Als Bob, ein Angreifer mit den per Phishing erbeuteten Zugangsdaten eines Contributors für Riftwells Repository, stellen Sie fest, dass der Branch main keinen Branch-Schutz hat — direkte Pushes und Force Pushes sind also beide erlaubt. Sie committen eine Änderung und schieben sie per Force Push auf main, schreiben damit die Historie um und überspringen Review wie CI; und weil Merges auf main automatisch ausgerollt werden, ist Ihr Code sofort live in der Produktion. Als Alice, DevOps-Lead bei Riftwell und verantwortlich für die Einstellungen des Repositorys, erhalten Sie einen Alarm über eine umgeschriebene Historie und stellen fest, dass von Ihnen geprüfte Commits verschwunden sind. Sie sehen, dass main einen Force Push von einem einzigen Konto ohne Review und ohne Status-Checks angenommen hat, und schließen die Lücke, indem Sie den Branch-Schutz für main aktivieren: Pull Request verpflichtend, Reviewer verpflichtend, erfolgreiche Status-Checks verpflichtend, Force Pushes blockiert und Administratoren einbezogen, damit kein privilegiertes Konto die Regel umgehen kann. Ein erneuter direkter Push oder Force Push auf main wird daraufhin abgelehnt, weil main ein geschützter Branch ist, und Sie reichen den Bericht ein. Zum Abschluss geht es darum, warum ein ungeschützter Default-Branch so gefährlich ist und warum der Branch-Schutz — angewandt auf alle — die Kontrolle ist, die Review und CI wiederherstellt.

Was Sie lernen in Umgehung des Branch-Schutzes

• Erkennen, was ein ungeschützter Default-Branch zulässt: direkte Pushes und Force Pushes, die die Historie umschreiben und Pull-Request-Review sowie CI-Status-Checks umgehen
• Nachvollziehen, wie ein einziges kompromittiertes Contributor-Konto ungeprüften Code direkt in die Produktion pushen kann, wenn Merges auf den Default-Branch automatisch ausgerollt werden
• Verstehen, warum ein Force Push auf einen gemeinsam genutzten Branch gefährlich ist: Er schreibt Historie um, die andere geprüft haben und auf der sie aufbauen, und kann Commits spurlos löschen
• Branch-Schutzregeln anwenden, die einen Pull Request, verpflichtende Reviewer und erfolgreiche Status-Checks verlangen und Force Pushes auf dem Default-Branch blockieren
• Die Option „Administratoren einbeziehen“ aktivieren, damit privilegierte Konten die Regel nicht umgehen können und die Kontrolle für alle durchsetzbar wird

Umgehung des Branch-Schutzes — Trainingsschritte

1. Ein gestohlener Contributor-Zugang

   Heute nimmt Bob Riftwell ins Visier, ein Unternehmen für Logistiksoftware. Er hat die Anmeldeinformationen eines Mitwirkenden für das Dispatch-API-Repository erbeutet und möchte, dass sein eigener Code in der Produktion ausgeführt wird, ohne dass eine einzige Person ihn zuerst überprüft. Er beginnt damit, das Repository zu öffnen, auf das das gestohlene Konto übertragen werden kann.

2. Nichts bewacht die Hauptsache

   Das Repository-Statusboard teilt Bob alles mit, was er braucht. Der Standard-Branch ist der Haupt-Branch, sein Branch-Schutz liest „Keine“ und jeder Push auf den Haupt-Branch wird direkt in der Produktion bereitgestellt. Da es keine Regeln für den Branch gibt, kann er direkt zu ihm vordringen und seine Geschichte mit Gewalt durchsetzen, und alles, was landet, wird von selbst in die Produktion überführt.

3. Klonen Sie das Repository

   Bob klont das Repository lokal mit dem gestohlenen Konto, sodass er seinen Verlauf neu schreiben und seine Änderung erstellen kann, bevor er es zurück in den Hauptbereich überträgt.

4. Zurückspulen nach dem Audit-Commit

   Der zuletzt überprüfte Commit für die Hauptversion fügte dem Authentifizierungsdienst eine Prüfprotokollierung hinzu, genau den Datensatz, der die Änderung kennzeichnen würde, die Bob vornehmen wird. Also beginnt er damit, seinen lokalen Haupt-Commit zurückzuspulen und den Audit-Logging-Commit vollständig zu löschen. Auf einem geschützten Branch wäre dies unmöglich. Hier ist es ein einzelner Befehl.

5. Mit Gewalt über die Hauptleitung schieben

   Bob schiebt seine zurückgespulte Geschichte direkt in den Hauptteil. Da der Branch keinen Schutz hat, akzeptiert ihn der Server und der überprüfte Audit-Logging-Commit wird aus dem gemeinsam genutzten Branch entfernt, als ob er nie zusammengeführt worden wäre. Alle anderen, die main ziehen, verlieren nun stillschweigend auch dieses Commit. Das ist es, was ein Force-Push auf einen gemeinsam genutzten Branch bewirkt: Es schreibt die Geschichte neu, die andere Leute bereits überprüft und darauf aufgebaut haben.

6. Öffnen Sie die Authentifizierungs-Middleware

   Jetzt fügt Bob seinen eigenen Code hinzu. Er öffnet die Authentifizierungs-Middleware, die Datei, die jede Anfrage an die Dispatch-API durchläuft, und liest sie sauber, bevor er sie berührt.

7. Bepflanzen Sie die Umgehungsstraße

   Bob fügt oben in der Middleware einen kurzen Block hinzu. Es liest sich wie ein Kompatibilitäts-Shim für ein Legacy-Relay, aber jede Anfrage, die einen festen Header-Wert trägt, wird als Administrator durchgewinkt, ohne Token und ohne Signaturprüfung. Eine Hintertür zu jeder Route, die der Dienst schützt, getarnt als harmlose Pipelines.

8. In Sichtweite begraben

   Der hinzugefügte Block befindet sich zwischen gewöhnlicher Middleware und liest sich wie etwas, das ein Backend-Ingenieur schreiben könnte. Nichts davon sieht auf den ersten Blick besorgniserregend aus, und genau aus diesem Grund würde es eine kurze Rezension überstehen, falls es jemals eine Rezension gäbe.

9. Commit auf main

   Bob übergibt die Änderung direkt an main mit einer Meldung über eine Relay-Zeitüberschreitung, nichts, was die Authentifizierung erwähnt. Es gibt keine Branch und keine Pull-Anfrage; Der Commit befindet sich bereits im Standard-Branch seines Klons.

10. Gehen Sie direkt in die Produktion über

    Bob schiebt den Commit direkt nach Main. Es gibt keinen Pull-Request zum Öffnen, keinen Prüfer zum Genehmigen und keine Statusprüfung zum Bestehen. Der Branch akzeptiert es, und da er mit der automatischen Hauptbereitstellung zusammengeführt wird, ist seine Hintertür Sekunden später in der Produktion aktiv.