​

​Sicuramente non è il cappello, quello è di Red Hat. E non è la giubba, quella la mettono i Canadesi a cavallo. E nemmeno la camicia, quella è riservata a Garibaldi. Quindi quelli del red team noi li immaginiamo coi calzini rossi. Ci pare più appropriato dei pantaloni, che sarebbero troppo cospicui e quindi inadatti ad un lavoro dove l'importante è non farsi notare… Dice Wikipedia che la tradizione di identificare i cattivi come i rossi (red team) è iniziata in Prussia, dove i rossi erano gli avversari nelle esercitazioni militari.

Poi evidentemente la tradizione si è diffusa e ora, a quanto pare, l'esercito americano nelle esercitazioni usa sempre il blu per i buoni e il rosso per i cattivi. Però forse più che buoni e cattivi (che non è politicamente corretto) dovremmo dire i difensori e gli at­tac­can­ti? Ma qui siamo ignoranti, forse i blu ogni tanto attaccano?

Fatto sta che questa cosa dei blu e dei rossi si è propagata pure all'informatica, per cui anche noi informatici abbiamo il red team, che sono dei finti cattivi (cioè sono dei buoni che fanno finta di essere cattivi). Il red team cerca di entrare nella rete di qualcuno, con l'intento di esporre le eventuali debolezze. A difendere il forte (la rete) ci sta il blue team, che all'inizio alza le barricate (i firewall ecc.) e poi aspetta che scatti qualche allarme, per poter strillare "BECCATI!" e a quel punto il gioco finisce. O forse finisce quando i blu rubano i calzini ai rossi?

Non molto tempo fa il CISA (Cybersecurity and Infrastucture Security Agency) ha condotto un'esercitazione con un red team che ha attaccato una "grande or­ga­niz­za­zio­ne infrastrutturale critica". Non ne sapremmo niente, se non fosse stato pubblicato un bellissimo documento che sintetizza (in 28 pagine) quello che hanno fatto, e quel poco che non sono riusciti a fare.

Se avete la voglia, e il tempo da investire, il documento lo trovate qui. È molto in­te­res­san­te e istruttivo e dovrebbe essere lettura obbligatoria per chiunque voglia occuparsi di sicurezza informatica. Se non ne avete il tempo, o la voglia, potete andare avanti a leggere. Proveremo a raccontare alcune delle cose che più ci hanno colpito.

Partiamo da una prima considerazione: l'organizzazione oggetto dell'esercizio in teoria era molto al sicuro. E il red team è entrato, ha girato in giro per 63 giorni, avrebbe potuto combinare guai e rubare tutto il rubabile. E i blu non si sono accorti di nulla, nemmeno quando i rossi hanno deliberatamente provato a far scattare qualche al­lar­me. Diamo per scontato che i blu non fossero informati dell'esercizio, altrimenti certe cose non si spiegherebbero. Probabilmente la cosa è stata concordata con alcuni dirigenti ("certain personnel at the organization") ma l'organizzazione era in gran parte all'oscuro dell'esercizio. 

Come sono entrati?
Questo è interessante. Hanno provato ad entrare nel modo più ovvio, cercando de­bo­lez­ze nei numerosi server accessibili da Internet, ma tutto era fatto a dovere e i firewall li hanno tenuti fuori. Sono quindi andati su linkedin a cercare persone che lavorassero nell'IT, e hanno "indovinato" i loro indirizzi mail. Il che non è difficile visto che tutte le organizzazioni hanno un qualche standard per assegnarli (tipo nome.cognome, o qualcosa di simile).
A questo punto hanno montato un attacco di spear phishing (phishing mirato) che alla fine gli ha fruttato le credenziali di due tecnici. E MFA non li ha fermati, o forse non c'era.

I movimenti laterali
Una volta all'interno i rossi hanno trovato un server Sharepoint¹ con una configurazione che consentiva di identificare gli amministratori, e dove diversi utenti avevano accesso amministrativo. Hanno quindi iniziato un secondo attacco di spear phishing su questi ultimi e sono riusciti a piazzare un pacchetto spyware sulla workstation di uno di loro. A questo punto avevano accesso persistente all'interno della rete e a un server.
Un secondo server (questo era un System Center Configuration Manager) è stato poi usato per consentire ai rossi di guadagnarsi accessi amministrativi su altri server e workstation, arrivando ad accedere a 5 siti separati della wan. A questo punto per i rossi è diventata una strada in discesa, si sono allargati ovunque, incluse le aree più con­trol­la­te della rete, usando i domain controller come veicolo per trapassare i firewall.

Il documento del CISA racconta tutto questo con un certo dettaglio, spesso molto tecnico. Forse il tecnicismo non aiuta, ma è utile sapere cosa avrebbero potuto fare i blu per evitare la figuraccia.

Ecco quindi alcune lezioni che vale la pena di tenere presente.

