Joomla e sicurezza

[ezio]

Ciao a tutti.

Abbiamo verificato che in certe circostanze, l'installazione di certi
plugin per Joomla che l'utente finale può fare da sé può aprire problemi
di sicurezza.

In sostanza l'utente, da remoto, se entra come amministratore, può
assumere gli stessi privilegi dell'utente di apache e di converso agire
tanto sui file di /var/www quanto sui processi quanto con tentativi su.

Se c'è un joomla attivo su un sistema e il sistema è dell'utente chi se ne frega, ma che accade se sono tanti joomla e utenti su un sistema ?

Dobbiamo ancora vedere se questo è concesso solo al superamministratore, o anche all'amministratore, ma ci interessa comunque avere più joomla attivi sui quali la gente faccia le cose da sé con i plugin per la gestione dei file e perché non vorremmo
aprire porte ssh, mettere in piedi vpn o peggio che mai ftp, insomma
eviteremmo volentieri cose complicate o limitazioni degli accessi a firewall o cose fragili di fronte a un brute force attack.

Sapete qualcosa di queste problematiche ? Me le confermate ?

Stavamo pensando anche ad ambienti chroot o a più macchine virtuali
joomla (apache + php + file, db comune da un'altra parte). Sapete di solito come fanno i fornitori di servizio a dare le cose in sicurezza ? Oppure è solo paranoia.

Grazie e ciao.
Ezio.

[AdHe5]

In sostanza l'utente, da remoto, se entra come amministratore, può
assumere gli stessi privilegi dell'utente di apache e di converso agire
tanto sui file di /var/www quanto sui processi quanto con tentativi su.

Non ho ben capito nel dettaglio quale è il problema... Spiegami meglio come l'utente può fare tutto ciò così cerchiamo di metterci una pezza

In linea di massima dovrebbero bastare i normali accorgimenti per una configurazione sicura di php ovvero:

1) Disabilitare register_globals in php.ini
2) Evitare i path traversal
3) Evitare Inclusioni dinamiche
4) Disabilitare funzioni pericolose (tipo exec())

Inoltre il codice scritto deve essere scritto in modo da prevenire XSS e SQL Injection (Cosa che solitamente non dipende dall'amministratore di sistema)

Cmq qui puoi trovare un bel pò di roba sui principali problemi di sicurezza di php

Un buon metodo per mettere in sicurezza il tuo php è utilizzare suhosin che se ben configurato ti protegge da molti dei problemi citati in precedenza

Anche se so di non essere stato esaustivo spero di esserti stato utile

[ezio]

Grazie AdHe5 per i link utilissimi.

Non ho ben capito nel dettaglio quale è il problema... Spiegami meglio come l'utente può fare tutto ciò così cerchiamo di metterci una pezza

Non so ripeterlo nel dettaglio, non lo gestisco io, quindi se sono vago è perché non so con precisione i singoli passi dell'utente, né conosco Joomla. Ho solo visto il comportamento finale. Root di linux e l'admin joomla sono la stessa persona, quindi la cosa non ha prodotto inconvenienti.

L'admin joomla ha installato un gran numero di plugin da sé da remoto. Non dovrebbe trattarsi di superadmin (ma spero di sbagliarmi, perché a ben pensarci questo spiegherebbe tutto). Attraverso questi plugin lui navigando entra come in una finestra ssh-telnet e può tutto non solo sui suoi file di OS ma su quelli di www-data / apache, ed è in grado di killare processi di www-data, quindi di tutti gli utenti oltre a fare su verso root.

CIao.
Cosa può essere successo ?

[AdHe5]

Sfruttando un bug del codice di un componente di joomla che permette di fare una Remote File Inclusion si può caricare una shell php (tipo r57 c99 c2007) e utilizzarla per effettuare operazioni sulla macchina con i permessi di apache

Un modo per contrastare questo tipo di attacco è quello di dire al php di non permettere l'inclusione di files che si trovano all'esterno del dominio in questione

Se vuoi avere un'idea di cosa fanno queste shell in php leggi qui

[ezio]

Grazie. Mi sembra di capire che anche in questo caso sia proprio un errore l'apertura delle register_globals.

[AdHe5]

Grazie. Mi sembra di capire che anche in questo caso sia proprio un errore l'apertura delle register_globals

Si, ma impostare register_globals su OFF non basta, per essere sicuri è necessario impedire al php di richiamare file esterni al dominio

Suhosin (il sw che ti ho segnalato sopra) può proteggere da questi ed altri tipi di attacchi, inoltre è molto facile da installare e configurare...
Ti consiglio di provarlo

Qui se vuoi trovi un'ottima guida in italiano

[maxmurd]

Io non so se lo sviluppo di joomla è un po' caotico come quello di postnuke, dove ognuno fa i moduli un po' come vuole... ma non mi stupirei, è tipico di applicazioni open...
Per cui non mi stupisco che ci sia gente così zattona da inserire aggeggi come le exec in modo pericoloso oppure fare scarsi controlli di sicurezza sulle variablil.

Che succede se un atttaccante scopre in un modulo, che è a codice pubblico, che un exec può essere manipolato setando una qualsiasi variabile? Tenta di approfittare di server con register_globals = on per piazzare le proprie istruzioni...
Poi ci sarebbe anche allow_url_fopen che sarebbe meglio mettere a Off come dice anche AdHe5 per evitare che qualcuno trovi il modo di eseguire script esterni, e non vedo perché non farlo salvo rari casi...

Ti conviene in ogni cso mettere suhosin, una protezione in più è meglio di una in meno...
Purtroppo è il difetto di php, che è facile da programmare ma è anche facile permettere zozzerie di ogni genere a programmatori poco avveduti...

[ezio]

Scusate se riprendo l'argomento a distanza di tempo.

Stavamo scegliendo per l'hosting tra una poco maneggevole configurazione di apache multiistanza, e una poco performante soluzione con gabbie chroot o macchine virtuali. Poi la soluzione ci è arrivata, perché doveva esserci.
Quindi è vero che php (libapache2-mod-php) viene eseguito con i privilegi dell'utente apache2 (es. www-data) e che concedere hosting su questa base fa sì che un utente possa attaccare l'altro se fa un php malevolo o se semplicemente installa plugin di Joomla o altro, perché assume i diritti di www-data.
Ma se si installa su apache suphp il php viene eseguito con i privilegi dell'owner dei file: è esattamente quello che cercavo, così l'owner non fa danni.
Dato che nella documentazione di suphp non si vede e si perde un po' tempo prima di capirlo, una volta installato suphp (al solito come libapache2-mod-suphp) occorre disabilitare il modulo php, altrimenti il comportamento default è lo stesso di prima.
Ciao.

[maxmurd]

Grazie Ezio buono a sapersi!!