Per chi volesse capire nella pratica come avviene un attacco mirato, o APT (advanced persistent threat), una lettura utile può essere quanto è stato svelato a metà aprile in merito all’attacco ad Hacking Team.
La società milanese, nota per il software di cyber-espionage Galileo o RCS (Remote Control System), aveva subito nel luglio 2015 un data breach della dimensione di 400 gigabyte, con fuoriuscita dai server di documenti, ricevute, contratti, codice sorgente, screenshot di conversazioni email imbarazzanti tra i dipendenti della società e i clienti governativi di oltre 30 paesi. Si era temuto anche che il codice del software di spionaggio, usato da regimi dittatoriali di varie parti del mondo per monitorare dissidenti, attivisti e giornalisti, avesse potuto finire in mano ai jihadisti.
Poi, il 15 aprile di quest’anno riappare Phineas Fisher, l’hacker che a luglio aveva rivendicato l’attacco a HT: con un tweet dal profilo @GammaGroupPR rimanda a una pagina web su Pastebin dove viene spiegato per filo e per segno come è avvenuto l’attacco.
Da notare che l’account Twitter utilizzato è sempre lo stesso, sia quello con cui era stata divulgata la notizia del data breach Hacking Team, sia anche in precedenza, nell’estate 2014, utilizzato per la diffusione dei documenti di Gamma Group (un’azienda anglo-tedesca produttrice dello spyware FinFisher). Segnale evidente che dietro questo tipo di attacchi lavora un gruppo di attivisti che condanna la vendita di questi software a governi oppressivi.
Oggi, con tutti i passaggi dell’attacco di luglio svelati, viene fatto un ulteriore passo nella direzione di fornire ulteriori informazioni, rendendo queste azioni potenzialmente ancora più diffuse. Proviamo a mettere a confronto quanto sapevamo finora sugli APT con quello che viene svelato da Phineas Fisher.
Un APT è di regola un attacco che si svolge in modo silente per lunghi periodi di tempo, prendendo di mira specifiche organizzazioni, orchestrando diverse tecniche e il lavoro di più esperti. Ha la caratteristica principale di procedere mantenendo massima segretezza, senza danneggiare in alcun modo i sistemi colpiti, procedendo fino ad arrivare ad acquisire e sottrarre le informazioni più critiche e i dati di maggiore valore senza essere scoperti. Ad oggi quello che si pensava era che questo tipo di attacchi richiedessero grandi capacità, grandi gruppi di attaccanti e molte risorse economiche a disposizione. Motivo per cui finora gli APT sono stati attribuiti per lo più ad attacchi State-sponsored, ad esempio con scopo di spionaggio industriale. Invece, secondo quanto dichiarato nella guida completa fornita da Phineas Fisher, l’attacco, pur complesso, ad Hacking Team sembra essere avvenuto in tempi ridotti: “con 100 ore di lavoro, una persona può smontare anni di lavoro di un’azienda multimilionaria” avrebbe dichiarato l’hacker, anche se da quanto racconta, l’attacco ha richiesto almeno qualche mese di lavoro. Il metodo utilizzato è quello che ripercorre tutte le fasi della kill-chain classica di un APT, come da letteratura (Enisa, ETL2015): reconnaissance, weapon
isation, delivery, exploitation, installation, command and control, action on objectives.
Il life-cycle di un APT – Wikipedia
Come descritto chiaramente, l’azione è partita dai sistemi raggiungibili da Internet, che complessivamente erano: un portale di customer support, un sito web basato su Joomla CMS, alcuni router, gateway VPN e un’appliance di spam filtering. L’hacker si è concentrato sull’obiettivo più facile, ossia la ricerca di una vulnerabilità zero-day su un embedded device. Dopo 2 settimane di reverse engineering, è stato creato un remote root exploit per uno dei device esposti (router, VPN gateways o appliance anti-spam: l’hacker non ha fornito maggiori dettagli sulla vulnerabilità utilizzata perché non essendo ancora nota potrebbe essere valida per ulteriori attacchi).
Prima di attaccare Hacking Team, l’exploit, il firmware per la backdoor e altri strumenti di post-exploit sono stati testati dall’hacker su altre aziende, per essere sicuro che non generassero errori o crash dei sistemi che avrebbero potuto mettere in allarme le persone dell’azienda presa di mira.
Quindi, diciamo almeno dopo 1 mese, sarebbe iniziato il lavoro vero e proprio di intrusione nella rete della società milanese, alla ricerca di altre vulnerabilità, sistemi malamente configurati, account privilegiati scritti in chiaro. Prima sono stati individuati alcuni database MongoDB senza autenticazione (con audio file di installazioni di test del software RCS). Quindi, fatto più grave, alcuni network attached storage (NAS) utilizzati per i backup, sempre senza autenticazione. Accedendo alle virtual machine dei backup l’hacker avrebbe quindi trovato anche il Microsoft Exchange email server, e in un altro backup un Windows registry con local administrator password per un BlackBerry Enterprise Server. Entrando sempre di più in possesso di credenziali, e muovendosi nella rete usando vari tool (PowerShell, Metasploit’s Meterpreter e altre utilities open source), ma senza di fatto utilizzare malware, alla fine l’hacker è riuscito con le password degli amministratori di sistema ad aprirsi un varco fino al codice sorgente di RCS.
Considerando come si è svolto l’attacco, ossia senza destare alcun allarme, viene da chiedersi quali misure avrebbero potuto impedirlo. In gran parte, sarebbe stata necessaria una migliore detection e intelligence sull’utilizzo delle risorse interne. Un migliore monitoraggio sulle attività della rete o sull’utilizzo di account privilegiati avrebbe potuto generare degli alert che avrebbero messo in allarme il personale. D’altro canto, alcune misure di sicurezza di base, come anche un migliore patching delle vulnerabilità, una separazione delle reti e dei sistemi di backup, un più diffuso utilizzo di sistemi di autentificazione, avrebbero impedito o rallentato le attività malevole. Infine, essendo stata trafugata una gran quantità di codice, una soluzione di Data Theft o Data Loss Prevention (DTP/DLP) utilizzata per il software che costituisce il patrimonio fondamentale dell’azienda, ne avrebbe impedito o limitato fortemente il furto.
A cura di Elena Vaciago, The Innovation Group
(Articolo originale su TechWeekEurope)
