Cosa trova davvero un penetration test di rete esterna

Troviamo ancora sull’internet pubblica pannelli di login che accettano admin/admin al primo tentativo. Non una volta, non per caso. È un titolo ricorrente nei nostri report. Un’appliance di backup montata in rack anni fa e mai più toccata. Un server di staging che uno sviluppatore ha tirato su in un weekend e poi dimenticato. Una porta di gestione del firewall che avrebbe dovuto essere limitata a un solo IP dell’ufficio e non lo è mai stata.

Questa è la scomoda verità sui penetration test di rete esterna: la via d’ingresso non è quasi mai ingegnosa. È qualcosa che già possiedi e che hai smesso di sorvegliare.

Un penetration test di rete esterna significa attaccare i tuoi sistemi esposti su internet come farebbe un vero intruso – dall’esterno, senza credenziali, senza schema di rete e senza aiuto. Il punto è trovare la porta prima che la trovi qualcuno che non ti deve rendere conto. Questa è una panoramica di ciò che quei test portano a galla, di come lo facciamo emergere e di cosa correggere per primo.

Punti chiave

• I penetration test di rete esterna attaccano i tuoi asset esposti su internet senza accesso preliminare, per individuare i punti d’ingresso che un attaccante cerca per primi.
• I riscontri a maggiore impatto sono di solito banali: pannelli di amministrazione esposti, appliance VPN e firewall non aggiornate e credenziali predefinite o riutilizzate.
• La scoperta della superficie di attacco vale metà del lavoro. La maggior parte delle organizzazioni non riesce a elencare ogni host che espone, ed è dai dimenticati che entriamo.
• I dispositivi perimetrali come VPN, firewall e gateway di posta sono bersagli privilegiati, perché una sola falla non autenticata può consegnare l’intero perimetro.
• Le correzioni sono noiose di proposito: ridurre la superficie esposta, aggiornare in fretta i dispositivi perimetrali, eliminare le credenziali predefinite e imporre l’MFA su tutto ciò che è esposto su internet.

Che cos’è un penetration test di rete esterna?

Un penetration test di rete esterna è un attacco controllato contro tutto ciò che la tua organizzazione espone all’internet pubblica: server web, server di posta, gateway VPN, firewall, servizi di accesso remoto, DNS e qualsiasi altra porta raggiungibile da un estraneo. Il tester parte dalla sedia di un attaccante, di solito con nient’altro che il nome della tua azienda o un elenco di intervalli di IP e domini.

Risponde a una domanda schietta. Se oggi un estraneo motivato ci puntasse addosso, riuscirebbe a prendere piede dall’esterno? È una domanda diversa da quella che pone un test interno. Il lavoro interno presuppone che l’attaccante sia già dentro e misura fin dove arriva. Il lavoro esterno riguarda il perimetro, e il perimetro è più ampio e più caotico di quanto la maggior parte dei team creda.

Lo si confonde con una scansione delle vulnerabilità. A torto. Una scansione lancia uno strumento e stampa un report. Un penetration test usa quell’output come punto di partenza, poi un essere umano lo convalida, concatena i riscontri e li sfrutta per dimostrare un impatto reale. Gli scanner sono rumorosi e ciechi al contesto. Uno segnala un’impostazione TLS di gravità media e passa dritto davanti al pannello di amministrazione che accetta admin/admin, perché fare login non è una cosa che uno scanner proverà davvero.

Come si mappa la superficie di attacco esterna?

La scoperta viene per prima, ed è lì che si nasconde una quantità sorprendente del valore. Prima di toccare qualsiasi cosa, costruiamo il quadro più completo possibile di ciò che esponi. L’elenco in ambito che un cliente ci consegna è raramente l’elenco completo di ciò che manda davvero online.

Apriamo con la ricognizione passiva per restare silenziosi: log di certificate transparency, record DNS, dati WHOIS e motori di ricerca che indicizzano i servizi esposti. La certificate transparency è la prima a cui ricorro. Ogni certificato TLS che un’azienda emette viene registrato pubblicamente, quindi fa trapelare sottodomini che nessuno voleva pubblicizzare – i nomi host dev, uat e vpn-test che non avrebbero mai dovuto essere trovabili.

# Subdomain enumeration from multiple passive sources
subfinder -d acme-corp.com -all -silent | tee subs.txt

# Resolve, then probe which ones are actually live
cat subs.txt | dnsx -silent -a -resp | httpx -silent -title -status-code -tech-detect

Poi passiamo all’attivo: scansione delle porte sugli host risolti e fingerprinting di ciò che risponde. Non contiamo soltanto le porte aperte. Diamo la caccia a quelle interessanti. Niente affina la concentrazione di un tester come la 3389 (RDP), la 445 (SMB) o una porta di database che risponde dritta su internet.

