Un vademecum è utile solo se ha la stessa forma della cosa che descrive. Un elenco di comandi non serve a niente se non sai in che ordine usarli e perché quel passo viene prima di quell'altro.
Quello che segue ha tre parti: l'ordine con cui si guarda un sistema, le regole che valgono sempre, e la storia di chi ha aperto le strade.
Tutto quello che descrivi vale per sistemi e reti su cui hai un'autorizzazione scritta. Senza contratto non è ricerca: in Italia si configura come intrusione informatica aggravata (art. 615-ter c.p.). Il vademecum presuppone l'autorizzazione, non la sostituisce.
Parte 1: l'ordine con cui si guarda un sistema
Il mestiere ha una regola che non è una preferenza stilistica: non si toca niente finché non si sa con certezza che cosa si sta toccando. Un assessment che lascia il bersaglio in stato incoerente non è un assessment, è un disservizio con un report in allegato.
1. Autorizzazione, prima di tutto
Non è un adempimento, è il primo deliverable. Per iscritto, con:
- gli IP o i domini esatti, uno per uno, non "la rete del cliente";
- la finestra temporale, con fuso orario;
che cosa è permesso e che cosa è vietato (dDoS, social engineering, accesso a dati reali, persistenza);
- il canale per il fermo immediato e il nome di chi risponde.
Il motivo è pratico prima che legale: se durante il test esce un allarme, la prima domanda che faranno è "era previsto?". Senza documento, la risposta non esiste e il lavoro si chiude lì. Con il documento, la risposta è "sì, questo era previsto" e la giornata continua.
Conservala per un anno dopo la fine del rapporto. È la difesa che ti serve quando il cliente cambia idea su che cosa era "accettabile".
2. Ricognizione passiva prima di quella attiva
Comincia da ciò che il bersaglio dice pubblicamente di sé: nomi, DNS, certificati, header, cosa risulta dai motori di ricerca, repository pubblici, foto di schermate con versioni visibili.
Questa fase non lascia tracce ed è quella che ti fa risparmiare il tempo più prezioso di tutti. In un assessment reale buona parte delle informazioni decisive arriva prima di toccare una macchina, e più spesso da un essere umano.
3. Mappa, non attacco
A questo punto fai due elenchi separati e tienili separati:
- quello che c'è: servizi, porte, versioni, host;
- quello che è vulnerabile: solo ciò che hai verificato, con la prova.
La confusione fra i due è l'errore più comune e il più costoso del mestiere. Un report che presenta una scansione come un vulnerability assessment non vale nulla in giudizio e non serve al cliente.
4. Verifica prima di scrivere
Per ogni potenziale problema, prima di metterlo nel report:
- riproducilo tu, da zero, con gli strumenti tuoi;
verifica che sia davvero sfruttabile nel contesto del cliente, non in teoria;
misura l'impatto reale: cosa ci guadagna un attaccante, e cosa deve ancora fare dopo.
Una vulnerabilità che non si sfrutta in condizioni reali è un potenziale teorico. Si scrive, si etichetta come tale, e non si gonfia.
5. Il tipo conta, e va detto
Non tutte le vulnerabilità hanno lo stesso peso. Il CVSS aiuta a ordinare, ma non dice niente sull'impatto nel contesto del cliente:
una RCE su un server esposto, con credenziali di default: critica, e spesso la cosa che il cliente deve correggere oggi;
una SQL injection che restituisce una tabella di nomi: alta, e non è automatica una criticità;
una configurazione TLS debole su un servizio interno non raggiungibile dall'esterno: bassa, e va detto perché è bassa.
Il cliente non vuole un punteggio, vuole sapere che cosa fare lunedì mattina. È il lavoro tuo, non del tool.
6. Non lasciare residui
Ogni cosa che tocchi deve tornare come era. File scaricati, account creati, servizi avviati, log modificati. Se per un errore hai aperto una sessione persistente su una macchina del cliente, il primo atto è dirglielo, non rimediare in silenzio.
Questo è il punto in cui la qualità di un professionista si vede davvero, e non la durata del rapporto.
Parte 2: le regole che non si negoziano
Sono poche, e sono quelle che valgono in ogni contesto, anche quando nessuno ti guarda.
Fuori dai conti, sempre. Le credenziali che trovi sono del cliente e sono un finding, non un bottino. Non finiscono in un file, non finiscono in una chat, non finiscono in un repository.
I segreti trovati vanno ruotati. Una password scoperta durante un test non è più un segreto: è una vulnerabilità pubblica da quel momento. Ruotarla fa parte del lavoro, non è un favore.
Non esagerare la dimostrazione. Non serve a prendere possesso di un server per provare che si può. Il minimo che dimostra il punto è quello giusto; il resto è distruzione con una scusa.
Non pubblicare il dettaglio prima che sia corretto. Un exploit funzionante su un sito ancora vulnerabile è un danno, non una ricerca.
Non distruggere la prova. I log che cancelli sono la prova della tua attività. Tornerai su quel sistema fra un anno e ti servirà ricordare che cosa avevi toccato.
Parte 3: chi ha aperto le strade, e perché
Qui la parte interessante. La domanda "perché lo erano" ha quasi sempre la stessa risposta: perché il sistema era nuovo e nessuno lo stava guardando, e perché avevano accesso alle macchine e al tempo per guardarlo.
Il gruppo del modellino ferroviario, MIT 1960
La cultura hacker non nasce nel 1980 e non nasce con le reti. Nasce al Tech Model Railroad Club del MIT, e si sposta subito nell'Artificial Intelligence Laboratory dello stesso istituto. L'oggetto erano trenini elettrici e calcolatori, ma la postura era già quella giusta: capire come funziona una cosa per poterla usare meglio.
I due gesti diventati leggendari non erano attacchi a nessuno: avevano una volante della polizia di campus sul tetto della Cupola, e la Cupola era stata trasformata in R2-D2. Il punto è che non c'era un nemico. Erano studenti con accesso legittimo a macchine loro, e il divertimento era capire, non rompere.
Quella distinzione è ancora quella che conta. Chi all'epoca agiva in modo da essere chiamato cracker era un'altra categoria, e chi oggi usa "hacker" per i due è un imprecisione che conviene segnalare quando la si sente.
Ken Thompson e Dennis Ritchie, 1969
Bell Labs, dopo che AT&T si ritira da Multics perché il progetto era troppo complesso. loro fanno la versione piccola: un sistema single-user, che chiamano Unics — uno Multics — e che diventerà Unix.
Il motivo per cui sono nomi da vademecum è che hanno scelto la via che rendeva il sistema leggibile e portable. Nel 1973 Ritchie riscrive il kernel in C, il linguaggio che lui e Brian Kernighan stavano costruendo per rimpiazzare l'assembly: da lì Unix si porta su macchine diverse con modifiche minime. L'idea che tutto sia un file e che i programmi siano piccoli e combinabili è un'eredità che Linux, macOS e Android portano ancora.
Non hanno "attaccato" niente. Hanno costruito meglio.
Gary Kildall, 1974
CP/M, il primo sistema operativo per microcomputer di larga diffusione, scritto da una persona sola per l'Intel 8080. Da CP/M vengono le lettere di drive di Windows, il termine BIOS, le estensioni a tre caratteri, e i nomi riservati come CON e NUL che ancora oggi Windows non ti lascia usare come nomi di file.
È un nome da vademecum per un motivo preciso: ha reso portabile il software su hardware che non esisteva ancora. È la stessa lezione di Ritchie, dieci anni prima.
I phone phreak e John Draper, 1969-1971
Prima che esistessero i computer personali c'era la telefonia. La rete AT&T segnalava lo stato delle linee con un tono a 2600 Hz inviato in banda, cioè dentro la stessa linea che trasmetteva la voce: chi emettesse quel tono al momento giusto otteneva il controllo della chiamata. Non serviva nessuna vulnerabilità: bastava parlare la lingua del sistema.
Lo sguardo in generale era la morale: non cercare di penetrare, cerca di capire. Il gruppo di Draper usava registratori a nastro e un organo Farfisa per riprodurre i toni, e faceva chiamate interurbane gratis per capire come funzionava la rete.
Nel 1971 Esquire pubblica un articolo di Ron Rosenbaum, Secrets of the Little Blue Box. Ecco il punto in cui la cultura si incontra l'industria: Steve Wozniak legge l'articolo, trova Draper, e i due costruiscono il blue box. Jobs e Woz lo vendono porta a porta all'università. Jobs dirà poi che senza i blue box non ci sarebbe stato Apple. Draper finirà assunto da Apple.
È la ragione per cui i blue box sono nella storia di questo mestiere: non perché fossero un attacco furbo, ma perché erano il modo più onesto di imparare una rete.
Richard Stallman, dal 1983
Di Stallman si parla a lungo in Open source: perché conviene al software a pagamento e lì c'è la data e il motivo. Qui conta un altro punto: la definizione di hacker che dà, e che non riguarda il crimine ma la curiosità come metodo di lavoro. Un hacker è chi si diverte a esplorare i limiti di un sistema programmabile, e non chi vuole distruggere.
Kevin Mitnick, 1963-2023
Il nome che i media usano per "hacker" è anche il primo grande equivoco del mestiere. Mitnick non ha progettato un attacco: ha capito come funzionava la telefonia, e ci è arrivato con l'ingegneria sociale più che con la tecnica. Nella sua testimonianza al Congresso del 1995 descrive di aver ottenuto accesso a sistemi dell'IRS e della Social Security Administration senza mai toccare un computer: telefonate a impiegati, con il gergo giusto, facendosi passare per un collega con problemi.
Arrestato nel 1995, cinque anni di carcere, un patteggiamento nel 1999, scarico nel 2000. È morto nel 2023.
I due fatti da ricordare non sono la prigione: sono che il suo metodo principale era convincere le persone, e che alla fine è diventato consulente di sicurezza. È la prova che la stessa capacità, usata dentro le regole, produce un professionista.
La distinzione che regge
Tutte queste storie hanno un elemento in comune, ed è più importante della cronologia.
La differenza che vale, e che regge meglio delle etichette white hat / black hat, è fra chi capisce e non ha ancora deciso e chi ha deciso. Le etichette sono comode e imprecise; il bisogno di capire è comune a tutti, e la decisione è ciò che cambia.
Ed è per questo che il vademecum ha questa forma. Non sono trenta comandi da memorizzare: sono quattro fasi in ordine e cinque regole che non si negoziano. I comandi cambiano ogni anno, e chi li impara a memoria è indifeso.
Il mestiero non consiste nel sapere che cosa si può fare. Consiste nel sapere che cosa si fa, e nel sapere che cosa non si fa — ogni volta, con la firma sotto.
Il vademecum in una riga
Se di tutto quanto sopra resta una cosa sola, è questa: guarda prima, tocca dopo, e non lasciare la porta più aperta di come l'hai trovata.