Backdoor: cosa sono, come funzionano, come difendersi

Le backdoor, nate ben prima di Internet, sono delle comode “porte di servizio” che consentono di accedere da remoto ad un sistema.

Nel tempo, però, si è iniziato ad abusare di questo utile strumento trasformandolo in una minaccia per le nostre infrastrutture critiche. Ma andiamo con ordine e scopriamo cosa sono, come funzionano ed eventualmente come difendersi dalle backdoor.

Backdoor: una lunga storia

Qualche anno fa (una trentina ed oltre o giù di lì), quando Internet era ancora di là dal diventare uno strumento disponibile a tutti, la telematica amatoriale era strutturata su BBS (Bulletin Board System) “domestiche”.

Alcune di queste erano anche collegate tra loro, in modo asincrono, in un circuito amatoriale di interscambio chiamato “Fidonet”.

In generale, comunque, chiunque fosse dotato di un computer, di un modem, di una linea telefonica e di quel minimo di abilità necessaria a configurare il sistema, poteva mettere in piedi una BBS e fornire il suo piccolo contributo alla diffusione della conoscenza.

I principali software per la gestione delle BBS disponevano già di sistemi di controllo accessi RBAC, tipicamente a 4 livelli: utente, utente privilegiato, moderatore ed infine i SysOps, che erano utenti amministratori plenipotenziari.

Però tali utenze consentivano solo di amministrare la BBS. E se fosse stato necessario intervenire sul computer? Come fare per riavviarlo da remoto, ad esempio? Alcuni decisero di introdurre una funzionalità nascosta, di solito tramite un programmino “TSR” (Terminate and Stay Resident) richiamabile con una speciale combinazione di tasti da digitare in qualsiasi momento, anche prima del login.

Questo trigger scatenava un interrupt, che “scavalcava” completamente l’autenticazione della BBS e permetteva di accedere direttamente ad una interfaccia di gestione del sistema host sottostante. Era una “porta di servizio” nascosta. Una backdoor, appunto.

In realtà le backdoor, seppur con altro nome, esistevano anche prima.

Un tempo i mainframe accettavano il login di root solamente da una particolare console telescrivente (teletypewriter), installata in una stanza a parte rispetto ai terminali “utente”, con accesso limitato e controllato.

Per poter effettuare operazioni come “root” occorreva chiedere (e spesso prenotare…) ad un responsabile l’accesso alla stanza della console teletype e digitare i comandi da lì. Le stampe immediate delle istruzioni impartite e degli output permettevano di tenere traccia di tutte le operazioni effettuate. Era impossibile operare come root senza lasciare tracce tangibili.

Ovviamente, in breve tempo vennero programmate delle funzioni specifiche, finalizzate ad “ingannare” il mainframe e far riconoscere qualsiasi terminale CRT come una telescrivente, per poter utilizzare il login di root anche da fuori della stanza protetta. Questa pratica è diventata talmente diffusa, che ancora oggi i files dei terminali di console si chiamano tty.

Backdoor “buone” e backdoor “cattive”

È evidente che non c’è nulla di intrinsecamente malevolo nell’idea di nascondere una funzionalità di gestione di emergenza a vantaggio del proprietario o del gestore del sistema.

Chiaramente, però, la cosa diventa problematica nel momento in cui la backdoor viene scoperta da qualcuno che non è colui a cui la “porta di servizio” sarebbe destinata.

Altro discorso ancora, invece, si ha se la backdoor proprio non è prevista ed è qualcun altro ad installarne una per poter prendere abusivamente il controllo del sistema. La prima backdoor di questo genere della cui esistenza si sia avuta una certa conoscenza fuori dal ristretto circuito degli addetti ai lavori fu il famigerato “Back Orifice” (BO), prodotto dallo storico collettivo hacker “Cult of the Dead Cow” (cDc).

