Metasploitable/DNS Bind - Revision history

Admin: /* DNS Exploit: bailiwicked host */

2016-08-19T09:43:18Z

DNS Exploit: bailiwicked host

← Older revision		Revision as of 09:43, 19 August 2016
Line 484:		Line 484:

	==DNS Exploit: bailiwicked host==		==DNS Exploit: bailiwicked host==

			In plain English, this attack allows you to add your own host entry to a DNS nameserver's list of hostnames. This is done by confusing the nameserver by sending responses to fake DNS queries.

	We can use this exploit by running:		We can use this exploit by running:

Admin: /* DNS Exploit: bailiwicked domain */

2016-08-19T09:40:05Z

DNS Exploit: bailiwicked domain

← Older revision		Revision as of 09:40, 19 August 2016
Line 6:		Line 6:

	==DNS Exploit: bailiwicked domain==		==DNS Exploit: bailiwicked domain==

			In plain English, this attack allows you to add your own DNS entries to a target DNS nameserver. Thus, you could create a DNS entry like somethingveryevil.microsoft.com that would direct visitors wherever you wish.

	We can use this exploit by running:		We can use this exploit by running:
Line 408:		Line 410:
	If you monitor your network interface in another window with tcpdump, you'll see this creates a HUGE amount of DNS packet traffic.		If you monitor your network interface in another window with tcpdump, you'll see this creates a HUGE amount of DNS packet traffic.

	On a low-traffic server, this will cause a noticeable spike in traffic, and probably raise some eyebrows and~~/or~~ get your ~~IP blocked~~. The traffic graph shown below shows the traffic spike that the target domain (example.com, or yahoo.com, or whatever you pick) sees. The blue spike is incoming traffic, and is caused by this DNS bind attack:		On a low-traffic server, this will cause a noticeable spike in traffic, and probably raise some eyebrows and get the IT crew on your case. The traffic graph shown below shows the traffic spike that the target domain (example.com, or yahoo.com, or whatever you pick) sees. The blue spike is incoming traffic, and is caused by this DNS bind attack:

	[[Image:TrafficSpike.png\|500px]]		[[Image:TrafficSpike.png\|500px]]

Admin: /* Reason for Failure */

2016-03-26T17:11:22Z

Reason for Failure

← Older revision		Revision as of 17:11, 26 March 2016
Line 912:		Line 912:
	{{Quote\|		{{Quote\|
	On another note, before using Metasploit to test your DNS infrastructure to see if it is exploitable, it is important to know whether your local network allows spoofed packets out. Many firewalls can be configured to drop spoofed packets from internal systems, and even my little LinkSys router does this. Because there is no mechanism in Metasploit currently (as far as I know) to detect whether your local network filters spoofed packets (and building such a mechanism would be tricky for various technical reasons), an incorrect assumption can result in a cache poisoning attack that has no possibility of succeeding but that also generates thousands of DNS queries at the same time.		On another note, before using Metasploit to test your DNS infrastructure to see if it is exploitable, it is important to know whether your local network allows spoofed packets out. Many firewalls can be configured to drop spoofed packets from internal systems, and even my little LinkSys router does this. Because there is no mechanism in Metasploit currently (as far as I know) to detect whether your local network filters spoofed packets (and building such a mechanism would be tricky for various technical reasons), an incorrect assumption can result in a cache poisoning attack that has no possibility of succeeding but that also generates thousands of DNS queries at the same time.

	Finally, for those unpatched nameservers running behind an iptables firewall, the SNAT --random option can provide a work-around for predictable source ports. Nevertheless, the emphasis should always be on patching vulnerable servers since the source port problem is only one aspect of the vulnerability in DNS.

	- https://cipherdyne.org/blog/2008/07/metasploit-dns-cache-poisoning-and-iptables-countermeasures.html		- https://cipherdyne.org/blog/2008/07/metasploit-dns-cache-poisoning-and-iptables-countermeasures.html

Admin: /* Flags */

2016-03-26T17:06:37Z

Flags

@@ Line 906: / Line 906: @@
 msf auxiliary(bailiwicked_host) >
 </pre>
 }}

Admin: /* Attack failure */

2016-03-26T16:57:32Z

Attack failure

← Older revision		Revision as of 16:57, 26 March 2016
Line 121:		Line 121:
	The attack fails. The DNS poisoning attempts continue indefinitely, but never finish. The output below took around 2 hours to generate.		The attack fails. The DNS poisoning attempts continue indefinitely, but never finish. The output below took around 2 hours to generate.

			{{Scroll box\|
	<pre>		<pre>
	msf auxiliary(bailiwicked_domain) > run		msf auxiliary(bailiwicked_domain) > run
Line 400:		Line 401:
	[*] race calc: 25 queries \| min/max/avg time: 0.01/0.69/0.19 \| min/max/avg replies: 11/480/128		[*] race calc: 25 queries \| min/max/avg time: 0.01/0.69/0.19 \| min/max/avg replies: 11/480/128
	[*] Now sending 32 spoofed replies from each nameserver (6) for each query		[*] Now sending 32 spoofed replies from each nameserver (6) for each query

	</pre>		</pre>
			}}

	===Tcpdump during bailiwicked domain attack===		===Tcpdump during bailiwicked domain attack===

Admin: /* Executing */

2016-03-26T16:55:08Z

Executing

Show changes

Admin: /* Before */

2016-03-26T16:41:20Z

Before

@@ Line 546: / Line 546: @@
 ===Before===
 =Flags=
 {{MSFlag}}

Admin: /* DNS Exploit: bailiwicked host */

2016-03-26T16:39:50Z

DNS Exploit: bailiwicked host

← Older revision		Revision as of 16:39, 26 March 2016
Line 535:		Line 535:

	</pre>		</pre>

			===Failure to check exploit===

			No die with the check, again:

			<pre>
			msf auxiliary(bailiwicked_host) > check
			[*] 10.0.0.27 - Cannot reliably check exploitability.
			</pre>

			===Before===

	=Flags=		=Flags=

	{{MSFlag}}		{{MSFlag}}

Admin: /* DNS Exploit: bailiwicked domain */

2016-03-26T16:38:55Z

DNS Exploit: bailiwicked domain

@@ Line 479: / Line 479: @@
 Reasons for failure are unclear at this point.
 =Flags=
 {{MSFlag}}

Admin: /* Tcpdump */

2016-03-26T16:27:47Z

Tcpdump

← Older revision		Revision as of 16:27, 26 March 2016
Line 403:		Line 403:
	</pre>		</pre>

	==Tcpdump==		===Tcpdump during bailiwicked domain attack===

	If you monitor your network interface in another window with tcpdump, you'll see this creates a HUGE amount of DNS packet traffic.		If you monitor your network interface in another window with tcpdump, you'll see this creates a HUGE amount of DNS packet traffic.
Line 476:		Line 476:
	</pre>		</pre>

	~~Reason~~ for failure is unclear.		===Conclusions?===

			Reasons for failure are unclear at this point.

	=Flags=		=Flags=

	{{MSFlag}}		{{MSFlag}}