#143 – Hanno violato Sophos

Si sono portati via un po' di dati dai firewall Sophos ad aprile 2020, facendo un attacco SQL Injection. Come si fa questo tipo di attacco? E soprattutto, come posso difendermi (se è un bug, non troppo, in effetti)

Pillole di Bit (https://www.pilloledib.it/) è un podcast indipendente realizzato da Francesco Tucci, se vuoi metterti con contatto con me puoi scegliere tra diverse piattaforme: - Telegram (o anche solo il canale dedicato solo ai commenti delle puntate) - TikTok (per ora è un esperimento) - Twitter - BlueSky - Il mio blog personale ilTucci.com - Il mio canale telegram personale Le Cose - Mastodon personale - Mastodon del podcast - la mail (se mi vuoi scrivere in modo diretto e vuoi avere più spazio per il tuo messaggio) Rispondo sempre Se questo podcast ti piace, puoi contribuire alla sue realizzazione! Con una donazione diretta: - Singola con Satispay - Singola o ricorrente con Paypal Usando i link sponsorizzati - Con un acquisto su Amazon (accedi a questo link e metti le cose che vuoi nel carrello) - Attivando uno dei servizi di Ehiweb Se hai donato più di 5€ ricordati di compilare il form per ricevere i gadget!

Il sito è gentilmente hostato da ThirdEye (scrivete a domini AT thirdeye.it), un ottimo servizio che vi consiglio caldamente e il podcast è montato con gioia con PODucer, un software per Mac di Alex Raccuglia

Ciao a tutti e bentornati all’ascolto di Pillole di Bit, questa è la puntata 143 e io sono, come sempre, Francesco. La puntata scorsa abbiamo parlato di un attacco informatico a un sito o a un servizio, che mira a abbatterlo, in modo che non possa più erogare il suo servizio. Un giorno parleremo del non attacco subito dal sito INPS il primo aprile 2020. Esatto, il NON attacco. Esistono degli altri tipi di attacchi, che sono più subdoli e spesso non te ne accorgi, oppure quando te ne accorgi è già troppo tardi. Questo ve lo racconto perché è iniziato tutto con una mail del 25 aprile mattina sulla casella del lavoro. Partiamo dalla parte tecnica, perché non è banale da raccontare, mettetevi comodi. In genere, in un sito web, quando ci sono delle caselle da compilare, quando si preme il pulsante di invio dati, i dati di queste caselle vengono usati per comporre una query che farà qualcosa all’interno del DB sul quale lavora il sito. Un esempio banale è l’accesso. Voi inserite utente e password e fate click su INVIA. Nel tempo che passa dal click a quando vedete la pagina riservata succede più o meno questo i due campi vengono controllati, in modo che non siano scritti male, quindi che non siano vuoti, che non ci siano caratteri strani e che non ci siano scritte cose che potrebbero mandare a pallino la query che viene eseguita. Vengono anche aggiunti i cosiddetti caratteri di escape, che permettono alla query di essere eseguita correttamente. Ad esempio, se nell’utente c’è un apostrofo e lo stesso apostrofo viene usato per costruire la query, delimitando un campo di testo, questo viene modificato in modo da dire alla query “guarda che non è un delimitatore di testo, ma un apostrofo nel testo” Poi la password viene elaborata e ne viene estratto l’hash, che dovrà essere controllato con quello salvato sul DB. Ok, il solito passo indietro. Nei DB dove ci sono utenti e password, nel campo della tabella relativi alla password non viene salvata la password in chiaro, per ovvi motivi di sicurezza: chiunque abbia accesso a quel DB conoscerebbe le password di tutti, che questo sia il DB admin del sistema o un attaccante. Per evitare questa cosa bruttissima, di solito si fa un’operazione matematica, detta hash, che codifica la password in una stringa che non ci assomiglia neanche un po’, che è univoca per quella password e non può essere la stessa per due password diverse e dalla quale non si può tornare indietro e risalire alla password. Per maggior sicurezza, si aggiunge alla password un testo aggiuntivo, detto salt, e si codifica la password con il salt. Quando scelgo la mia password la procedura che fa il sistema è: aggiungo il salt ne faccio l’hash la salvo nel DB Torniamo alla nostra autenticazione. Abbiamo inserito la password e il sito, preso il testo in chiaro della password, aggiunge il salt e ne fa l’hash, a questo punto confronta l’hash con quello che ha nel DB, se l’hash è lo stesso, la password inserita è quella corretta e viene garantito l’accesso. In linguaggio SQL si esegue una query che dice “senti, verifica se a questa password corrisponde questo hash”. La query viene creata con i dati che io inserisco nelle due caselle. Ma se io inserisco nelle due caselle un testo particolare, che non viene sanificato, posso far fare al sistema una query che voglio io e non la query che è stata progettata. Questo tipo di attacco si chiama di SQL injection. Se io nel campo dell’utente scrivo un testo ben pensato, che via podcast è un casino da spiegare, ma fidatevi, posso passare al server una query diversa da quella che il programmatore si aspettava di eseguire. Posso far fallire la query principale mettendo un commento, seguito da un punto e virgola, che identifica la fine di una query e poi accodare una mia query. Se nella query che accodo metto una “select * from utenti”, al posto di fare accesso al sistema, avrà una pagina che mi restituisce un errore se la tabella utenti non c’è, oppure tutta la tabella utenti completa se questa esiste. Posso aggiungere un bellissimo “DROP Database”, così distruggo tutto, oppure, identificato l’utente amministratore posso fare un update, aggiornare la password e metterla a blank, così che posso poi fare l’accesso come amministratore in tutta tranquillità. Questo tipo di attacco è noto da molti anni e ormai tutti sanno come mitigarlo, si studia anche all’università, io ho passato l’esame di programmazione web e ho dovuto fare un sistema protetto dalle SQL injection. Il firewall del cliente che citavo all'inizio del podcast aveva un bug, questo bug ha permesso ad attaccanti, al momento ignoti, di bucarlo, nel senso di entrare e di farci cose. L’attacco è stato proprio di SQL injection, se no che vi facevo a fare lo spiegone per metà puntata? Questo tipo di attacco è iniziato il 20 aprile 2020 e la mail che mi è arrivata dal supporto di Sophos è del 25 aprile 2020 in prima mattina. Il testo era sostanzialmente questo: “ciao, abbiamo scoperto una vulnerabilità nel firewall, l’abbiamo sistemata, ma visto che il tuo firewall è stato compromesso, è necessario che tu faccia alcune azioni urgenti” Visto che sono entrati e si sono portati via il DB degli utenti, compresi gli hash delle password, l’attività da fare è stata quella di cambiare tutte le password e comunicarle agli utenti che le utilizzavano per collegarsi in VPN. Qui risulta palese perché è necessario che le password siano salvate come hash. Se ho la password in chiaro, estratta dal DB, entro nel firewall come un utente qualsiasi o, peggio amministratore, e inizio a fare cose poco simpatiche all’interno della rete aziendale. Un po’ come se un nemico riuscisse a trovare una grata chiusa male nelle mura di un castello, entra e inizia ad ammazzare la gente o a fare altri danni. Se ho l’hash, non lo posso mettere come password, nel campo password, perché ne verrebbe fatto l'hash e questo sarebbe diverso da quello di partenza, memorizzato nel DB e quindi non funzionerebbe. Quello che potrei fare è andare a controllare in determinati enormi archivi se quell’hash è già stato trafugato e si sa a che password appartiene. Per questo motivo è importante non riutilizzare la stessa password per più servizi diversi. Se ne bucano uno e scoprono la password relativa a quell’hash, potrebbero bucarne un secondo, verificare che l’hash è lo stesso e usare la password per accedere. Per sistemare il problema ci ho messo una giornata a creare le password, resettarle e comunicarle ai vari utenti, mi è andata bene perché Sophos, con il quale ho un contratto di assistenza, tiene sotto controllo i dispositivi e li aggiorna senza chiedertelo prima, in caso di problemi gravi come questo, dove pochi minuti possono fare la differenza. Pago un contratto, anzi, lo paga un cliente, e questi soldi sono tutti ben spesi. I dispositivi vanno sempre aggiornati, non dimenticatelo mai. Da questa puntata potete portarvi via un po’ di informazioni importanti, ve le elenco, per semplicità. non si deve mai usare la stessa password per più servizi se un servizio, quando fate click su “password dimenticata”, vi restituisce la vostra vecchia password in chiaro, scappate a gambe levate se usate un firewall di una marca nota e ce lo avete con IP pubblico esposto su internet, aggiornatelo sempre, ma proprio sempre, se non avete un contratto attivo e non potete aggiornarlo più, cambiatelo non pensate mai che la vostra rete non interessa a nessuno, e quindi nessuno sarà interessato ad attaccarvi. E’ una bugia bella e buona I contatti - 1 Tutti i contatti, i link e le informazioni su questo podcast li trovate sul sito www.pilloledib.it, il link diretto alla puntata è www.pilloledib.it/podcast/143      Potete contattarmi in un sacco di modi diversi: gli account twitter @pilloledibit e @cesco_78 la mail [email protected] il gruppo telegram www.pilloledib.it/telegram     Il form sul sito Rispondo a tutti e sono attivo nel gruppo di discussione Se volete partecipare attivamente al podcast, trovate sul sito i link per le donazioni, ci sono molte piattaforme e modalità, scegliete quella che vi piace di più. Se donate almeno 5€ compilate il form con i vostri dati e vi spedisco gli adesivi a casa. Ringrazio tantissimo chi sta partecipando, chi ha partecipato e chi sta pensando di farlo. Alcune piccole novità, tranquilli, non vi rubo troppo tempo. Ho deciso di rimuovere le pubblicità dal podcast, ma lo farò appena il budget raggiungerà la soglia minima per il pagamento, mancano meno di due €, una volta raggiunta le tolgo. A voi danno fastidio e a me portano talmente poco che non ne vale la pena. Visto che non vi tediano più, potreste pensare a una donazione, se non l’avete mai fatta. Ogni tanto mi arrivano delle richieste di consulenza su argomenti più o meno tecnici, ho la Partita IVA, posso farli e fatturarli, se vi interessa, vi lascio il link della mia pagina professionale, così che possiate andare a vedere cosa faccio e quanto costo Ultima, poi la smetto, ho attivato la pagina degli sponsor sul podcast, quindi se avete un’azienda, un prodotto, un servizio, che vi andrebbe di promuovere tra il migliaio di ascoltatori del podcast, andate su pilloledib.it/sponsor e trovate tutte le informazioni. Il tip Abbiamo parlato di sicurezza delle password e di chi le ruba e le riutilizza. Il problema è che le password vengono rubate quasi quotidianamente e i servizi ai quali siamo iscritti sono decine e decine, come si fa a stare dietro a tutto? Semplice, ci si iscrive a un servizio che controlla le fughe di password e ci avvisa. Il sito, impronunciabile, lo trovate nelle note dell’episodio come al solito. Insomma, sì, state a casa, ma anche state sicuri online Bene è proprio tutto, non mi resta che salutarvi e darvi appuntamento alla prossima puntata. Ciao!