Martedì scorso uno dei più importanti siti web internazionali sulla simulazione di volo, AVSIM, è stato letteralmente distrutto. Il pomeriggio del 14 maggio la BBC è stata la prima testata giornalistica a riportare la notizia.
Quando dico distrutto, non parlo di un semplice delirante deface della home page fatto da qualche cracker arabo, russo o sudamericano, intendo proprio dire che le partizioni dei due server che contenevano i dati sono state spazzate via.
Benché spesso ne abbia la possibilità, è raro che un attaccante danneggi a tal punto un server, purtroppo però questa volta la storia è andata diversamente.
AVSIM era un vero punto di riferimento per gli appassionati. Era online dal 1996, 13 anni di storia di flight simulation… volati via!
Un forum temporaneo per gli amanti del sito è reperibile qui.
Tom Allensworth, founder del sito, ha affermato: “AVSIM è totalmente offline in questo momento e pensiamo che sarà così per ancora un po’ di tempo a venire. Non siamo in grado di predire quando torneremo online, se mai lo potremo tornare effettivamente.”
La notizia ha fatto velocemente il giro della Rete e ha scatenato forti reazioni di indignazione e rabbia. Ovviamente contro il criminale di turno, ma anche nei confronti dei gestori del sito.
A rendere ancora più tragica la storia, infatti, è l’assenza di un adeguato piano di backup.
Il sito era costituito da due server principali, uno per le mail e la libreria e uno per il sito web effettivo e il forum. Sul primo era presente il backup giornaliero del secondo e viceversa.
La strategia di backup è piuttosto semplice ed intuitiva, già migliore dei backup di un server salvati sul server stesso, come capita a volte di vedere, o della loro totale assenza. Ma non è assolutamente adeguata ad un sito di quel rilievo!
E infatti, martedì scorso, quando l’attaccante è stato in grado di compromettere entrambi i server (che probabilmente condividevano grosse parti di configurazione, se non addirittura le credenziali), questa strategia ha dimostrato la sua fragilità.
Quantomeno serviva un server di backup dedicato adeguatamente protetto e isolato, meglio ancora sarebbe stato un backup off-site, il backup dei backup era anche possibile ma forse eccessivo.
La frase di Allensworth “oltre 12 anni di operazioni molto sicure e nessun attacco riuscito mi indicava che il nostro approccio quantomeno funzionava” mi ricorda un po’ quelli che dicono “io non ho un antivirus e non mi son mai preso niente”. Metodo di ragionamento tipicamente umano, ma non razionale.
A parte il fatto che non si può sapere con facilità e certezza se si è stati compromessi o meno (non sempre l’attaccante è così stupido da cancellare tutto, è più facile che rubi silenziosamente i dati che gli interessano), bisogna anche considerare che se ti è andata bene per un certo tempo, non puoi inferire che ciò che fai va bene, puoi essere stato solo fortunato, mentre devi concludere che hai sbagliato qualcosa se capita un incidente informatico.
Sulla reale efficacia di un anti-virus abbiamo già sollevato dei dubbi, ma è comunque un layer di sicurezza in più che risulta spesso utile.
Discorso analogo a quello dei backup vale per i file di log: se ti tirano giù il server web, almeno dovresti poter tracciare chi è stato e come ha fatto! E invece anche i file di log sono andati distrutti perché non adeguatamente protetti e gestiti. Speriamo che almeno l’hoster conservi qualche informazione utile.
Quanto alle ragioni che hanno portato alla compromissione del server, al momento non è nota né la tecnica usata né il suo autore.
Siccome non è possibile risalire ad un’immagine recente del sito attraverso la Wayback Machine, non mi è facile fare delle ipotesi in merito. Potrebbe essere stata colpa di qualche web application vulnerabile come il forum in PHP (oltre il 60% dei siti web continene vulnerabilità serie afferma una recente ricerca; secondo la mia esperienza direi oltre il 90% il problema può essere al massimo trovarle), del web server o del mail server.
Mi preme segnalare a questo proposito una vulnerabilità appena segnalata nel web server Microsoft IIS 6, che fin ora si era comportato piuttosto bene dal punto di vista della sicurezza, al contrario delle versioni precedenti.
La vulnerabilità riguarda il modo in cui IIS gestisce richieste WebDAV contenenti caratteri Unicode e permette di bypassare l’autenticazione in directory protette o l’upload di file sul server. La falla ricorda molto quella che affliggeva IIS 4 e 5 nel 2001 e che aveva fatto letteralmente delle stragi anche per colpa dei worm CodeRed e Nimda che la sfruttavano.
Dettagli tecnici sulla vulnerabilità sono reperibili a questo indirizzo.
Come ho già detto non sappiamo come l’attaccante abbia violato AVSIM, ma la metodologia a grandi linee è sempre suddivisa in due fasi principali.
Inizialmente si sfrutta una vulnerabilità dell’applicazione web o del server per poter eseguire comandi arbitrari su di esso.
Siccome però i privilegi con cui si eseguono i comandi sono di solito quelli del web server, non è ancora possibile fare ciò che si vuole, tantomento distruggere le partizioni. L’attaccante caricherà allora sul web server qualche exploit di local privilege escalation (ce ne sono diversi sia per Windows che per Linux) per acquisire i privilegi di SYSTEM su Windows o di root su Linux e simili.
A quel punto la partita è conclusa.
