Gli attacchi informatici sono la quotidianità per chiunque si occupi di sicurezza, ed una recente vulnerabilità dell'editor JCE porta a nuove riflessioni sul tema sicurezza.

Per chi non ha seguito il problema, riporto, brevemente, ciò che è successo. All'interno di questo editor, usato da più di un CMS, e da Joomla principalmente, si sono verificati due problemi di sicurezza:

• un utente non autenticato poteva caricare un file
• lo stesso utente poteva cambiare l'estensione del file.

Ciascuna delle situazioni con consisteva in un reale pericolo, sinché esse non occorrevano simultaneamente. L'editor permetteva di caricare solo files di immagini o di archivio, ma non poneva vincoli sulle funzioni che rinominavano il files. Ciò ha permesso di caricare files PHP con un estensione fittizia (es: jpeg) e poi di rinominarli come PHP, ovvero files eseguibili da remoto.

A questo punto era possibile richiamare il file tramite interfaccia web ed eseguire qualsiasi operazione il file consenta.

 

Impedire l'esecuzione di shell remote

È impossibile impedire un tale evento, ma si possono arginare attacchi come quanto successo con JCE.

Le applicazioni web hanno dimenticato quanto era standard nei vecchi sistemi server. Probabilmente chi non viene dai "vecchi" sistemi unix non conosce, o conosce da poco, il concetto di NX-bit (termine moderno per un vecchio concetto) o di noexec partition.

In parole povere i termini sopra espressi indicano l'impossibilità di eseguire codice ove si presume che non ci sia codice eseguibile. Riportato al mondo dei processori, Intel per citare il mondo di chi usualmente ci segue, non si vede perché l'area dati (il prefisso DS, data segment, per chi conosce il linguaggio macchina) debba poter eseguire del codice. Riportato al mondo dei server, non si capisce perché un codice debba essere eseguito ove vi sono i files di log; e qui citiamo la possibilità, a dire il vero poco sfruttata dai se dicenti sysadmin attuali, di montare un filesystem senza possibilità di eseguire programmi nello stesso.

Quanto qui riportato non è certo una soluzione "definitiva" a questo tipo di attacco, almeno in senso generale, ma può essere una soluzione per quei programmi, come il citato JCE, in cui il problema non è una cattiva progettazione ma un comprensibile calo di attenzione.

In questo articolo non focalizzeremo l'attenzione su come rimuovere l'handler di PHP dalle directories "incriminate", cosa che qualunque sysadmin saprà fare, una volta messo in allarme, ma sugli interventi possibili al webmaster non sysadmin.

Joomla ha delle directories, o percorsi, all'interno delle quali non devono trovarsi dei files eseguibili, ed è su questa "presunzione"che era nato l'hack di JCE. Infatti si supponeva che all'interno della directory /images si trovassero solo immagini, pertanto il rinominare un file in questa directory era stata considerata un'operazione sempre lecita.

 

Accesso alle shell remote

Come detto l'attacco consisteva nel caricare un file PHP nella directory /images, usata normalmente da JCE per le proprie immagini, come se si trattasse di una immagine e poi rinominare lo stesso come file eseguibile.

Una volta caricato il file era possibile richiamare lo stesso e eseguire qualsiasi comando desiderato. Rifacendoci  a quanto esposto nella introduzione vedremo ora come impedire un tale comportamento.

.htaccess per bloccare il richiamo di shell remote

Quanto qui indicato preserva solo da "a momentary lapse of reason", per dirla con i Pink Floyd; questo problema è comunque quello alla base di massima parte degli attacchi.

La soluzione consiste nell'impedire a directories non destinate a contenere files PHP di poter essere usate per attacchi di tipo remote shell.

Le directories in questione sono /images, /media ed altre. Apriamo il file .htaccess e subito dopo "RewriteEngine On" inseriamo:

 

RewriteCond %{REQUEST_URI}  ^/images/  [NC,OR]
RewriteCond %{REQUEST_URI}  ^/media/  [NC,OR]
RewriteCond %{REQUEST_URI}  ^/logs/  [NC,OR]
RewriteCond %{REQUEST_URI}  ^/tmp/
RewriteRule .*\.(phps?|sh|pl|cgi|py)$ - [F]

 

Questo impedirà il richiamo da web di file *.php (che sono quelli che più ci interessano),*.phps, *.sh, *.pl, *.cgi e*.py, nelle directories indicate indicate e nelle relative sotto directorories.

Notate:

• il flag [NC]: le directories di Joomla sono scritte in minuscolo, ma vogliamo evitare che qualcuno nasconda le directory sotto un nome alternativo (es: Images);
• il flag [NC] non presente nel nome file: in realtà l'handler è usualmente associato alla sola estensione minuscola, quindi un file con estensione maiuscolo verrà scaricato ma non eseguito. se vi sentite più sicuri mette un [NC, F] anche nella RewriteRule;
• la redirezione a "-": in realtà non serve, anzi è inutile, specificare una redirezione quando si vuole segnalare un errore.
• il flag [F] senza [L]: il flag [L] (last, ultima istruzione, ovvero interrompere l'esecuzione) è implicito quando si specifica [F] (forbidden: vietato, errore HTTP status 403)

 

Immagini in path non convenzionali

Alcuni programmi non usano la directory /images per salvare i loro files, in tal caso è opportuno inserire le directories usate all interno delle condizioni di filtro sopra illustrate.

JoomShooping

Joomshopping per ragioni storiche salva i files di immagini all'interno della directory del componente, pertanto basterà aggiungere la seguente riga in cima alla lista prima vista:

RewriteCond %{REQUEST_URI}  ^/components/com_jshopping/files/  [NC,OR]

 

Virtuemart 1.x

Virtuemart 1.x salva anche esso i files di immagini all'interno della directory del componente, pertanto basterà aggiungere la seguente riga in cima alla lista prima vista:

RewriteCond %{REQUEST_URI}  ^/components/com_virtuemart/shop_image/  [NC,OR]

 

Protezione da Shell Remote

Come spiegato questo aiuta, ma non è la soluzione definitiva: in realtà non vi è una soluzione.

Per il resto un'assistenza qualificata è la migliore garanzia.