Se entrano, sei finito: certo, non tutti avranno l'onore di essere attaccati da hacker di questo calibro, ma sicuramente hacker così esistono. Il dettaglio di come sono entrati forse non è importante. e sicuramente i blu avrebbero potuto fare meglio, molto meglio. Ma la verità è che facevano già molto meglio dell'azienda tipo. Purtroppo, se un utente cade in una mail di phishing, e si fa installare un malware sul pc, non ci sarà difesa efficace. Morale: non fare click nei link delle mail².
Cosa fare: formazione, MFA (che non è perfetto ma fa tantissima differenza), non usare account condivisi, prendere molto sul serio la protezione delle identità.

Se hai strumenti di controllo usali. Se non li hai mettili, e poi usali. Metterli è facile, lo hanno fatto in tanti, spesso per proteggere più il fondoschiena che la rete. Usarli, molto meno. Tante volte gli strumenti ci sono ma non vengono usati, o vengono ignorati. Qui, ad esempio, a un certo punto i rossi sono stati beccati da un antivirus, che ha generato un alert e rimosso il software malevolo. E i blu che hanno fatto? Assolutamente niente. Perché? Probabilmente perché ricevevano di frequente allarmi simili e avevano imparato a ignorarli. I sistemi di controllo non devono fare rumore inutile, questo è fondamentale. E se gli allarmi sono frequenti non vanno spenti, vanno risolti!

Limitare le autorizzazioni al minimo indispensabile. Col passare del tempo gli utenti guadagnano autorizzazioni, ma raramente le perdono. È naturale che succeda ma è pericoloso. Più limitiamo quello che possono fare meglio è, non per mancanza di fiducia, non è detto che l'utente debba necessariamente essere lui a sbagliare. Lo stesso vale per gli account di servizio, quelli sono più pericolosi di altri, perché non hanno MFA.

Non mischiare utenze privilegiate e utenze normali. Se un utente ha bisogno di ac­ces­so amministrativo ad uno specifico server ok, Ma non dobbiamo usare la sua utenza standard, deve averne una separata, privilegiata, da usare solo per accedere come amministratore e solo quando necessario.

Occhio alle configurazioni di default. Sono le più semplici, non le più sicure. I rossi non hanno mai sfruttato buchi di macchine non aggiornate, ma buchi lasciati lì per errori di configurazione. Certo, se non si aggiornano i sistemi è peggio, ma aggiornarli non è tutto, occorre attivamente metterli in sicurezza.

Implementare restrizioni sul software consentito. Gli antivirus / antimalware pro­teg­go­no fino a un certo punto. Limitare via Software Restriction Policies o qualcosa di analogo, quali software possono essere eseguiti, indipendentemente dal riconoscerli come malware, può essere di grande aiuto.

Non far scadere le password, e fare attenzione a come si impostano le password di utenti privilegiati. Qui il problema è che, per riuscire a ricordarle, le persone tendono ad usare varianti della stessa password, col risultato che queste diventano predicibili. E utenti che hanno due account, uno standard e uno privilegiato, usano la stessa password o password simili per entrambi. Meglio rendere più facile la vita all'utente, non facendole scadere con regolarità. Forzeremo l'aggiornamento se abbiamo ragione di pensare che quell'account possa essere compromesso.

Limitare il traffico in uscita. Si è portati a pensare che il traffico che entra sia quello pericoloso, mentre quello uscente sia necessariamente innocuo. Non è così. Gran parte dei meccanismi di propagazione prevedono che sia la macchina infetta che contatta il padrone (cattivo) non viceversa. Perché si sa che il viceversa è bloccato, o sem­pli­ce­men­te è impossibile perché la macchina non ha ip pubblico. Quindi, un server non deve poter contattare l'esterno, a meno che sia assolutamente necessario, e se è necessario deve poterlo fare solo sui canali / protocolli previsti.

Queste sono alcune delle azioni che secondo il CISA avrebbero mitigato o eliminato gran parte delle debolezze sfruttate nell'attacco.. Ce ne sono altre che non hanno carattere generale, oppure che sono troppo tecniche per poter essere discusse qui.

Ma la lezione più importante, come sempre, è che non è mai il caso di sentirsi al sicuro...

----------------------------------------------------------------------------------------

(1) In realtà il fatto che si tratti di un server Sharepoint è incidentale, la debolezza era nella configurazione di Windows, e Sharepoint non ha mai avuto un ruolo. Ma è rilevante il fatto che utenti "normali" avessero accesso amministrativo sul server, verosimilmente perché erano amministratori di Sharepoint (ma le due cose non necessariamente vanno insieme)

(2) In questo caso nel secondo attacco di phishing i rossi hanno convinto un utente ad accettare un appuntamento, e gli hanno mandato un falso invito. Nell'accettare l'invito l'utente ha in realtà eseguito il malware. Qualcosa di molto meno evidente di un link su una mail di spam. Un'altra lezione da imparare è che l'interlocutore "informatico" potrebbe non essere quello che sembra. I social su questo ci hanno già insegnato tutto…