# Fast full-range TCP sweep, then service/version detection on the hits
nmap -p- --min-rate 2000 -oA sweep 203.0.113.0/24
nmap -sV -sC -p 22,443,3389,8443 -oA services 203.0.113.10

Ciò che ne esce è un inventario vivo: nomi host, IP, porte aperte, software in esecuzione, versioni. Quell’inventario sorprende regolarmente chi ha commissionato il test. Abbiamo consegnato a dei team un elenco in cui una fetta consistente degli host erano cose di cui il loro gruppo di sicurezza non aveva mai sentito parlare, tirate su da uno sviluppatore o da un fornitore di marketing e lasciate accese a girare.

Che cosa trova davvero un test esterno?

Ecco la ripartizione onesta di ciò che finisce in prima pagina nei nostri report, più o meno nell’ordine in cui tende a contare.

Servizi esposti e interfacce di amministrazione

Il riscontro grave più comune è qualcosa che non avrebbe mai dovuto affacciarsi su internet. Console di gestione. Dashboard di CI come Jenkins. Porte di database. Server API di Kubernetes. Istanze di Elasticsearch e Redis lasciate lì senza autenticazione – e sì, un Redis aperto significa spesso una rapida connessione redis-cli e un’occhiata a qualunque cosa vi sia in cache. Pannelli di amministrazione di stampanti e dispositivi IoT. Ambienti di staging che rispecchiano la produzione ma ne saltano i controlli. Se è in ascolto su un IP pubblico ed è stato costruito per uso interno, lo mettiamo a verbale.

Appliance perimetrali non aggiornate

I concentratori VPN, i firewall e i gateway di posta sono esattamente dove un attaccante esterno vuole stare, e invecchiano male. Stanno proprio sul confine. Fanno girare software che spesso non puoi ispezionare. E un solo bug di pre-autenticazione in uno di essi può scaricare un attaccante dritto sulla rete interna. Falle critiche non autenticate in importanti prodotti VPN e firewall sono state tra i bug più massicciamente sfruttati degli ultimi anni, proprio perché sono esposti su internet per progettazione e lenti da correggere. Quando individuiamo un dispositivo perimetrale che esegue una versione con un exploit pubblico noto, quello finisce in cima al report – e arriva con una telefonata.

Credenziali predefinite e deboli

Le credenziali predefinite non vogliono saperne di morire. Il problema ha persino una sua classe di debolezza, CWE-1392, uso di credenziali predefinite, e troviamo ancora admin/admin, admin/password e valori di fabbrica su apparati messi in produzione di fretta e mai più rivisti. Subito dietro arriva il riutilizzo delle credenziali – password bruciate in vecchie violazioni di terze parti che aprono ancora la tua VPN o la tua webmail. Testiamo le superfici di login individuate contro elenchi curati e derivati da violazioni, con attenzione e con limite di frequenza, perché a un attaccante che lancia un password spraying (MITRE ATT&CK T1110.003) non importa nulla di una policy di blocco che non hai mai configurato.

MFA assente sull’accesso remoto

Un portale VPN o Outlook Web Access protetto dalla sola password è a una credenziale dalla compromissione. Lo spraying unito all’assenza di MFA è tra le vie più affidabili verso un’organizzazione che vediamo, e non richiede nemmeno una riga di codice di exploit. Se è affacciato su internet e apre una porta verso qualcosa di interno, serve un secondo fattore. Punto e basta.

Fughe di informazioni e configurazioni errate

Pagine di errore troppo dettagliate. Directory .git esposte. Elenchi di directory. File di backup lasciati nella root del sito. Nomi host interni che trapelano dalle intestazioni HTTP. Presi da soli sembrano banali. Concatenati, consegnano all’attaccante una mappa – e a volte codice sorgente o credenziali senz’altro.

Perché conta una sola porta aperta?

Perché il perimetro è una catena, e a un attaccante basta che tenga un solo anello. Guarda come va. Un sottodominio dimenticato punta a un’applicazione web non aggiornata. L’applicazione fa trapelare il tuo formato interno dei nomi utente. Quel formato alimenta un password spraying contro la VPN, e la VPN non ha MFA. Ora c’è un punto d’appoggio all’interno, e il test esterno ha appena mostrato l’anteprima di una violazione al rallentatore.

Nessuno di quei passaggi ha avuto bisogno di uno zero-day. È il punto che ripetiamo ai clienti di continuo. È molto più probabile che tu venga compromesso attraverso una pila di esposizioni ordinarie e correggibili che tramite qualche attacco esotico e inedito. I penetration test di rete esterna esistono per trovare quella pila finché è ancora un tuo problema, da risolvere in silenzio.

Come si prevengono questi riscontri?

