Recentemente una famiglia di vulnerabilità relative a un BUG di Bash, l'interprete più comune su GNU/Linux, MAC OS e alcuni Unix, ed è stato chiamato SinfernoShock o Porta basculante (CVE-2014-6271). La questione più importante e allarmante a questo proposito ha a che fare con il fatto che detto BUG è presente a Bash da 20 anni, quindi si stima che la gravità della questione sia addirittura maggiore di Heartbleed.
Il Bash BUG o ShellShock Non è di per sé un codice dannoso (come virus informatici, spyware, malware, ecc.) quindi non può essere rilevato e bloccato da antivirus o sistemi simili, ma deve essere corretto nell'implementazione del software stesso che lo "subisce".
Si consiglia di applicare questo tutorial in ambienti controllati, per scopi legati alla ricerca e allo studio dell'informatica, come spiegato qui.
Cos'è il Bash BUG ShellShock?
Fondamentalmente il problema risiede nella possibilità che Bash deve memorizzare la definizione delle funzioni di scripting in variabili d'ambiente, più precisamente nel modo in cui queste funzioni vengono caricate da Bash.
Il BUG si manifesta quando in una variabile d'ambiente, dopo la definizione della funzione, viene aggiunto codice aggiuntivo che Bash continuerà ad analizzare ed eseguire dopo aver caricato la funzione.
Con il seguente comando, una definizione di funzione vuota, codice arbitrario, è stata caricata nella variabile "x" e quindi è stato chiamato Bash.
Quello che succede è che prima di chiamare Bash, è stata caricata la variabile d'ambiente ed è stato eseguito il codice iniettato che mostra semplicemente la stringa "vulnerabile" sulla console (potrebbe andare peggio ovviamente!). Quindi Bash è stato eseguito e il comando echo è stato chiamato come esempio. Una variante più semplice del comando per eseguire il test:
$ env x = '() {:;}; eco vulnerabile 'bash Quest'ultimo comando mostrerà la stringa "vulnerabile" sullo schermo se la versione Bash ha il BUG o non mostrerà nulla se è una versione patchata.
Come indicato nell'introduzione, questo BUG determina una famiglia di vulnerabilità che potrebbe essere utilizzata da un utente malintenzionato per controllare i computer in remoto. All'interno di queste varianti, ce ne sono alcune un po' più complesse, altre molto semplici e altre più o meno complesse. Esistono varianti relative ai moduli Apache e CGI, altre per il client DHCP e alcune un po' più elaborate di altre.
Per questa guida verrà utilizzato uno dei casi più semplici, attacco shellShock su client DHCP GNU/Linux.
Sistemi coinvoltiOspite della vittima:
GNU/Linux con Bash 4.3
Client DHCP isc-dhclient-4.2.4
IP 192.168.1.88 (tramite DHCP)
Ospite in attacco:
Windows XP
Server DHCP "tftp32" di Ph. Jounin
IP: 192.168.1.100
INGRANDIRE
Per la dimostrazione del concetto, assumiamo una LAN in cui siano collegati sia la vittima che l'attaccante.
Poiché il software client DHCP viene eseguito con autorizzazioni di amministrazione, l'autore dell'attacco tenterà di includere codice dannoso in alcuni parametri dell'opzione DHCP nella configurazione DHCP assegnata alla vittima.
Processi
1) L'attaccante esegue il software del servizio DHCP {(ftp32 ”di Ph. Jounin) è stato utilizzato per questa guida}
1.1) Seleziona l'interfaccia di rete da utilizzare e premi il pulsante "Impostazioni"
1.2) Configurare le opzioni per eseguire solo il servizio DHCP.
1.3) Vai alla scheda "DHCP" e configura come segue:
1.4) Nota nel campo "Opzione aggiuntiva" è stata specificata l'opzione 114 (utilizzata in VOIP) e nel campo di dettaglio dell'opzione sono stati inseriti la definizione della funzione Bash e il codice dannoso:
() {ignorato;}; echo 'CODICE INiettato'; /bin/cat/etc/passwd 1.5) Premere "OK", il servizio DHCP è pronto.
2) Nel terminale di sistema della vittima, esegui il seguente comando per esporre il Syslog del sistema per quando eseguiamo la richiesta DHCP:
# tail -f / var / log / syslog &3) Supponendo che eth1 sia l'interfaccia di rete della vittima, esegui il client DHCP:
# dhclient eth14) Il comando eseguirà la richiesta DHCP e l'attaccante l'assegnazione corrispondente:
5) Nel terminale della vittima, grazie al comando tail che era in background mostrando il syslog di sistema, verrà visualizzata l'esecuzione del codice iniettato, in questo caso verrà visualizzata la stringa "INJECTED CODE" e quindi il contenuto del file /etc/passwd della vittima (potrebbe essere molto peggio…):
Quest'ultima parte è grazie al comando "/bin/cat/etc/passwd”Che fa parte della stringa specificata come opzione 114.
L'autore dell'attacco potrebbe aver eseguito altri comandi ed eseguire qualsiasi azione poiché dispone dei permessi di "root" poiché il client DHCP della vittima viene eseguito con tali privilegi.
ConsiderazioniPer questa guida è stato utilizzato un software comune, senza variazioni sul sistema Victim. Questa vulnerabilità è presente in altre applicazioni che utilizzano Bash per eseguire parametri o script nel sistema.
è imperativo applicare gli aggiornamenti corrispondenti al sistema per prevenire questo tipo di attacco.
È bene chiarire che i contenuti qui presentati sono utili sia per comprendere la meccanica dell'attacco sia per sensibilizzare su quest'ultimo punto. Tieni presente che questa sentenza esiste da almeno 20 anni, quindi potrebbe essere stata applicata molto prima che fosse rilasciata.
Ti è piaciuto e hai aiutato questo Tutorial?Puoi premiare l'autore premendo questo pulsante per dargli un punto positivo
