di Flavio De Septis
C’è un tipo di attacco informatico che non fa rumore. Non manda in tilt i siti, non riempie lo schermo di messaggi minacciosi, non chiede riscatti. Lavora nel silenzio più assoluto, ed è proprio per questo che è tra i più insidiosi. Chi si occupa di sicurezza lo conosce bene e gli ha dato nomi tecnici — web shell, nel gergo, o “php2shell” quando riguarda i siti costruiti con il linguaggio di programmazione più diffuso del web il PHP. Ma per capirlo non serve essere informatici: basta pensare a una casa.
Immaginiamo che il sito di un’azienda, di un giornale o di un negozio online sia un edificio ha un ingresso principale, delle finestre, stanze aperte al pubblico e altre riservate. Chi lo gestisce si preoccupa, giustamente, di chiudere bene la porta e di controllare chi entra. Una web shell è qualcosa di più subdolo di un ladro che scassina quella porta: è come se un intruso, approfittando di una distrazione, installasse di nascosto una seconda porta — piccola, ben mimetizzata nel muro — di cui possiede l’unica chiave. Da quel momento entra ed esce quando vuole, senza passare dall’ingresso sorvegliato, e senza che nessuno se ne accorga. In termini tecnici è proprio così che viene descritta: uno script caricato su un server web che ne consente l’amministrazione da remoto, e che può servire anche come trampolino per raggiungere i sistemi interni collegati.
Il nome “php2shell” descrive esattamente questo passaggio: la trasformazione di un innocuo file del sito in un punto di comando a distanza. Un oggetto piccolissimo che consegna all’attaccante, di fatto, le chiavi di casa.
Come nasce quella seconda porta
Nessuno, ovviamente, installa di proposito una porta per i ladri. L’intruso sfrutta sempre una disattenzione, e le occasioni purtroppo non mancano.
A volte è un modulo del sito dove gli utenti possono caricare qualcosa — la foto del profilo, un documento, un allegato. Se quel modulo non controlla davvero ciò che riceve, l’attaccante può far passare, al posto di un’immagine, il piccolo programma che gli serve da grimaldello. Altre volte la falla è in uno di quei componenti aggiuntivi che si installano per arricchire un sito, rimasto vecchio e mai aggiornato: un ricambio difettoso che apre una crepa nel muro. E capita, con una frequenza che dovrebbe far riflettere, che tutto nasca da una password rubata o riutilizzata, che consegna l’accesso senza bisogno di scassinare nulla. Non a caso, chi studia il fenomeno osserva che l’installazione di una web shell avviene di norma sfruttando vulnerabilità delle applicazioni o errori di configurazione.
Il filo che lega questi scenari è sempre lo stesso: una fiducia mal riposta. Il sito, costruito per essere servizievole, finisce per eseguire un ordine che non avrebbe mai dovuto ricevere.
Quando la serratura è difettosa per tutti: lo zero-day
C’è poi una variante che amplifica tutto, e porta un nome quasi poetico: lo zero-day, il “giorno zero”. Indica una falla scoperta da chi vuole sfruttarla prima che chi ha costruito il programma ne sappia qualcosa. Il nome allude ai giorni di preavviso che il produttore ha avuto per correre ai ripari: zero.
Qui l’immagine della serratura difettosa diventa ancora più calzante. Di solito, quando si scopre un difetto, il produttore viene avvisato, prepara un ricambio e avverte i clienti. C’è un intervallo di allerta, ma anche una soluzione pronta. Con uno zero-day accade il contrario: il difetto lo conoscono per primi i ladri, che iniziano a usarlo mentre il fabbro non sa ancora che la sua serratura è difettosa e non ha nemmeno fabbricato il pezzo per ripararla.
Il problema è che quasi nessun sito è costruito da zero: quasi tutti poggiano su programmi diffusissimi, usati da milioni di persone. È un enorme vantaggio — software collaudato ed economico — ma ha un rovescio della medaglia. Quando salta fuori una falla in uno di questi programmi tanto popolari, l’attaccante non trova un bersaglio: ne trova migliaia, tutti con la stessa serratura difettosa. Gli basta scrivere una volta il proprio grimaldello per provare ad aprire, in modo automatico e in sequenza, un numero sterminato di porte. Ed è spesso attraverso quella falla che riesce poi a installare la sua seconda porta: lo zero-day è la crepa, la web shell è ciò che ci passa.
Perché proprio WordPress? Il paradosso della popolarità
A questo punto molti si saranno chiesti perché, quando si parla di siti attaccati, torni sempre lo stesso nome: WordPress. La risposta è istruttiva, perché smonta un luogo comune. WordPress non è attaccato perché sia fatto male — al contrario, il suo cuore è curato e aggiornato di frequente. È attaccato perché è ovunque: fa funzionare una quota enorme dei siti del mondo, e questa diffusione lo rende il bersaglio più conveniente in assoluto. È lo stesso motivo per cui si scassinano più spesso i modelli di serratura più venduti: non perché siano i peggiori, ma perché un grimaldello che li apre vale su moltissime porte. Lo stesso principio vale, del resto, per il linguaggio PHP in sé: le web shell più diffuse sono scritte proprio nei linguaggi più supportati dai server, e PHP è tra i più comuni in assoluto.
Il punto debole, poi, non vive quasi mai nel centro, ma ai margini. Un sito WordPress tipico è un collage di componenti aggiuntivi — i plugin e i temi — spesso sviluppati da terzi, talvolta abbandonati dai loro autori, raramente aggiornati da chi li ha installati. Basta che uno di questi pezzi sia difettoso e trascurato perché si apra la crepa. A tutto ciò si aggiunge il fattore umano: moltissimi di questi siti sono gestiti da chi non è un tecnico — piccole imprese, professionisti, blogger — che installano e poi dimenticano, con password deboli e nessuna sorveglianza.
Lo stesso ragionamento, è bene dirlo, vale per tutte le altre piattaforme molto diffuse: altri sistemi di gestione dei contenuti, le piattaforme di commercio online, i forum, i pannelli di amministrazione. Il denominatore comune non è il nome del software, ma una ricetta a tre ingredienti: larga diffusione, cioè molti bersagli identici; estensibilità con componenti di terzi, cioè molte crepe possibili; e gestione spesso poco professionale, cioè poca manutenzione. Dove ci sono questi tre ingredienti, lì l’attaccante trova terreno fertile.
La lezione, per chi ha una responsabilità, è che il vero bersaglio non è una tecnologia ma un comportamento. Due siti identici possono avere destini opposti a seconda di quanto chi li gestisce è disciplinato. La domanda giusta non è “quale piattaforma è sicura”, ma “quali dei miei siti sto davvero sorvegliando e mantenendo”.
Perché è così difficile accorgersene
Qui sta la parte più scomoda della storia. L’intruso che ha installato la sua porticina non ha alcun interesse a farsi notare: anzi, fa di tutto per confondersi con l’arredamento. Dà al proprio file un nome qualunque, lo nasconde in mezzo a centinaia di file legittimi, lo traveste perché somigli a qualcosa di normale — alcune shell, ad esempio, si camuffano da pagina di errore nascondendo un modulo di accesso segreto. Il sito, intanto, continua a funzionare perfettamente. I clienti navigano, gli ordini arrivano, le pagine si caricano come sempre.
Ed è proprio questa normalità apparente a ingannare. Il ragionamento istintivo — “va tutto bene, quindi siamo al sicuro” — è esattamente l’errore su cui l’attaccante conta. Mentre in superficie nulla cambia, dietro le quinte quella porta nascosta permette di rovistare tra i documenti, leggere informazioni riservate, portarsi via i dati dei clienti, e persino usare l’edificio come trampolino per raggiungere altri sistemi collegati. E il danno continua finché la porta resta lì: riparare la crepa originale non serve a nulla, se nel frattempo non ci si accorge che è stato aperto un passaggio tutto nuovo.
Le briciole lasciate dall’intruso: gli indicatori di compromissione
Per fortuna, anche l’intruso più accorto lascia delle tracce. Chi indaga sugli incidenti informatici le chiama indicatori di compromissione — in sigla IoC — e il modo migliore per immaginarli è pensare agli indizi su una scena del crimine: prove che segnalano una possibile violazione all’interno di una rete o di un sistema, le briciole che il visitatore indesiderato si lascia dietro senza volerlo.
Senza entrare nel tecnicismo, questi indizi appartengono a poche grandi famiglie. Ci sono quelli legati ai file — la comparsa di un documento che prima non c’era, o la modifica sospetta di uno esistente — quelli legati alla rete, come collegamenti verso indirizzi insoliti, e quelli legati al comportamento del sistema, come un traffico anomalo o attività fuori dall’ordinario. Nel caso specifico delle web shell, uno dei segnali più rivelatori è sorprendentemente semplice: la stessa pagina richiamata in modo ripetuto e insistente, come qualcuno che continua a bussare sempre alla stessa porticina sul retro. Allo stesso modo, l’analisi di quante volte e da dove vengono richiamati i singoli file del sito può tradire la posizione della shell nascosta.
La morale pratica è che questi indizi non si trovano guardando il sito dal davanti, come farebbe un visitatore, ma esaminando i suoi registri interni — i log, l’equivalente delle telecamere di sorveglianza che annotano ogni passaggio. È lì che gli indicatori restano impressi, ed è per questo che tenerli, conservarli e guardarli con regolarità non è una formalità burocratica ma la condizione stessa per accorgersi di essere stati visitati.
Cosa dicono le regole italiane
Non si tratta, peraltro, di buon senso lasciato alla sensibilità del singolo: in Italia esiste ormai un quadro di riferimento preciso. Il presidio nazionale contro gli attacchi informatici fa capo all’Agenzia per la Cybersicurezza Nazionale (ACN), al cui interno opera il CSIRT Italia, la squadra che interviene in caso di incidente, analizza rischi e attacchi in corso e tiene informate le amministrazioni. È la stessa struttura che, in occasione dei grandi attacchi internazionali, censisce i sistemi nazionali verosimilmente compromessi e allerta quelli esposti ma non ancora colpiti — esattamente il lavoro di chi dà l’allarme quando una serratura difettosa comincia a essere forzata in giro per il mondo.
Per chi gestisce i sistemi della pubblica amministrazione, poi, alcune buone abitudini sono addirittura obbligatorie. Le Misure minime di sicurezza ICT emanate dall’AgID — in vigore per tutte le PA — indicano un insieme ordinato di controlli di natura tecnologica, organizzativa e procedurale per contrastare le minacce più frequenti. Tra questi, due parlano direttamente alla nostra storia: l’obbligo di tenere un inventario aggiornato dei sistemi e un elenco dei software autorizzati, con le relative versioni — cioè sapere con precisione cosa si ha “sotto il cofano”, la premessa di ogni difesa — e quello, previsto sempre dalle stesse misure, di accedere con regolarità ai servizi di early warning che tengono aggiornati sulle nuove vulnerabilità. Tradotto: non aspettare che il difetto della serratura lo scopra l’intruso, ma farsi avvisare per tempo.
Vale la pena notare che, pur essendo vincolanti solo per il settore pubblico, queste indicazioni valgono come eccellente bussola anche per un’azienda privata: fotografano, in forma di norma, lo stesso insieme di accorgimenti che qualunque gestore accorto dovrebbe adottare.
Cosa si può fare, davvero
La notizia incoraggiante è che difendersi non richiede soluzioni fantascientifiche, ma qualcosa di più semplice e più raro: disciplina e costanza. Un po’ come per la salute, dove non esiste la pillola miracolosa ma funzionano le buone abitudini ripetute nel tempo.
La prima e più efficace difesa è impedire che quella seconda porta possa essere installata. Significa controllare con serietà tutto ciò che viene caricato sul sito e conservarlo in un luogo dove, anche se qualcuno vi nascondesse un programma dannoso, questo non possa essere messo in funzione. Un attrezzo da scasso chiuso in un ripostiglio sigillato non fa alcun danno. E poiché, come si è visto, la via d’ingresso più battuta sono proprio le vulnerabilità e gli errori di configurazione, individuarli e chiuderli è il passaggio cruciale per evitare la compromissione.
Poi c’è la manutenzione ordinaria, la meno affascinante e la più importante. Tenere aggiornati il sito e tutti i suoi componenti, eliminare quelli che non servono più, proteggere gli accessi degli amministratori con password solide e con la verifica in due passaggi ormai familiare a chiunque usi l’home banking. Ogni pezzo vecchio e dimenticato è una potenziale crepa; ridurne il numero riduce il rischio. E quando esce la correzione di una falla — soprattutto di uno zero-day — applicarla subito: dal momento in cui il ricambio è disponibile, i ritardatari diventano i bersagli più facili, perché gli attaccanti sanno che molti aggiorneranno con calma.
Serve infine qualcosa che somigli a un impianto di allarme con le telecamere. Esistono sistemi che sorvegliano i file del sito e segnalano quando ne compare uno nuovo o ne viene modificato uno in modo sospetto; altri che riconoscono i tentativi di intrusione mentre avvengono e li bloccano, anche senza conoscere i dettagli della falla, semplicemente perché qualcosa di anomalo sta accadendo; altri ancora che analizzano le tracce lasciate da ogni visita — quegli indicatori di compromissione di cui si è detto. È il lavoro silenzioso di chi, dietro le quinte, tiene gli occhi aperti al posto nostro.
E poi, perché la prudenza vuole che ci si prepari anche al peggio, conviene avere copie di sicurezza affidabili e un piano chiaro su come reagire se qualcosa va storto: non limitarsi a chiudere la porta scoperta, ma cambiare tutte le serrature e assicurarsi che non ne siano rimaste altre aperte. Trovare una seconda porta deve sempre far scattare la ricerca di una terza. Del resto, quando si scopre una web shell, la sua sola presenza segnala una violazione grave del server, che impone un intervento immediato di contenimento e bonifica.
La morale della storia
Dietro la maggior parte di questi attacchi non c’è un genio del crimine informatico, ma qualcosa di molto più banale e, in fondo, più rassicurante: una porta lasciata socchiusa. Un controllo saltato, un aggiornamento rimandato, una password troppo comoda. Persino lo zero-day, con tutto il suo fascino da film — la falla segreta, la corsa contro il tempo — lascia una lezione sobria: non si può impedire che esistano serrature difettose, perché nessun software sarà mai perfetto; si può però decidere in anticipo quanto si è pronti a reagire quando il difetto verrà fuori.
Per i più curiosi di seguito il bollettino ufficiale emanato da ACN
https://www.acn.gov.it/portale/w/php2shell-sanate-vulnerabilita-critiche-in-php
Le organizzazioni che attraversano questi momenti con meno danni non sono quelle fortunate, né quelle che hanno speso di più in tecnologia. Sono quelle che, nei mesi tranquilli, hanno fatto il lavoro noioso: sapere cosa possiedono, tenerlo in ordine, sorvegliarlo, prepararsi al guasto. Perché la buona sicurezza nasce raramente da un singolo gesto eroico. Nasce dalla somma di tante piccole attenzioni che, messe insieme, rendono il lavoro dell’intruso così faticoso e rischioso da non valerne più la pena. Ed è esattamente questo, alla fine, lo scopo: non costruire un muro invalicabile — non esiste — ma scoraggiare chi vorrebbe scavalcarlo.
