Sei uno sviluppatore web? Utilizzi Git? Se la risposta é sí, ti consiglio di perdere 5 minuti a leggere questa breve, quanto inquietante, storia di orrore informatico, che vede come protagonista (nei panni dell'assassino) l'insospettabile Git.
Tutto nasce da un dettaglio banale, che per molti può essere scontato, ma che invece molti altri non notano o ignorano per inesperienza: durante il processo di inizializzazione di un repository, il comando
Una volta scaricata la cartella .git basta entrarci e resettare il repository e cancellare il file index. In questo modo si "imbroglia" Git, gli si fa credere di essere autorizzati ad avere accesso al repository (d'altronde abbiamo sul PC tutti i file contenuti nella cartella nascosta che si trova SOLO all'interno del repository) e tramite il comando
Pensi sia assurdo che qualcuno lasci la porta aperta agli hacker in questo modo? Anche a me sembrava strano, ma Google conferma che non sono pochi quelli che hanno deciso di rendere open source il loro sito/web application in maniera del tutto inconsapevole. Una storia paurosa e con un pessimo finale, a meno che il nostro sistemista eroe non decida di correre ai ripari. Per farlo basta creare un file .htaccess nella directory nascosta .git ed inserire la seguente impostazione:
Verifica di persona, su Google, quanti siti hanno questa vulnerabilità con la query:
Why so serious?
Tutto nasce da un dettaglio banale, che per molti può essere scontato, ma che invece molti altri non notano o ignorano per inesperienza: durante il processo di inizializzazione di un repository, il comando
git init crea una cartella nascosta nominata .git, che contiene informazioni e log relativi al repository software appena inizializzato. Questa cartella all' interno del codice sorgente di un'applicazione classica, con codice compilato é innocua e possiamo anche trascurarla. Se invece questa cartella si trova in una cartella pubblicata sul web server di una web application? Il bravo sistemista protegge le cartelle che non vuole rendere pubbliche tramite l'inserimento di apposite regole nel file .htaccess. Non tutti sono bravi sistemisti. Nel secondo caso si lascia esposta una cartella che contiene riferimenti al nostro repository, ai collaboratori , l'elenco delle modifiche e molto altro. Fosse questo il problema.Può andare peggio di così?!
Sì. Una volta verificato che la cartella .git sia disponibile ed accessibile, basta scaricarla sul proprio PC; wget è l'ideale:wget -r --no-parent http:/website.com/.git
Una volta scaricata la cartella .git basta entrarci e resettare il repository e cancellare il file index. In questo modo si "imbroglia" Git, gli si fa credere di essere autorizzati ad avere accesso al repository (d'altronde abbiamo sul PC tutti i file contenuti nella cartella nascosta che si trova SOLO all'interno del repository) e tramite il comando
git reset --hard viene ripristinato lo stato del repository aggiornato all'ultimo commit; questo é possibile perche nella cartella nascosta sono presenti queste informazioni. Git analizzerà la cartella e noterà che non é presente alcun file e quindi eseguirà imperterrito il suo compito chiedendo al server di inviare i file presenti per riallineare la cartella locale con il server. In parole povere comincerà a scaricare il codice server side dell'applicazione e tutto quello che il programmatore ha inserito nel repository: documentazione, copie di database, commenti ecc ecc. Oltre a clonare in locale una qualsiasi applicazione web, sito e portale, questa disattenzione può essere usata per recuperare password amministrative e organizzare facili attacchi alla macchina che li ospita.Pensi sia assurdo che qualcuno lasci la porta aperta agli hacker in questo modo? Anche a me sembrava strano, ma Google conferma che non sono pochi quelli che hanno deciso di rendere open source il loro sito/web application in maniera del tutto inconsapevole. Una storia paurosa e con un pessimo finale, a meno che il nostro sistemista eroe non decida di correre ai ripari. Per farlo basta creare un file .htaccess nella directory nascosta .git ed inserire la seguente impostazione:
Deny from all
Verifica di persona, su Google, quanti siti hanno questa vulnerabilità con la query:
inurl:.git intitle:index.ofWhy so serious?
X
THE END
THE END