Rating di Cybersecurity usando Shodan
Da appassionata di mindfulness sono abituata a stare con quello che c’è: nel contesto IT questo atteggiamento traduce la capacità di osservare la realtà della connettività così com’è, senza dipendere esclusivamente da strumenti complessi. L’idea del progetto è produrre un cybersecurity rating che valuti in modo oggettivo l’assetto esposto di un dominio o di un’organizzazione—utilizzando fonti esterne come Shodan—e che allo stesso tempo si colleghi alle evidenze interne di compliance normativa e alle dashboard aziendali. Il risultato è una dashboard unica che coniuga visibilità esterna (servizi esposti, banner, versioni) e stato interno dei controlli (checklist ISO 27001, mappatura NIST CSF), trasformando dati tecnici in priorità concrete di remediation e in metriche utilizzabili dal management.
pippozzo time
Quando ho deciso di convertire la mia esperienza in insegnamento, ho iniziato a produrre una quantità non definita di slide cercando di spiegare tutto ciò che reputavo utile per le materie assegnate. In realtà quelle slide servivano più a me che agli studenti, perchè mi permettevano di superare la mia sindrome dell’impostore e visto che l’ho egregiamente superata, sono molto felice di poter parlare di questo progetto senza slide e chiarire anche alcuni aspetti un po’ più spinosi. Fare ricerche su un dominio usando Shodan (ovvero consultare i dati che Shodan ha già indicizzato, senza avviare scansioni o exploit verso il bersaglio) di norma non è reato: è attività di OSINT/passiva. Diventa invece rischioso (e potenzialmente configurante reato) effettuare scansioni attive, sfruttare vulnerabilità o introdursi in sistemi protetti senza autorizzazione (art. 615-ter c.p.).
Quindi chiariamo subito che questo progetto è stato un passive OSINT e non uno scanning attivo. Shodan permette di raccogliere e rendere ricercabili i risultati che il suo crawler ha già eseguito. Consultare questi dati è un’attività passiva e, in sé, non costituisce accesso abusivo. Se poi quello che si trova è un portale di accesso esposto e con “admin” “admin” si riesce ad entrare, allora stiamo sfruttando una vulnerabilità e entrando in un sistema. Qualora si dovesse trovare un portale esposto, l’etica è quella di contattare l’owner e comunicargli questa vulnerabilità in modo tale da rendere internet un posto più sicuro. Per un dominio che si cerca Shodan fornisce informazioni indicizzate come: indirizzo IP, porte aperte, servizi e banner (es. server web, SSH, FTP), versioni dei software riportate nei banner, certificati SSL/TLS e i loro soggetti, hostname e domini associati, organizzazione/ASN, geolocalizzazione approssimativa dell’IP, timestamp dell’ultima scansione, eventuali tag di vulnerabilità o CVE rilevati e storici di banner. Questi dati derivano da dati raccolti pubblicamente eseguiti dal crawler di Shodan e sono esposti tramite l’interfaccia e la API ufficiale.
Ormai è finita l’epoca dei siti creati in modo casalingo con l’indirizzo di casa e numero di telefono del proprietario nel dettaglio del dominio, ora ci si rifà a grandi fornitori (come Squarespace, dove è hostato fattoreumano.org, Wordpress, etc) che proteggono - nella maggior parte dei casi - le informazioni e che tutelano anche la loro infrastruttura. Facendo un reverse dell’indirizzo IP di fattoreumano.org - ad esempio - potrebbe uscirvi un IP che su Shodan in realtà compare associato a qualcunaltro, proprio perchè il TTL è di 4h (e quindi ogni 4h viene cambiato e associato ad altro). Vediamo un po’ da lontano cosa possiamo trovare su Shodan cercando, ad esempio, la mappa dei servizi esposti in Italia (immagine qui sotto, ref: https://exposure.shodan.io/#/IT). Questa fotografia solitamente fa sentire meno soli i manager di Aziende che sono appena state bucate proprio a causa di uno di questi servizi esposti.
Capiamo cosa si può fare con shodan
La porta 5060, ad esempio, è usata dal protocollo SIP per il signalling delle chiamate VoIP; la sua presenza pubblica non è di per sé un’emergenza, ma segnala che vale la pena verificare. Per intercettare traffico su 5060 (o sulla 7170) un attaccante non basta che “apra” una porta: deve trovarsi sul percorso di rete dei pacchetti (on-path), compromettere un dispositivo intermedio o manipolare attivamente la negoziazione della chiamata. Molti telefoni IP e centralini rispondono su 5060, quindi la porta è spesso visibile; però il traffico viaggia comunque verso l’indirizzo destinazione, non verso chiunque voglia ascoltare. Un avversario può leggere o dirottare le comunicazioni solo se è fisicamente o logicamente in mezzo (e.g. stessa rete Wi-Fi non protetta, router/ISP compromessi, ARP-spoofing o DNS poisoning), oppure se riesce a forzare la chiamata a passare per un suo server. Se signalling e media sono cifrati (SIP/TLS per lo signalling, SRTP per l’audio) una semplice acquisizione passiva dei pacchetti non permette di leggere il contenuto.
La porta aperta è da intendersi come un indicatore da investigare, non una prova di compromissione. Serve controllare quale servizio la espone, valutare la necessità dell’esposizione e applicare mitigazioni se necessario.
il progetto
Il progetto si può fare individualmente o in gruppi, può riguardare un target definito conosciuto o basandosi su un protocollo vulnerabile (e.g. videocamere casalinghe). Vediamo nel dettaglio quali possono essere le fasi di processo possono essere considerate per questa tipologia di attività.
Fase 1 — Analisi del target: definire scope e perimetro in modo da ottenere più informazioni possibili. In questa fase non si utilizzano tool invasivi perchè non è lo scopo dell’OSINT - quindi, evitiamo tool tipo OWASP Juice Shop/ZAP che necessitano di autorizzazione. Di seguito un po’ di tool utili (oltre a Shodan.io):
Whois Lookup: Servizi come who.is o ICANN WHOIS permettono di trovare informazioni sui domini registrati da un’azienda.
SecurityTrails (securitytrails.com) o https://dnsdumpster.com: per la lista dei domini registrati per un’azienda e la cronologia delle modifiche ai DNS e anche quelli registrati.
crt.sh (crt.sh): Database pubblico dei certificati SSL, utile per scoprire sottodomini di un’azienda analizzando i certificati emessi.
Google Dorks: Ricerche avanzate su Google con operatori specifici, ad esempio: site:azienda.com (mostra tutti i sottodomini indicizzati) o site:azienda.com -www (esclude il dominio principale per concentrarsi sui sottodomini).
https://www.ssllabs.com/ssltest/ per la verificara dell’ssl dei siti.
https://builtwith.com/ vedere la tecnologia con cui è sviluppato un sito andando ad identificare domini, sottodomini e record DNS.
https://www.criminalip.io/asset lista di tutti gli IP che sono già disponibili e classificati come non sicuri.
Fase 2 — Analisi dei risultati: definire i sott-indicatori (E = esposizione servizi, V = vulnerabilità note, C = stato certificati, D = servizi sensibili esposti, S = dispersione/numero asset) e la scala di normalizzazione (0–100). Stabilire pesi documentati per ogni sott-indicatore e calcolare la formula aggregata (es. Rating = somma pesata normalizzata). Introdurre campo “confidenza” che modula il peso della evidenza instabile (IP dinamici, ad esempio, avranno un peso ridotto). Inoltre è necessario anche definire soglie operative (es. 0–30 basso, 31–60 medio, 61–100 alto) per potere avere delle tabelle di analisi con punteggi parziali, rating finale e tracciamento delle formule.
Fase 3 — Reporting & Governance: associare ogni metrica ai controlli NIST CSF (Identify/Protect/Detect/Respond/Recover) e ai controlli ISO 27001 rilevanti (es. A.8, A.12, A.14 ecc.). Per ogni gap identificato generare una raccomandazione tecnica e una corrispondente azione di compliance (priority, owner, tempo stimato) in modo tale da produrre una matrice finale dove si hanno i punti emersi, i controlli NIST/ISO connessi e le raccomandazione. Alcuni spunti potrebbero essere ad esempio raccogliere gli asset a rischio, CVE critiche con link NVD, heatmap per porta/servizio, drill-down che rimandi al raw banner Shodan e al record WHOIS. La fasse di reporting è estremamente importante per poter far evincere la sintesi, metodologia e limiti, oltre che le questioni più tecniche (raw data, formule, playbook remediation). Quando si parlaa di governance si intende la possibilità di stabilire i ruoli (responsabile progetto, owner dati, legale), policy di retention (es. evidenze conservate 90 giorni salvo diversa indicazione), procedure di accesso e distruzione delle evidenze, rispetto dei T&C delle piattaforme utilizzate e clausole di disclosure per terze parti. Includere meccanismi di opt-out e debriefing per soggetti coinvolti. Output minimo: policy firmata, registro accessi, procedura di distruzione. La governance aiuta anche a definire i KPI per la qualità dei dati (tasso falsi positivi, % host verificati), prevedere cicli di riepilogo periodico (monthly/quarterly) per ritarare pesi, soglie e workflow, e aggiornare la matrice NIST/ISO in base a cambi normativi.
