<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Think Security &#187; nstx tunnel</title>
	<atom:link href="http://think-security.com/tag/nstx-tunnel/feed/" rel="self" type="application/rss+xml" />
	<link>http://think-security.com</link>
	<description>Information Security Resources and IT Professional Services</description>
	<lastBuildDate>Mon, 25 Jul 2011 10:48:18 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.2</generator>
		<item>
		<title>IP over DNS</title>
		<link>http://think-security.com/ip-over-dns/</link>
		<comments>http://think-security.com/ip-over-dns/#comments</comments>
		<pubDate>Sun, 05 Sep 2010 10:50:40 +0000</pubDate>
		<dc:creator>gmoskov</dc:creator>
				<category><![CDATA[Internal Network]]></category>
		<category><![CDATA[Pentest Articles]]></category>
		<category><![CDATA[bypass firewall]]></category>
		<category><![CDATA[covert channel]]></category>
		<category><![CDATA[dns tunnel]]></category>
		<category><![CDATA[iodine]]></category>
		<category><![CDATA[ip over dns]]></category>
		<category><![CDATA[NSTX]]></category>
		<category><![CDATA[nstx tunnel]]></category>

		<guid isPermaLink="false">http://think-security.org/?p=6</guid>
		<description><![CDATA[Sometimes while you are performing a penetration test, you need to break out from a supposedly isolated network like an internal VLAN in a bank, or a process network full of <a href="http://en.wikipedia.org/wiki/SCADA">SCADA</a> equipment. Such networks should be completely isolated from the Internet, so there is no chance that someone who has network access can implant a backdoor and either sneak out information or allow access from the outside. This article demonstrates how the often overlooked DNS service can be used to build a covert channel and why when you configure an isolated network, you shouldn't allow even name resolution of external hosts. To demonstrate this we will use the NSTX tunnel software to build a dns tunnel and bypass firewall. <span style="color:#777"> . . . &#8594; Read More: <a href="http://think-security.com/ip-over-dns/">IP over DNS</a></span>]]></description>
			<content:encoded><![CDATA[<p>Sometimes while you are performing a penetration test, you need to break out from a supposedly isolated network like an internal <strong>VLAN</strong> in a bank, or a process network full of <a href="http://en.wikipedia.org/wiki/SCADA" target="_blank">SCADA</a> equipment. Such networks should be completely isolated from the Internet, so there is no chance that someone who has network access can implant a backdoor and either sneak out information or allow access from the outside. This article demonstrates how the often overlooked <strong>DNS</strong> service can be used to build a covert channel and why when you configure an isolated network, you shouldn&#8217;t allow even name resolution of external hosts. To demonstrate this we will use both the <strong>NSTX</strong> and <strong>Iodine</strong> tunnels to build a dns tunnel and bypass the potential firewall restrictions.</p>
<h2>Scenario 1</h2>
<p>A great tool to demonstrate this idea is <a href="http://savannah.nongnu.org/projects/nstx/" target="_blank">NSTX</a>. It allows you to tunnel IP packets inside <strong>DNS</strong> queries, thus bypassing all firewall restrictions. Experience shows that almost any network will have access to <strong>DNS</strong> servers and also most <strong>DNS</strong> servers by default have forwarders enabled. This will be your gateway to the Internet, provided that you have a domain name that is controlled by you and a server with a valid external IP address, that is currently not running <strong>DNS</strong>.</p>
<p>The magic that makes the whole thing work is a <strong>subdomain </strong>whose control is delegated to your server which will be running the <strong>NSTX</strong> daemon. The following <a href="http://www.isc.org/software/bind" target="_blank">BIND</a> configuration lines demonstrate this:</p>
<pre>$ORIGIN tunnel.example.com.
@               IN      NS      ns.tunnel.example.com.
ns              IN      A       1.2.3.4</pre>
<p>These configure the <strong>DNS</strong> server to forward all <strong>DNS</strong> queries for the records in tunnel.example.com to the <strong>DNS</strong> server (<strong>NSTX</strong> daemon) located on IP address 1.2.3.4. This way all queries for hosts like test.tunnel.example.com will be forwarded to your <strong>NSTX</strong> daemon running at 1.2.3.4. As you might have already guessed, the actual host request that is sent to the <strong>NSTX</strong> daemon is a Base64 encoded part of an IP packet. Just as the <strong>TXT</strong> record that you receive in reply.</p>
<p>For the actual implementation we&#8217;ll assume that you using a <a href="http://www.debian.org/" target="_blank">Debian</a> or <a href="http://www.ubuntu.com/" target="_blank">Ubuntu</a> distribution. You need to install the <strong>nstx</strong> package, which can be achieved with the following command:</p>
<pre>$ sudo apt-get install nstx</pre>
<p>Then you&#8217;ll have to add the following lines in /etc/network/interfaces on the server:</p>
<pre>iface tun0 inet static
address 10.0.0.1
pointopoint 10.0.0.2
netmask 255.255.255.255
mtu 512</pre>
<p>Swap the IP addresses when you modify /etc/network/interfaces on the client machine:</p>
<pre>iface tun0 inet static
address 10.0.0.2
pointopoint 10.0.0.1
netmask 255.255.255.255
mtu 512</pre>
<p>This will ensure that one the <strong>NSTX</strong> tunnel is up, you&#8217;ll have 10.0.0.1 on the server and 10.0.0.2 on the client side. You might tweak the <strong>mtu</strong> parameter for better performance, but with 512 bytes you should be fine.</p>
<p>The next thing that you&#8217;ll need to do is to modify /etc/defaults/nstx. On the server make sure that the following entries are uncommented:</p>
<pre>NSTX_DOMAIN="tunnel.example.com"
start_nstxd=yes
ifup_tun=tun0</pre>
<p>And on the client side:</p>
<pre>NSTX_DOMAIN="tunnel.example.com"
start_nstxcd=yes
ifup_tun=tun0</pre>
<p>And that&#8217;s it! When you start the <strong>NSTX</strong> daemon on the server:</p>
<pre>$ sudo /etc/init.d/nstxd start</pre>
<p>&#8230; and on the client &#8230;</p>
<pre>$ sudo /etc/init.d/nstxcd start</pre>
<p>&#8230; you should see a tunnel interface called tun0 that is up on both machines and you should be able to ping 10.0.0.1 from the client. From there you might want to enable <strong>NAT</strong> on your server and allow packets to be routed through it, but as this is a trivial task, I guess you can figure that out by yourself.</p>
<h2>Scenario 2</h2>
<p>Now, after you have already understood the principle of operation and the low level approach, we present you the easy way of digging <strong>DNS</strong> tunnels &#8211; by using iodine. Compared to <strong>NSTX</strong>, <strong>iodine</strong> has the following advantages:</p>
<p><strong>Higher performance</strong><br />
iodine uses the NULL type that allows the downstream data to be sent without encoding. Each DNS reply can contain over a kilobyte of compressed payload data.<br />
<strong>Portability</strong><br />
iodine runs on many different UNIX-like systems as well as on Win32. Tunnels can be set up between two hosts no matter their endianness or operating system.<br />
<strong>Security</strong><br />
iodine uses challenge-response login secured by MD5 hash. It also filters out any packets not coming from the IP used when logging in.<br />
<strong>Less setup</strong><br />
iodine handles setting IP number on interfaces automatically, and up to 16 users can share one server at the same time. Packet size is automatically probed for maximum downstream throughput.</p>
<p>Even though Iodine is much easier to use and it has clients for Windows, it seems that it is not that reliable as NSTX, as NSTX works in some networks where Iodine fails. This has probably something to do with the different types of DNS queries that are used by those two applications.</p>
<p>The immediately obvious advantages are the <strong>Windows</strong> client, the password protection and the much easier setup process. As <strong>iodine</strong> comes bundled in most Debian distributions, you can just install it using apt-get, or you can grab the latest stable <strong>Windows</strong> packages from <a href="http://code.kryo.se/iodine/iodine-0.5.1-win32.zip" target="_blank">here</a>. Please refer to the <a href="http://code.kryo.se/iodine/README.html" target="_blank">README</a> for some explanation on the usage.</p>
<h2>Mitigation</h2>
<p>The mitigation couldn&#8217;t be easier &#8211; just don&#8217;t allow access from an isolated network to a DNS server which has forwarders enabled.</p>
]]></content:encoded>
			<wfw:commentRss>http://think-security.com/ip-over-dns/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>