I rimedi sono poco spettacolari, il che è una buona notizia, perché poco spettacolare significa realizzabile.

• Riduci la superficie. Ogni servizio su un IP pubblico dovrebbe avere una ragione documentata per stare lì. Se non ce l’ha, toglilo da internet o spostalo dietro la VPN. Nessuno attacca una porta che non è aperta.
• Tieni un inventario degli asset davvero accurato. Non puoi difendere ciò che non sai di possedere. Mantieni un elenco vivo degli asset esposti su internet e riconcilialo regolarmente, idealmente con una scoperta esterna automatizzata che esegue la stessa ricognizione di un attaccante.
• Aggiorna i dispositivi perimetrali con corsia preferenziale. VPN, firewall e gateway di posta meritano un loro processo accelerato. Quando un fornitore rilascia una correzione per una falla non autenticata in uno di essi, conta in giorni, non in settimane.
• Elimina le credenziali predefinite e imponi l’MFA. Cambia ogni valore predefinito al momento del deployment, blocca le password riutilizzate e compromesse e richiedi l’autenticazione a più fattori su ogni superficie di accesso remoto e di amministrazione. Questo singolo controllo neutralizza gran parte di ciò che sfruttiamo.
• Riesegui il test dopo aver cambiato le cose. Un perimetro non è statico. Compaiono nuovi servizi, i record DNS si spostano, le appliance vanno fuori data. Un test puntuale è un’istantanea, non una garanzia.

Come CyberXplore aiuta

Il nostro servizio di penetration test di rete esterna fa esattamente ciò che descrive questo articolo. Mappiamo l’intera tua impronta esposta su internet, compresi gli asset che non sapevi fossero esposti, poi convalidiamo e sfruttiamo in sicurezza ciò che troviamo per mostrare un impatto reale invece di un muro di rumore da scanner. Ottieni un report prioritizzato che separa le cose da correggere oggi dal rischio di fondo, con chiari passi di riproduzione su cui i tuoi tecnici possono agire, e un nuovo test per confermare che i buchi siano davvero chiusi. Se vuoi vedere ciò che vede un vero attaccante quando guarda il tuo perimetro, richiedi un preventivo e ne definiremo insieme l’ambito.

FAQ

In cosa un penetration test di rete esterna è diverso da una scansione delle vulnerabilità?

Una scansione delle vulnerabilità è automatica e sputa fuori un elenco di potenziali problemi, molti dei quali falsi positivi, senza alcuna prova che qualcosa sia sfruttabile. Un penetration test di rete esterna usa la scansione come uno degli input, poi un essere umano convalida i riscontri, li concatena e dimostra in sicurezza un impatto reale. La scansione ti dice cosa potrebbe non andare. Il test dimostra cosa un attaccante potrebbe davvero fare.

Quanto dura un penetration test di rete esterna?

Per una tipica impronta esterna di piccole-medie dimensioni, metti in conto all’incirca una o due settimane di test attivi più la stesura del report, anche se scala con il numero di host e servizi attivi in ambito. Ciò che varia di più è la scoperta, perché una superficie di attacco ampia o sconfinata richiede più tempo per essere mappata a fondo. Fissiamo la tempistica sul tuo reale numero di asset invece di tirare a indovinare.

Il test comprometterà i nostri sistemi di produzione?

Il test si svolge secondo regole d’ingaggio concordate in anticipo. Evitiamo le tecniche di denial-of-service, applichiamo limiti di frequenza a tutto ciò che tocca l’autenticazione e ci coordiniamo sui sistemi sensibili. La stragrande maggioranza del lavoro esterno è osservazione attenta e convalida controllata, e tutto ciò che ha un reale potenziale di disturbo viene eseguito solo con un via libera esplicito.

Con quale frequenza dovremmo eseguire i penetration test di rete esterna?

Almeno una volta all’anno, e dopo qualsiasi cambiamento significativo del tuo ambiente esposto su internet – il lancio di un nuovo prodotto, una migrazione, una fusione. Molte organizzazioni li eseguono anche per soddisfare requisiti di conformità come PCI DSS o SOC 2. Poiché i perimetri cambiano, i team con un’impronta in rapida evoluzione traggono vantaggio da test più frequenti o da un monitoraggio esterno continuo della superficie di attacco tra un ingaggio completo e l’altro.

Cosa otteniamo al termine dell’ingaggio?

Un report che si apre con una sintesi per la dirigenza e un elenco prioritizzato di riscontri ordinati per rischio reale, ciascuno con prove chiare, passi di riproduzione e indicazioni per la correzione. Separiamo le voci urgenti dall’hardening a priorità più bassa, così il tuo team sa esattamente da dove partire. Offriamo anche un nuovo test dopo la correzione per confermare che i problemi siano davvero chiusi e non solo segnalati.