In realtà, BO non nasceva con l’intenzione di causare danni, quanto per dimostrare la scarsa sicurezza dei sistemi Windows based. Purtroppo, la strada per l’inferno è lastricata di buone intenzioni e BO venne rapidamente “weaponizzato” in vari tipi di payloads e diffuso su decine di migliaia di sistemi online, creando di fatto la prima botnet.

Oggi come oggi uno strumento molto usato e decisamente potente è il payload meterpreter, che si integra nella suite Metasploit. Lo scopo della suite Metasploit è il penetration testing. Ma è evidente che degli attori malevoli possono utilizzarla con scopi meno nobili.

Chi c’è dietro alle backdoor?

Oggi come oggi le backdoors sono ancora molto diffuse e comunemente utilizzate, per quanto queste siano in genere regolarmente documentate e protette da sistemi di autenticazione o protocolli di attivazione specifici.

Tutti i server moderni integrano una interfaccia di rete particolare (Intelligent Platform Management Interface, IPMI) che consente l’accensione remota, lo spegnimento, la riconfigurazione dell’array e persino la visualizzazione della console locale.

Alcuni apparati di rete dispongono di una funzione di login override che consente di accedere in amministrazione al sistema dalla porta console locale mettendo in loop due o più porte di rete specifiche o tenendo premuto un tasto specifico mentre si rialimenta il sistema.

E cosa sono queste, se non delle backdoor “legittime”? Chiaramente, questi sistemi di gestione, quando non vengono opportunamente configurati (collegando le porte IPMI ad una VLAN o ad una rete specifica e cambiando le password di default, ad esempio), possono diventare un canale di accesso privilegiato per un eventuale attaccante.

Alcuni stanno sollevando (legittimamente), il dubbio che alcuni produttori di apparati di telecomunicazioni stiano nascondendo, nell’hardware o nel codice operativo dei loro device, dei sistemi di controllo remoti finalizzati allo spionaggio delle comunicazioni o al controllo delle infrastrutture critiche.

Il caso storico del chip “Clipper”, implementato dalla NSA ai tempi dell’amministrazione Clinton, ha sostanzialmente posto le basi della querelle. È il caso di dire che a giocare con il fuoco si rischia di scottarsi. Di fatto oggi gli USA accusano altri produttori di sistemi di TLC di fare la stessa cosa che essi stessi hanno voluto fare per anni.

Questo vale per le autorità governative, quanto per gli OTT ed i produttori di sistemi interconnessi, che oramai controllano quasi interamente lo sviluppo del nostro mondo sempre più digitale ed interconnesso. Le innocenti ed utili backdoor, oggi si sono trasformate in armi nella guerra digitale e rappresentano una minaccia trattata sui tavoli diplomatici delle più grandi potenze mondiali.

Ormai, il 90% dei dispositivi digitali che utilizziamo, anche i più minuti, usano un sistema operativo che può essere programmato. Le smartplug o le webcam che abbiamo in casa adottano spesso un kernel Linux. Aggiungere a tali devices delle funzioni di accesso remoto “nascoste” è concettualmente piuttosto semplice.

È ciò che accadde con la botnet Mirai. Un worm che cercava gli smart device collegati in rete con username e password di default che, quando ne trovava uno, vi accedeva ed installava un RAT (Remote Access Tool), quindi si metteva a cercare altri devices vulnerabili per diffondersi.

È di qualche giorno fa la notizia di alcuni modelli di smartphone di fascia bassa su cui è stato rilevato il trojan Triada.231. Questo trojan era stato incluso nel firmware direttamente dai produttori, assieme ad altri software apparentemente legittimi.

Non c’è modo di sapere se i produttori fossero consapevoli della cosa, perché la filiera del software è divenuta ormai talmente complessa ed articolata da rendere, se non impossibile, perlomeno estremamente difficile individuare gli attori malevoli. Non si può escludere che l’inclusione del malware sia stata determinata da una banale disattenzione in un device di test da cui poi è stato ricavato il package master per le app preload.

