Il mio blog-spazio.

Grave vulnerabilità in Vesta Control Panel : aggiornate

Ciao a tutti cari amici sysadmin,
se utilizzate VestaCP con versione inferiore a 0.9.8-20
sappiate che siete vulnerabili ad una variante di Xor-DDos BotNet
e potreste essere compromessi.



Cosa sarebbe questo Xor ?
Citiamo direttamente Wiki
XOR DDoS is Trojan malware that hijacks Linux systems and uses them to launch DDoS attacks which have reached loads of 150+ Gbps.

In order to gain access it launches a brute force attack in order to discover the password to Secure Shell services on Linux.

Once Secure Shell credentials are acquired and login is successful,
it uses root privileges to run a script that downloads and installs XOR DDoS.

It is believed to be of Asian origin based on its targets, which tend to be located in Asia.

Several things are noteworthy about XOR DDoS, such as that it is built exclusively for ARM and x86 systems and it appears to have been programmed in C/C++.



Ok, praticamente è un hack tool multiuso,
quando attivato dal cattivone di turno, fa partire uno scanner di rete alla ricerca del target,
che in questo caso è la porta di VestaCP.
(mai usare le porte default dei servizi, credo di essermi salvato proprio per questo.)

Dicevamo,
quindi, la porta 8083!

Quando trova un IP con la 8083 aperta (vestacp login panel) inizia una sorta di tentativi di login,
non si tratta di un vero bruteforce;
ha solo bisogno di fare delle prove per generare dei file,
complice un metodo di controllo della password potenzialmente non sicuro da parte di vestaCP,
questo riesce ad accedervi in pochissimo tempo, per cui non importa la complessità della vostra password.

Nel dettaglio:

Lo script PHP /api/index.php
riceve la password dell'utente tramite richiesta POST
questo script scrive la password dell'utente in un file tmp
(ad esempio /tmp/tmp.blaAabBlablALA)

Questa operazione a detta del team di Vesta
era necessaria per proteggere la password dall'essere dirottata tramite il comando "ps faux".

Il percorso del file viene quindi passato allo script della shell
v-check-user-password
con il comando
v-check-user-password admin /tmp/tmp.blaAabBlablALA

Lo script legge il contenuto di /tmp/tmp.blaAabBlablALA
e chiama il sottoprocesso per generare l'hash in base al contenuto del file

hash=$($BIN/v-generate-password-hash $method $salt <<< $password)


Questa parte sicuramente consente l'esecuzione di codice arbitrario.
In teoria potresti inviare qualcosa di simile
"password; cat /etc/passwd"

per ottenere il contenuto di /etc/passwd


Nell'aggiornamento ecco cosa è stato fatto:
- Il processo PHP continua a ricevere password "unescaped" tramite POST
- Poi, invece di trasmettere questa password allo script, crea direttamente un hash
- questo hash è scritto in /tmp

In questo modo la stringa di codice iniettata come l'esempio sopra
"password; cat /etc/passwd"

invece di rispondere con le nostre password,
risponde/converte in una innocua hash
"7v8FlZefN7aQ9OoxGkR8lFHKejCxH9g64TQVVoRUuAObszO2hJy.CAs8ZG3JUtDKYQZNIZS61"

che rende impossibile iniettare qualsiasi cosa.

QUOTE:

apro parentesi
si poteva iniettare tranquillamente un :
echo root::0:0:root:/root:/bin/bash > /etc/passwd


viene da piangere
chiudo parentesi



La variante si chiama : Trojan.DDoS_XOR-1
gli attacchi al momento partono da server asiatici.

Ma vediamo come difenderci.

Come aggiornare?

Io sono su Debian,
per cui vado di apt,
se siete su centos/redhat andate di yum.

apt-get -qq update &&apt-cache show vesta|grep "Version"


Se siete così, siete ok:

root@cosmo:~# apt-get -qq update &&apt-cache show vesta|grep "Version"
Version: 0.9.8-20
root@cosmo:~#


o così:
v-list-sys-vesta-updates


Rel 20 (siete ok)

