Quanto è facile nascondere l'aggiunta di un file a un repository git

3

Ecco lo scenario ...

Ho un repository git su un server che potrebbe essere stato compromesso. Il mio team di sviluppo dice che possono fidarsi dei file nella directory che ospita il repository git perché tutti i commit (diffs) e i nuovi file che vengono aggiunti al repository sono controllati e firmati dal repository 'owner' e qualsiasi nuovo file mostrerà come nuovo alla versione locale quando viene effettuato uno stato o un pull.

Tuttavia, credo che se una persona ha compromesso il server su cui è alloggiato il repository git, ci deve essere un modo per aggiungere un file a quel repository e coprirlo in modo che quando uno sviluppatore fa il suo prossimo tiro, il nuovo il file non viene visualizzato nel loro stato git. È questo il caso?

    
posta David Scholefield 23.06.2015 - 19:57
fonte

2 risposte

3

I tuoi sviluppatori sono corretti in quanto qualsiasi modifica al repository sarà riflessa da un nuovo commit. I commit precedenti non possono essere modificati senza che a tutti gli sviluppatori venga notificato un conflitto grave durante l'aggiornamento dal repository remoto.

Detto questo, sarebbe semplice per un utente malintenzionato aggiungere un nuovo commit al repository che verrebbe automaticamente scaricato e applicato ai repository locali degli sviluppatori quando si estrae dal server. Trovo estremamente improbabile che i tutti che vengono sottoposti a commit al repository vengano riesaminati manualmente a meno che non si tratti di un progetto usato raramente. Anche se vengono esaminati, un aggressore motivato potrebbe apportare un cambiamento innocuo che ha implicazioni sulla sicurezza. Ad esempio, nel 2003, una persona sconosciuta ha aggiunto un commit al kernel Linux che conteneva una vulnerabilità di escalation della root . Questo accadeva quando Linux utilizzava CVS, ma l'unico vero git di protezione contro questo tipo di attacco è il commit di gpg.

A meno che tu non stia utilizzando firme crittografiche forti per proteggere i tuoi commit, non c'è modo di sapere veramente se una terza parte ha modificato il tuo repository senza eseguire una verifica completa di tutti i commit dello sviluppatore che li ha presumibilmente creati dalla data della compromissione del server. Questo è l'unico modo per assicurarsi veramente che un utente malintenzionato non abbia creato un commit da uno dei tuoi sviluppatori.

Spetta a te determinare se il rischio che l'attaccante lo faccia o no vale lo sforzo di cercare di scoprirlo. Se sei una piccola azienda che produce software che non memorizza, protegge o accede a dati sensibili e questo sembra un tipico compromesso drive-by per trasformare il tuo server in un host spam, probabilmente non mi preoccuperei. Se elaborate grandi quantità di denaro, probabilmente lo farei.

Ora sarebbe anche un buon momento per assicurarti di non memorizzare alcuna credenziale all'interno del tuo repository. Cose come le password del database, le chiavi API per altri servizi, le chiavi TLS ei segreti crittografici utilizzati per l'autenticazione dei cookie di sessione non devono mai essere archiviati insieme al codice sorgente e dovresti considerare quelli che sono stati compromessi e richiedono la rotazione.

    
risposta data 23.06.2015 - 20:48
fonte
2

Basandosi su ciò che è stato detto, la lettura dei registri di commit è tutto, tuttavia ci sono modi per ingannare l'utente finale e scaricarli da file che non sono ovvi per loro.

Un modo è quello di aggiungere file al database dell'oggetto git direttamente invece del repository (quindi usando il comando git hash-object invece del normale git add ). In questo modo non appaiono quando si digita un comando di lista, quindi non sarà ovvio che siano abbattuti.

$ echo 'version 1' > test.txt
$ git hash-object -w test.txt
83baae61804e65cc73a7201a7252750c76066a30

Il tuo database contiene il nuovo contenuto:

$ find .git/objects -type f
.git/objects/83/baae61804e65cc73a7201a7252750c76066a30

Ho visto i progetti utilizzare questo metodo per nascondere segreti e credenziali che non sono sicuri ed è semplicemente la sicurezza per oscurità.

    
risposta data 19.06.2017 - 21:06
fonte

Leggi altre domande sui tag