Questo, chiaramente, sposta l’attenzione su chiunque. Fortunatamente, però, abbiamo modo di perimetrare almeno l’elenco delle “fonti primarie”.

Innanzitutto, bisogna distinguere: un conto sono le backdoor installate dal produttore, facenti parte del sistema, ma usate abusivamente, un altro conto sono le backdoor secondarie, non previste ed installate a seguito di un exploit, un altro conto ancora sono le backdoor inserite dai produttori per altri scopi e non documentate.

Per le prime è evidente che ci si trova davanti a delle “classiche” violazioni di sicurezza, prevenibili con la buona diligenza (cambiare le password di default e segregare le reti di management, ad esempio) o con il patching dei sistemi e l’uso di sistemi IDS.

Andare a capire chi produce e diffonde malevolmente le backdoor non previste è un po’ come cercare di scoprire chi, nel supercondominio, getta l’umido nel bidone del secco. Non è impossibile, ma di fatto non ha molto senso farlo, perlomeno non al di fuori di una indagine penale.

Invece, nel caso di backdoor introdotte dai produttori dei sistemi ci si trova alternativamente davanti ai classici “easter eggs” oppure a qualcosa di ben più grave e di vasta portata. Perché significa che i devices che stiamo utilizzando sono in realtà dei componenti asserviti ad interessi e strategie di potenze ostili.

Quali possano essere queste potenze ostili, dopotutto è un mero esercizio di “listing” dei paesi e delle compagnie che producono la maggior parte dei software e dei devices. Bisogna quindi farsene una ragione, e partire dal presupposto che le backdoor possono essere presenti ovunque.

Come funzionano e come difenderci

Prima di tutto, cerchiamo di dare una definizione univoca di backdoor. Qualsiasi sistema o meccanismo di accesso può essere una backdoor, ma sono veramente delle backdoor quei sistemi, software o hardware, che consentono un accesso privilegiato a dati o sistemi senza passare il vaglio del controllo accessi “standard”.

Una backdoor, per manifestarsi, necessita di un “trigger”, ossia di una specifica azione che la attiva. Questo trigger può essere di due tipi: locale o remoto. Nel primo caso, la backdoor può essere attivata solo quando si ha fisicamente accesso al dispositivo.

È il classico reset button di molti devices, oppure una particolare combinazione di tasti da premere per resettare la password di amministrazione quando connessi direttamente alla console del dispositivo. Il trigger remoto invece è accessibile da qualsiasi punto di accesso al sistema.

Può essere un “magic packet” indirizzato ad una porta TCP specifica, un comando di wake up interno ad un software pubblicato o una particolare funzione “nascosta” e non raggiungibile dall’interno dei servizi offerti.

Considerando sempre che il giusto livelli di sicurezza da applicare ai sistemi è quello necessario e sufficiente a garantire il livello di sicurezza che si desidera ottenere, difendersi dall’abuso delle backdoor è possibile. Basta applicare l’antica filosofia di design “Trust No One”. Ecco un semplice decalogo di buon senso.

