Come i trasferimenti di zona aperti espongono la tua rete interna

Sintesi: un trasferimento di zona DNS (AXFR) dovrebbe rimanere confinato tra il nameserver primario e quelli secondari di un dominio. Quando viene lasciato aperto a chiunque, un'unica query restituisce un elenco completo di ogni host presente in quella zona. In recenti analisi, Red Sift ha trovato zone in più patrimoni DNS che consegnavano hostname interni, infrastrutture VoIP non crittografate e mappe di rete complete a chiunque le richiedesse. Nessuna di queste organizzazioni ha deciso volontariamente di esporre questi dati. È semplicemente il risultato di un accumulo nel tempo.

Da non perdere: il nostro primo articolo di questa serie sulla gestione dei DNS pendenti.

• Un trasferimento di zona aperto restituisce ogni hostname di una zona con un'unica query, senza bisogno di scansioni o tentativi
• I domini principali sono spesso protetti, mentre un sottodominio delegato, spesso di proprietà di un team diverso, viene lasciato completamente aperto
• Ciò che viene esposto non è astratto. Si tratta di endpoint SIP, ambienti di sviluppo e convenzioni di denominazione interne su cui un aggressore può agire immediatamente
• Red Sift ASM scopre e monitora continuamente questi asset, compresi quelli di cui il tuo team non conosce nemmeno l'esistenza

Un trasferimento di zona DNS, o AXFR, è il meccanismo utilizzato da un nameserver primario per replicare il proprio file di zona completo su un nameserver secondario. Si tratta di una parte normale e necessaria della gestione del DNS. Due server devono avere gli stessi record, quindi uno copia l'intera zona sull'altro.

Il problema è che l'AXFR non è stato progettato pensando all'internet moderno. A meno che un nameserver non sia esplicitamente configurato per limitare i trasferimenti a indirizzi IP affidabili, risponderà a una richiesta di trasferimento proveniente da chiunque. Esegui dig axfr @nameserver domain.com contro un server mal configurato e otterrai indietro ogni record di quella zona. Ogni sottodominio. Ogni hostname interno. Ogni indirizzo IP collegato a quegli host.

Non è necessario forzare i sottodomini o scansionare intervalli di IP per costruire una mappa dell'infrastruttura di qualcuno. Basta chiederla.

La maggior parte dei team di sicurezza che ci ha riflettuto ha bloccato i trasferimenti sul proprio dominio principale. È la zona che tutti ricordano di controllare.

Ciò che viene trascurato è la delega. Quando un dominio affida un sottodominio a un nameserver diverso, magari per un prodotto specifico, un ufficio regionale o una piattaforma di proprietà di un team diverso, quella zona delegata funziona con la propria configurazione. Nessuno la riverifica secondo gli standard del dominio principale, perché nessuno la considera una zona separata. È semplicemente "parte del dominio".

La scala è il vero problema qui. La nostra analisi ha riscontrato lo stesso schema di esposizione in più organizzazioni. Prendiamo un'azienda di telecomunicazioni. I loro nameserver principali erano puliti: trasferimenti limitati, record aggiornati, niente da segnalare. Ma un sottodominio delegato, configurato anni prima per una piattaforma di videoconferenza, consentiva ancora trasferimenti di zona aperti su sei hostname.

Nessuno l'ha fatto apposta. Un sottodominio viene delegato per un progetto, il team che lo gestiva passa ad altro, e la configurazione non viene mai più rivista. È semplicemente finita così.

Un singolo dig axfr contro quella zona delegata ha restituito:

• Gli hostname interni dei Session Border Controller in esecuzione in due sedi separate, comunicanti tramite SIP non crittografato
• Un insieme di hostname interni mappati direttamente a specifiche funzioni aziendali, rendendo immediatamente leggibile la convenzione di denominazione interna
• Un ambiente di sviluppo collocato all'interno di quella che era altrimenti una zona di produzione
• Un numero seriale SOA che mostrava come la zona non fosse stata toccata dal 2019