Altrimenti, se avete una revisione inferiore alla 0.9.8 rev20
dovete aggiornare,
ci sono diversi metodi,
quello ufficiale tramite comando shell :

v-update-sys-vesta-all

Se non dovesse funzionare, potete aggiornare in altri tre metodi:

1. Tramite interfaccia web
- Accedi come amministratore
- Vai alla scheda aggiornamenti
- Fai clic su un pulsante di aggiornamento sotto pacchetto Vesta

2. Tramite gestore pacchetti
- SSH tramite utente root nel tuo server
- yum update / apt-get update && apt-get upgrade

3. Tramite GitHub
- SSH come root
- Installa git: yum install git / apt-get install git
- Quindi eseguire questo comando:

cd $(mktemp -d)
git clone git://github.com/serghey-rodin/vesta.git
/bin/cp -rf vesta/* /usr/local/vesta/



Consiglio: al termine dell'update alla v20, di reinstallatela:
apt-get update && apt-get -reinstall install vesta-nginx vesta-php

yum reinstall vesta vesta-php vesta-nginx


Unpacking replacement vesta-php ...
Setting up vesta-nginx (0.9.8-20) ...
Starting vesta-nginx: vesta-nginx.
Starting vesta-php: vesta-php.
Setting up vesta-php (0.9.8-20) ...
Restarting vesta-nginx: vesta-nginx.
Restarting vesta-php: vesta-php.

..20!



Come faccio a capire se sono compromesso
o
Come tolgo il trojan dalla macchina?


Dopo aver aggiornato VestaCP,
partiamo con una semplicissima regola,
cambiate la maledetta porta di default di VestaCP.



sed -i 's/8083;/8555;/' /usr/local/vesta/nginx/conf/nginx.conf && v-add-firewall-rule ACCEPT 0.0.0.0/0 8555 TCP && service vesta restart


Con questo comando, passate dalla porta 8083, alla porta 8555.
Ma potete personalizzarvi la porta come volete.

Ora, vediamo se vi hanno bucato:

ls -la /etc/cron.hourly/

Se vi esce fuori il file gcc.sh siete nella cacca.

NON cancellate il file gcc.sh,
se questo viene delettato, verrà generato immediatamente un altro processo.

Il trojan ha un file raw proveniente da /lib/libudev.so,
Inserisce uno script in "cron hourly job" (crontab every 1 hour),
ovvero il nostro caro gcc.sh,

inoltre aggiungerà lo script per l'avvio della macchina in /etc/rc*.d
o su Centos /etc/rc.d/{init,rc{1,2,3,4,5}}.d ...

Disabilitiamo tramite chmod il file gcc.sh
chmod 0 /etc/cron.hourly/gcc.sh; chattr +ia /etc/cron.hourly/gcc.sh; chattr + i /etc/crontab


usiamo il comando top o ps aux per vedere il nome del virus, si tratta di un nome random
ha una forma di questo genere wnrkywzlgd, mtyxkeaofa, haahshahaa .....

Facciamo una ricerca dentro la macchina per vedere dove si posiziona:

find / -name wnrkywzlgd (esempio, mettete il nome del vostro)


Li disabilitiamo in base a dove li becca, in genere /usr/bin e /etc/init.d
(..sempre su debian, su centos o redhat come detto sopra, potrebbe essere diverso!)

chmod 0 /usr/bin/wnrkywzlgd
chmod 0 /etc/init.d/wnrkywzlgd
chattr +ia /usr/bin/wnrkywzlgd
chattr +ia /etc/init.d/wnrkywzlgd


Una volta individuato lo si killa:

kill -9 numeroPID

pkill wnrkywzlgd


Iniziamo a cancellare qualcosina:
rm -rf /usr/bin/wnrkywzlgd


Controlliamo che non vi siano altri nomi strani in /usr/bin
ls -lt /usr/bin | head


Cancelliamo l'origine del tutto:

rm -rf /lib/libudev.so


ora che avete bloccato il root-kit potete cancellare tutti gli altri restanti (gcc.sh ed i vari script in rc.d init.d)

Se passate anche una scansione di ClamAV e RKHunter non sbagliate!