Bypass protezione ramo

Cos’è Bypass protezione ramo?

Un ramo predefinito senza protezione accetta qualunque cosa gli venga inviata. Chiunque abbia accesso push può impegnarsi direttamente nel main o nel push forzato sulla sua cronologia. I controlli di revisione e di stato funzionano solo se qualcosa impone modifiche attraverso di essi. Passerai direttamente al main con le credenziali di un collaboratore oggetto di phishing, quindi eseguirai un push forzato sulla cronologia e vedrai il CI saltare. Aggiungerai la protezione del ramo: richiedi una richiesta pull, revisori, superamento dei controlli e nessun push forzato, con l'impostazione include-administrators attivata, perché una regola che gli account privilegiati possono aggirare non è un controllo.

Cosa imparerai in Bypass protezione ramo

• Riconoscere cosa consente un ramo predefinito non protetto: push diretti e push forzati che riscrivono la cronologia e ignorano la revisione delle richieste pull e i controlli dello stato degli elementi della configurazione
• Traccia il modo in cui un singolo account collaboratore compromesso può inviare il codice non revisionato direttamente alla produzione quando si unisce al ramo predefinito con distribuzione automatica
• Comprendere perché un push forzato su un ramo condiviso è pericoloso, perché riscrive la cronologia revisionata e sviluppata da altri e può cancellare i commit senza registrazione
• Applicare regole di protezione del ramo che richiedono una richiesta pull, revisori obbligatori e il superamento dei controlli di stato e che bloccano i push forzati sul ramo predefinito
• Abilita l'opzione include-administrators in modo che la regola non possa essere aggirata da account privilegiati, rendendo il controllo applicabile a tutti

Bypass protezione ramo — Fasi della formazione

1. Un posto da collaboratore rubato

   Oggi Bob prende di mira Riftwell, un'azienda di software logistico. Ha phishing le credenziali di un collaboratore per il repository dispatch-api e vuole che il proprio codice venga eseguito in produzione, senza che una sola persona lo riveda prima. Inizia aprendo il repository a cui può inviare l'account rubato.

2. Niente protegge il main

   La scheda di stato del repository dice a Bob tutto ciò di cui ha bisogno. Il ramo predefinito è main, la sua protezione del ramo non legge nessuno e ogni push a main viene distribuito direttamente alla produzione. Senza regole sul ramo, può spingersi direttamente ad esso e forzare la sua storia, e qualunque cosa porti alla produzione da sola.

3. Clona il repository

   Bob clona il repository localmente con l'account rubato, in modo da poter riscrivere la sua cronologia e creare la sua modifica prima di riportarla al main.

4. Riavvolgi oltre l'audit commit

   Il commit più recente esaminato sul registro di controllo aggiunto principale al servizio di autenticazione, esattamente il record che segnalerebbe la modifica che Bob sta per apportare. Quindi inizia riavvolgendo il commit principale locale, eliminando completamente il commit di registrazione di controllo. Su un ramo protetto ciò sarebbe impossibile. Qui è un singolo comando.

5. Spinta forzata sulla principale

   Bob spinge con forza la sua storia riavvolta direttamente al main. Poiché il ramo non ha protezione, il server lo accetta e il commit di registrazione di controllo esaminato viene eliminato dal ramo condiviso, come se non fosse mai stato unito. Tutti gli altri che tirano main ora perderanno silenziosamente anche quel commit. Questo è ciò che fa una spinta forzata verso un ramo condiviso: riscrive la storia che altre persone hanno già rivisto e costruito.

6. Apri il middleware di autenticazione

   Ora Bob aggiunge il proprio codice. Apre il middleware di autenticazione, il file attraverso cui passa ogni richiesta all'API di invio, e lo legge in modo pulito prima di toccarlo.

7. Pianta il bypass

   Bob aggiunge un breve blocco nella parte superiore del middleware. Sembra uno spessore di compatibilità per un relè legacy, ma qualsiasi richiesta che trasporta un valore di intestazione fisso viene inoltrata come amministratore, senza token e senza controllo della firma. Una porta secondaria su ogni percorso protetto dal servizio, mascherata da innocui impianti idraulici.

8. Sepolto in bella vista

   Il blocco aggiunto si trova nel middleware ordinario e si legge come qualcosa che un ingegnere di backend potrebbe scrivere. Niente sembra allarmante a prima vista, ed è esattamente il motivo per cui sopravvivrebbe a una rapida revisione, se mai fosse avvenuta una revisione.

9. committati nel main

   Bob conferma la modifica direttamente su main con un messaggio relativo al timeout del relè, senza nulla che menzioni l'autenticazione. Non sono presenti diramazioni e richieste pull; il commit è già sul ramo predefinito nel suo clone.

10. Vai direttamente alla produzione

    Bob invia il commit direttamente al main. Non è necessaria alcuna richiesta pull da aprire, nessun revisore che la approvi e nessun controllo dello stato da superare. La branch lo accetta e, poiché si unisce alla distribuzione automatica principale, la sua backdoor è attiva in produzione pochi secondi dopo.