Niente di tutto questo richiede a un aggressore di fare qualcosa di sofisticato. È una lista di bersagli, consegnata gratuitamente. Un SIP non crittografato indica esattamente dove intercettare una chiamata. Un ambiente di sviluppo all'interno di una zona di produzione indica esattamente dove i controlli sono probabilmente più deboli. Un record aggiornato l'ultima volta nel 2019 indica che nessuno lo sta controllando.

Un'analisi separata, questa volta presso un'azienda SaaS, ha mostrato una versione diversa della stessa causa alla radice. Un ingegnere di rete aveva recentemente preso in carico un'infrastruttura cresciuta per anni sotto proprietari diversi. Conosceva alcuni dei problemi nella parte di zona che aveva ereditato. Non li conosceva tutti.

Un dig axfr ha restituito quasi 55 host, ciascuno con un indirizzo IP risolvibile, in un'unica risposta. Non si tratta di un quadro parziale. È una mappa quasi completa di una porzione significativa dell'ambiente aziendale, consegnata con un'unica query a chiunque avesse pensato di chiederla.

Nessuno dei due casi ha coinvolto un attacco sofisticato. Entrambi hanno coinvolto una query DNS standard che avrebbe dovuto essere rifiutata e non lo è stata.

Un trasferimento di zona aperto non è un rischio teorico da segnalare in un foglio di calcolo per la conformità. È attività di ricognizione, svolta per conto dell'aggressore, a costo zero per lui.

Una volta che qualcuno ha un elenco completo dei tuoi hostname e indirizzi IP, non deve indovinare dove guardare. Sa quali host eseguono cosa. Sa dove un ambiente di sviluppo potrebbe avere una gestione delle patch più debole. Sa quale infrastruttura gestisce il traffico vocale e se è crittografato. Ogni modalità di fallimento descritta in questo articolo, un trasferimento non limitato, una delega non monitorata, un record obsoleto che nessuno ha più rivisto, indica a un aggressore esattamente quale asset colpire successivamente.

Questo è anche il motivo per cui i controlli puntuali non reggono. La zona dell'azienda di telecomunicazioni presumibilmente aveva superato una revisione a un certo punto. La delega semplicemente non è più stata riesaminata da allora. I patrimoni DNS non restano fermi. Nuovi sottodomini vengono delegati, nuovi team ne assumono la proprietà, e le configurazioni si discostano senza che nessuno lo decida.

Testa qualsiasi nameserver di cui sei responsabile con:

Se restituisce un elenco completo della zona invece di un rifiuto, quel server consente trasferimenti non limitati. Risolvi il problema limitando esplicitamente i trasferimenti a un elenco denominato di indirizzi IP secondari affidabili nella configurazione del tuo server DNS, che si tratti di BIND, PowerDNS o dell'impostazione equivalente del tuo provider DNS.

Poi vai oltre il dominio principale. Elenca ogni sottodominio che è stato delegato a un nameserver diverso, e testa ciascuno allo stesso modo. Se non hai un elenco aggiornato di ciò che è stato delegato e a chi, quella è la vera scoperta. Non hai ancora un problema di trasferimento di zona, hai un problema di visibilità, e il trasferimento di zona è solo il primo punto in cui emerge.

È difficile individuare questo problema controllando occasionalmente il proprio dominio, perché l'esposizione di solito non riguarda il dominio gestito attivamente dal tuo team. Riguarda quello che è stato delegato tre anni fa e che è silenziosamente scomparso dal radar di tutti.

Red Sift ASM scopre e inventaria continuamente i tuoi asset esposti all'esterno, compresi quelli di cui il tuo team non sa ancora dell'esistenza, collegandosi direttamente ai tuoi registrar e provider DNS gestiti invece di affidarsi a un elenco manuale. Monitora la configurazione DNS su tutto il tuo patrimonio in modo continuativo, non come un audit occasionale, così un sottodominio delegato che devia dalle policy viene segnalato invece che dimenticato. E poiché ti mostra ciò che un aggressore vede dall'esterno, l'infrastruttura di terze parti e quella delegata ricevono lo stesso livello di controllo degli asset configurati direttamente dal tuo team.