Ci sono dei problemi nei siti di organizzazioni ed enti italiani, che vanno oltre gli attacchi. Le ipotesi di minaccia, aiutano ad analizzare disguidi generali che forse si possono evitare
E’ stata lanciata una nuova serie di offensive da parte del gruppo di attivismo filo russo Killnet e i suoi sottogruppi organizzativi, contro aziende e istituzioni italiane.
Secondo quanto rivendicato siamo già da ieri alle 5.00 del mattino sotto attacco che, per quanto riguarda lo stato attuale, ha impattato in maniera lieve o inesistente le nostre infrastrutture. Io personalmente ho riscontrato pochissime indisponibilità abbastanza circoscritte.
Cosa ci insegnano le minacce di Killnet
Ho analizzato per Cyber Security 360 nel dettaglio come sono nate e dove stanno portando le minacce cyber di Killnet, Legion e i vari sotto gruppi dell’organizzazione pro Russia. Parlando anche sopratutto del fatto che si tratta di attacchi DDoS e che vanno analizzati prima di essere semplicemente riportati, basandosi unicamente sulle rivendicazioni del gruppo.
Nello specifico, come riportato anche nell’articolo di oggi, ho avuto modo di analizzare la lista degli indirizzi IP presi di mira come obiettivo contro l’Italia, rilevando che tra essi ci sono server che ospitano siti anche di rilevanza strategica per lo Stato: Difesa, Senato, Banca d’Italia, CSIRT e aeroporti vari.
In questo post mi voglio concentrare proprio sulla parte relativa all’elenco degli aeroporti, ignorando per un momento il resto.
In Italia abbiamo diffusi problemi di configurazione
Se gli attacchi DDoS sono rimasti semplici minacce, interessante è invece cogliere l’occasione per fare analisi su tutti questi target che di volta in volta vengono presi di mira.
Un attacco DDoS punta a rendere indisponibile un server (web, o altro), sovraccaricandolo di richieste illecite fuori norma. A quanto apprendo però, nel caso aeroporti Italia, l’indisponibilità di alcuni siti web ce la creiamo anche da soli, senza attacchi esterni.
Cosa voglio dire? Voglio porre l’attenzione sulle configurazioni dei server web che erogano il servizio. Mi concentro sugli aeroporti perché tra i target sarebbero quelli che in caso di indisponibilità diffonderebbero un danno comunitario più ampio.
Nella lista figurano 10 siti web di aeroporti italiani, di questi, 5 sono OK (da tutti i punti di vista), 1 risulta down (indisponibile veramente) e 4 sono mal configurati.
Facendo test di verifica della disponibilità, lanciando magari richieste HTTP di tipo GET, agli indirizzi target potremmo apparentemente rilevare un down di questi 4 siti. In realtà un controllo più approfondito fa capire subito che in realtà il server sta funzionando bene (non sta soffrendo di attacchi), ma il sito, in certe condizioni, risulta comunque indisponibile. Bene, questa indisponibilità se la crea l’amministrazione stessa del sito. Cioè chi l’ha configurato o chi lo mantiene.
Per l’utente finale, che presumibilmente non fa analisi prima di consultare un sito di un aeroporto italiano, risulta comunque un disservizio (anche se ovviabile). Inoltre anche in un contesto come questo, fatto di minacce, rivendicazioni e ipotesi di attacchi DDoS, queste incomprensioni non rendono la vita facile a chi deve raccontare cosa sta accadendo.
Anche il problema evidenziato da Killnet per il sito web governativo del CSIRT italiano (Computer Security Incident Response Team), non ha nulla a che fare con operazioni malevole o di hacking, ma si tratta di un semplice errore di “gestione degli errori”. Nel senso che, se si interroga il sito con una richiesta che non porta ad un effettivo contenuto presente nel database, non restituisce il classico errore 404 ma una pagina vuota. Es: https://www.csirt.gov.it/contenuti/gdfgdfgdg
Quali sono le configurazioni errate nei server web
Quattro siti web su 10 rimangono pur sempre il 40% che, se il livello si dovesse ripercuotere con questo standard anche su numeri più alti, è di sicuro una fetta importante del web perlomeno italiano.
I 4 siti sui quali ho riscontrato configurazioni errate, abbastanza gravi da rendere il sito stesso indisponibile a certe richieste, sono quelli degli aeroporti di Forlì, Pisa, Garda e Venezia (Marco Polo).
Le anomalie riscontrate sono sempre dovute a redirect errati, certificati SSL scaduti o non correttamente associati ai domini e anche il misto delle due precedenti.
- Aeroporto di Forlì: funziona perfettamente se lo si interroga con il “www” prima del dominio, ma se scriviamo il dominio senza “www” il server non è capace di reindirizzarci al sito web (indisponibile).
- Aeroporto di Pisa: sul “.it” il certificato HTTPS (SSL) è scaduto, siccome il “.com” funziona correttamente, basterebbe indirizzare tutte le richieste al “.com”. Anche qui se richiediamo il sito senza “www” il sito è indisponibile e il server non risponde.
- Aeroporti del Garda: in realtà ha una versione funzionante del sito sotto “www.aeroportoverona.it”, però non reindirizza in automatico senza il “www”.
- MarcoPoloDomani.it: dovrebbe indirizzare a “www.veneziaairport.it”, ma non lo fa perché il certificato SSL è attribuito ad altri domini (della società di gestione) che quindi non autenticano questo stesso dominio, creando disagio.
Ora quello che viene naturale suggerire è che correggere queste problematiche, richiede pochissimi minuti di configurazione lato server, ma l’impatto dei disguidi che crea, nell’utenza, è sicuramente l’aspetto più importante.
Rimane inoltre la speranza che questa percentuale (il 40%) sia un caso circoscritto a questa lista e non replichi gli stessi risultati, qualora applicate le medesime verifiche su larga scala nel web italiano (istituzionale).
