Avete presente quando ci sono quelle sere in cui sarebbe il caso di spegnere il telefono e buttare via le email senza leggerle? Ecco, l’altra sera un caro amico, nonché collega e ottimo programmatore, mi ha girato in tutta fretta il link ad un articolo circa la CVE-2015-8562. Si tratta di una minaccia di gravità molto elevata che, nel sito da lui segnalatomi, viene descritta così.
a vulnerabilità, già corretta con l’aggiornamento Joomla 3.4.6 e le patch per le versioni 1.5 e 2.5, è di una gravità inaudita. Finora non era mai successo che il giorno di rilascio di un aggiornamento di sicurezza il 30% dei siti Joomla ricevessero il primo attacco.
Di seguito vi riporto tutte le informazioni.
Innanzitutto, per i più profani, chiariamo che cosa sia la CODE INJECTION. In modo piuttosto semplificato è l’inserimento di codice malevolo e non autorizzato, all’interno delle pagine web di un sito. In questo caso parliamo di pagine in PHP.
Questo tipo di attacco avviene sfruttando delle “debolezze applicative” che spesso possono dare origine ad attacchi come de-facing o, per l’appunto, code injection. Non mi soffermerò su quanto è scritto nell’articolo, leggetelo perché è interessante.
Vorrei soffermarmi sull’importanza di effettuare manutenzioni evolutive (MEV) dei portali che vengono gestiti. Che ci crediate oppure no, esistono ancora clienti che reputano il sito qualcosa di statico, di fermo, come forse neanche una vetrina di negozio potrebbe essere.
Avere un portale aziendale, un sito per la propria attività o per la propria passione, significa inserire un contenitore di informazioni all’interno di torrente (anzi no, di un fiume) di altre informazioni. Nessun contenitore è inespugnabile, questo deve esser chiaro.
Molto spesso l’atteggiamento del cliente è quello di respingere i lavori di manutenzione evolutiva (aggiornamenti infrastrutturali, applicativi, e così via), esponendo il proprio sito a problemi e aspetti critici di non scarsa rilevanza.
Nel caso specifico si tratta di una attacco che, ufficialmente, viene descritto come segue:
Joomla! 1.5.x, 2.x, and 3.x before 3.4.6 allow remote attackers to conduct PHP object injection attacks and execute arbitrary PHP code via the HTTP User-Agent header, as exploited in the wild in December 2015.
Capite da soli l’importanza di effettuare la manutenzione ai vostri portali, avendo cura di installare sempre le ultime versioni e tenere aggiornate le estensioni che, nel caso di obsolescenza, potrebbero diventare fonti di exploit.
La stessa cosa vale per i template e spesso questo è un aspetto assolutamente trascurato. L’acquisto di template commerciale deve, necessariamente, coincidere con i processi di aggiornamento da parte dello sviluppatore. Se un template rimanesse indietro rispetto agli aggiornamenti sul core di Joomla, le conseguenze potrebbero essere di media ed elevata pericolosità.
Il sito:
racchiude tutti gli exploit a cui Joomla è stato soggetto ed è un punto di riferimento per chi decide di mettere in sicurezza il proprio portale.
La minaccia in questione è anche effetto di una programmazione che, nel caso specifico di Joomla, ha presentato delle discontinuità non di poco conto. Molti ricorderanno che nel passaggio tra la versione 2.x e la 3.x la migrazione non è stata assolutamente “dolce” come era stato preventivato. Al contrario ci sono stati seri problemi di compatibilità con i contenuti e non solo con le estensioni (cosa che tra l’altro è comprensibile). Joomla ha raggiunto una stabilità di efficienza con la versione 3.4 e successive che le hanno permesso di risolvere molti problemi legati a traduzione dei contenuti, aggiornamenti automatici e così via. Ciò nonostante l’architettura del portale dovrebbe essere ulteriormente migliorata, soprattutto per quanto riguarda la capacità di garantire la stabilità del sistema.
Sappiamo tutti che le minacce sono direttamente proporzionali alla diffusione del sistema utilizzato. Se un sistema è largamente diffuso, le minacce saranno maggiori rispetto ad un sistema sconosciuto. È pur vero che questo principio vale anche per le funzionalità contenute all’interno di una piattaforma web. Una piattaforma con 100 funzioni, è più esposta a rischi rispetto ad una con 20 funzioni.
Infine c’è l’aspetto dei backup. Fare un backup non significa controllare la solidità della propria infrastruttura web. Effettuare molti backup, senza controllarne effettivamente la genuinità è come non averne nessuno ed il rischio è quello di non riuscire più a risalire a dati consolidati, sicuri e integri.
Ad ogni modo nel link sopra riportato c’è scritto tutto ciò che deve essere adottato per rendere sicura la propria versione di Joomla. Con la speranza che la piattaforma, nel futuro, possa essere più stabile di oggi.