1. Cambiare le password di default. La maggior parte delle violazioni dei sistemi condotte tramite backdoor, è avvenuto perché venivano usate password deboli o di default. Esistono centinaia di database online che riportano tutte e credenziali di default dei principali apparati. Moltissimi router domestici usano ancora, come password di default della rete wireless, una chiave prodotta a partire dall’ID del dispositivo (MAC Address, BSSID o altro seriale disponibile nell’etere) con algoritmi noti. Esistono addirittura delle app che consentono, semplicemente “sniffando” le reti, di comprendere il tipo e modello di Access Point e restituiscono la password di default di quella particolare rete.
2. Applicare pedissequamente il principio di minimum access, segregando il più possibile i network ed i flussi dati in maniera tale da avere il traffico di management esclusivamente su una rete dedicata e strettamente sorvegliata. Se vedo traffico IPMI su una rete destinata al traffico standard, di certo c’è un problema. Viceversa, se trovo traffico sulla rete di management destinata a servizi differenti da quelli di gestione, la probabilità diventa una quasi certezza.
3. Non possiamo fidarci pienamente di nessun device o software che non abbiamo programmato o realizzato noi. Ed anche in questo caso, dobbiamo diffidare dei componenti, per cui diventa fondamentale sfruttare il periodo di test per auditare il sistema e cercare di verificarne il funzionamento nei dettagli.
4. I sistemi IDS/IPS tradizionali difficilmente riescono ad individuare delle backdoor, mentre i sistemi avanzati di network behavior analysis possono al contrario esserci di estremo aiuto, evidenziando le connessioni inusuali da o verso indirizzi che non dovrebbero parlarsi.
5. Un PC di un utente che effettuasse traffico HTTPS verso un server web non dovrebbe destare preoccupazioni particolari. Uno switch di rete che facesse lo stesso traffico invece ci dovrebbe far alzare il sopracciglio.
6. Se la rete telefonica che usate è analogica, separate gli armadi per la fonia dagli armadi dati e chiudete a chiave gli armadi. Ancora oggi, nella maggior parte delle aziende dotate di cablaggio strutturato e fonia analogica, la rete dati e la rete voce sono attestate sugli stessi patch panel. Questo costringe a lasciare gli armadi accessibili a tutto il personale di supporto per poter consentire lo spostamento degli interni da una postazione ad un’altra anche senza l’intervento dell’IT. Tutto ciò, non solo finisce con il generare i classici armadi “spaghetti network” che rendono il debug della rete un inferno, ma soprattutto semplifica la vita di chi volesse collegare sistemi di intercettazione. E questo porta inoltre al punto successivo.
7. È notizia di pochi giorni fa che la NASA è stata violata per mezzo di un Raspberry Pi collegato abusivamente al network. Un microcomputer da 35€ ha consentito la sottrazione di centinaia di GB di dati confidenziali dal network del Jet Propulsion Laboratory. Tutto ciò non sarebbe stato possibile se nella rete in questione fossero state implementate misure di machine authentication come l’802.1x o altri sistemi NAC.
8. Quando si parla di software, l’open source spesso ci fornisce qualche garanzia in più: il codice aperto rende sostanzialmente impossibile nascondere funzioni non rilevabili, ed in ogni caso è sempre possibile confrontare il codice dei componenti open source con una fonte “pura”. Questo rende le operazioni di “static code review” estremamente più efficaci nel rilevare eventuali “aggiunte” non richieste.
9. Se proprio occorre usare strumenti “closed source”, dato che in questi casi il reverse engineering è generalmente proibito, ricordarsi che tali software devono riportare nel dettaglio le specifiche di funzionamento, e pertanto qualsiasi deviazione da quanto richiesto ed acquistato comporta una violazione degli obblighi del produttore. Questo include anche tutte le funzionalità di accesso remoto o di aggiornamento automatico delle release del software. E comunque nessun fornitore serio rifiuterebbe di sottoporre il proprio sistema ad un audit o ad un penetration test.
10. Cifrare il più possibile i dati, anche e soprattutto a livello file. Abbiamo visto che adottare le password più robuste del mondo è sostanzialmente inutile quando si può accedere ai sistemi o ai dati tramite una backdoor. È però altrettanto vero che difficilmente una backdoor integra una funzione di override o di decodifica dei dati cifrati tramite un software terzo rispetto al sistema. Le funzioni di disk encryption sono generalmente studiate per proteggere i dati dalla lettura dal di fuori del sistema su cui son stati cifrati. Ma è evidente che, se si può accedere da remoto alla console di un server, i dati saranno visibili in chiaro. Sapere che anche una eventuale esfiltrazione di dati a livello file non comporta una (facile) violazione della loro confidenzialità è decisamente un plus da tenere in seria considerazione. Soprattutto quando i dati sono memorizzati nel cloud.