IPoverDNS - Revision history

LauraW: /* Set up routes to go through the tunnel */

2017-10-12T13:54:09Z

Set up routes to go through the tunnel

← Older revision		Revision as of 13:54, 12 October 2017
Line 129:		Line 129:

	<code>$ route del default</code>		<code>$ route del default</code>

	<code>$ route add default dns0</code>		<code>$ route add default dns0</code>

Line 136:		Line 137:

	[[File:SetupIPoDNS.png\|1000px]]		[[File:SetupIPoDNS.png\|1000px]]


	==== Put a ssh tunnel through the dns tunnel for encryption ====		==== Put a ssh tunnel through the dns tunnel for encryption ====

LauraW: /* Problems with Captive Portals */

2017-10-12T12:22:18Z

Problems with Captive Portals

← Older revision		Revision as of 12:22, 12 October 2017
Line 249:		Line 249:
	There is a workgroup dedicated to figure out solutions for captive portals: https://datatracker.ietf.org/wg/capport/charter/		There is a workgroup dedicated to figure out solutions for captive portals: https://datatracker.ietf.org/wg/capport/charter/

	It is not clear how other applications that are not using a webbrowser are supposed to work with a captive portal. ~~Forged~~ ~~DNS~~ ~~answers~~ ~~meddle~~ ~~with~~ ~~DNSSEC~~ ~~and~~ ~~can~~ ~~cause~~ ~~errors.~~ ~~They~~ ~~also~~ ~~don't~~ work ~~well~~ if the ~~user~~ ~~has~~ ~~it's~~ ~~own~~ ~~DNS~~ ~~servers~~ ~~configured~~.		It is not clear how other applications that are not using a webbrowser are supposed to work with a captive portal. E.g. when the user first starts an Email program the service might not work without any indication of what should be done. According to wikipedia, "Platforms that have Wi-Fi and a TCP/IP stack but do not have a web browser that supports HTTPS cannot use many captive portals. Such platforms include the Nintendo DS running a game that uses Nintendo Wi-Fi Connection."

			Forged DNS answers meddle with DNSSEC and can cause errors. They also don't work well if the user has it's own DNS servers configured. Some captive portals force the user to maintain an open browser window all the time, or log in again after a while.

			Not only does DNS tunneling allow for bypassing a captive portal, spoofing of your own MAC address can do the same trick.

	Some software tries to detect captive portals to handle them correctly, but that can also lead to problems and errors, as there is no standard. (example: https://forum.piratebox.cc/read.php?9,8879)		Some software tries to detect captive portals to handle them correctly, but that can also lead to problems and errors, as there is no standard. (example: https://forum.piratebox.cc/read.php?9,8879)

			In general, we are not very fond of the general principle of captive portals. It would be better if a standard was developed to handle this.

LauraW: /* Problems with Captive Portals */

2017-10-12T12:14:43Z

Problems with Captive Portals

← Older revision		Revision as of 12:14, 12 October 2017
Line 243:		Line 243:
	== Problems with Captive Portals ==		== Problems with Captive Portals ==

	=== Technical problems ===

	Redirecting the user to the captive portal is basically a '''man in the middle''' attack. ~~Therefore,~~ it ~~doesn't~~ ~~work~~ ~~with~~ ~~https~~ ~~websites,~~ ~~which~~ ~~are increasingly common. If the user tries~~ to ~~open~~ ~~a https~~ ~~website~~, they ~~are~~ ~~not~~ ~~redirected,~~ ~~but~~ ~~instead~~ ~~they~~ ~~get~~ an ~~https~~ ~~error~~.		Redirecting the user to the captive portal is basically a '''man in the middle''' attack. They use a HTTP protocol vulnerability to redirect users to their pages. Technically, they were never intended. There is no standard that describes their implementation.
			Of course, it doesn't work with https websites because this kind of man in the middle attacks is prevented there. And https websites with strict transport security are increasingly common. If the user tries to open a https website, they are not redirected to the portal, but instead they get an https error. Already, users often have the problem that many large websites such as Google, Facebook or Twitter can only be reached via HTTPS. Thanks to HSTS, it is ensured that these pages can not be called any more unencrypted. Captive portals won't work when those large and popular websites are requested, and when the ceritificate error message is displayed, it might encourage the bad practise of just clicking through the message and ignoring it.

			There is a workgroup dedicated to figure out solutions for captive portals: https://datatracker.ietf.org/wg/capport/charter/
	It causes some strange problems (https://forum.piratebox.cc/read.php?9,8879)

			It is not clear how other applications that are not using a webbrowser are supposed to work with a captive portal. Forged DNS answers meddle with DNSSEC and can cause errors. They also don't work well if the user has it's own DNS servers configured.
	forged DNS answers don't work with DNSSEC

			Some software tries to detect captive portals to handle them correctly, but that can also lead to problems and errors, as there is no standard. (example: https://forum.piratebox.cc/read.php?9,8879)

	=== fundamental problems ===

	man in the middle

LauraW at 10:30, 12 October 2017

2017-10-12T10:30:17Z

← Older revision		Revision as of 10:30, 12 October 2017
Line 67:		Line 67:

	You can test your server setup by putting in the IP here: http://code.kryo.se/iodine/check-it/		You can test your server setup by putting in the IP here: http://code.kryo.se/iodine/check-it/

			==== Configuring NAT and IP masquerading ====

			To forward your traffic to the internet and make your server do NAT, you have to set this up.

			Enable packet forwarding:

			<code>echo 1 > /proc/sys/net/ipv4/ip_forward</code>

			Make the setting persistent:

			<code>echo "net.ipv4.ip_forward=1" > /etc/sysctl.d/60-ipv4-forward.conf</code>

			Enable NAT by adding this to your IPTABLES:

			<code>
			iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

			iptables -t filter -A FORWARD -i eth0 -o dns0 -m state --state RELATED,ESTABLISHED -j ACCEPT

			iptables -t filter -A FORWARD -i dns0 -o eth0 -j ACCEPT
			</code>

			Make it persistent, e.g. like this:

			<code>iptables-save > /etc/iptables.rules</code>

Lmittmann: /* Tunneling Detection */

2017-10-12T10:14:39Z

Tunneling Detection

← Older revision		Revision as of 10:14, 12 October 2017
Line 178:		Line 178:

	<code>		<code>
	0abbt82M-J2hbM->M-nYM-VAdM-?BM-KM->M-nWwM-bM-RcxbM->M-X5M-RM-mfM-dZkM-DaUM-UM-^TVXM->qGaM-VmgwM-faM->gdki5.a.tunnel.~~l0m~~.de.		0abbt82M-J2hbM->M-nYM-VAdM-?BM-KM->M-nWwM-bM-RcxbM->M-X5M-RM-mfM-dZkM-DaUM-UM-^TVXM->qGaM-VmgwM-faM->gdki5.a.tunnel.mydomain.com.

	0ebbu82M-J2hbM->M-nYM-VAdM-?BM-UM->M-nWwM-fM-RM-LxbM->M-X5M-RM-mfM-d9ZJx6M-}M-dM-QM-byaiqaSgM-AMnM-^WydtM-we.M-ZG.tunnel.~~l0m~~.de.		0ebbu82M-J2hbM->M-nYM-VAdM-?BM-UM->M-nWwM-fM-RM-LxbM->M-X5M-RM-mfM-d9ZJx6M-}M-dM-QM-byaiqaSgM-AMnM-^WydtM-we.M-ZG.tunnel.mydomain.com.

	0ibbv82M-J2hbM->M-nYM-VAdM-CBM-?M->M-nWwM-fM-R2xbM->M-X5M-RM-mfM-d9ZJx6M-}M-dM-QM-byaiqaSgM-AMnM-^Wydule.M-ZG.tunnel.~~l0m~~.de.		0ibbv82M-J2hbM->M-nYM-VAdM-CBM-?M->M-nWwM-fM-R2xbM->M-X5M-RM-mfM-d9ZJx6M-}M-dM-QM-byaiqaSgM-AMnM-^Wydule.M-ZG.tunnel.mydomain.com.

	0mbbw82M-J2hbM->M-nYM-VAdM-CBM-WM->M-nWwM-fM-RM-dxbM->M-X5M-RM-mfM-d9ZJx6M-}M-dM-QM-bzaiqaSgM-AMfM-^WyduNe.M-ZG.tunnel.~~l0m~~.de.		0mbbw82M-J2hbM->M-nYM-VAdM-CBM-WM->M-nWwM-fM-RM-dxbM->M-X5M-RM-mfM-d9ZJx6M-}M-dM-QM-bzaiqaSgM-AMfM-^WyduNe.M-ZG.tunnel.mydomain.com.

	0qbbx82M-J2hbM->M-nYM-VAdM-EBM-YM->M-nWwM-mrM-VUdbM-rM-qPM-\lM-LM-dM-SmaM-BIM-]8M-lWM->qGaM-VmgM-FM-fM-_M->M-^dM-Jnf.Ca.tunnel.~~l0m~~.de.		0qbbx82M-J2hbM->M-nYM-VAdM-EBM-YM->M-nWwM-mrM-VUdbM-rM-qPM-\lM-LM-dM-SmaM-BIM-]8M-lWM->qGaM-VmgM-FM-fM-_M->M-^dM-Jnf.Ca.tunnel.mydomain.com.

	0ubby82M->tM->dpM-}aabacuaaAXM-uKabagM-@MHGaaeM-jM-VM-[M-uM-Yjyd7zCjM-\HM-ILM-_M-YGcahM-}FM-Ea.aaqiGvM-}M-}M-`BM-EM-BM-_M-ZM-PM-oAM-`M-DM-v.tunnel.~~l0m~~.de.</code>		0ubby82M->tM->dpM-}aabacuaaAXM-uKabagM-@MHGaaeM-jM-VM-[M-uM-Yjyd7zCjM-\HM-ILM-_M-YGcahM-}FM-Ea.aaqiGvM-}M-}M-`BM-EM-BM-_M-ZM-PM-oAM-`M-DM-v.tunnel.mydomain.com.</code>

LauraW at 09:41, 12 October 2017

2017-10-12T09:41:53Z

Show changes

LauraW at 09:01, 12 October 2017

2017-10-12T09:01:14Z

← Older revision		Revision as of 09:01, 12 October 2017
Line 9:		Line 9:
	However, it can not receive and send packets, since a firewall on the access point drops all outward packets. (In detail, this means that the access point does not reject the connection by sending RST packets, but completely ignores the connection. For Iptables, this is equivalent to the "DROP" statement.) There is an exception to this categorical rejection these are connections on port 80 (HTTP). All HTTP requests are intercepted by the access point via a transparent HTTP proxy and the requests are transferred to a web page of the Wlan provider. The normal customer notices this by entering the browser, entering an arbitrary domain, and instead of the expected website, the web page of the provider appears, usually with a login option and instructions for payment.		However, it can not receive and send packets, since a firewall on the access point drops all outward packets. (In detail, this means that the access point does not reject the connection by sending RST packets, but completely ignores the connection. For Iptables, this is equivalent to the "DROP" statement.) There is an exception to this categorical rejection these are connections on port 80 (HTTP). All HTTP requests are intercepted by the access point via a transparent HTTP proxy and the requests are transferred to a web page of the Wlan provider. The normal customer notices this by entering the browser, entering an arbitrary domain, and instead of the expected website, the web page of the provider appears, usually with a login option and instructions for payment.

	[[file:Eudoramsetup.png]]		[[file:Eudoramsetup.png\|350px]]
	[[file:Telekomhotspot.png]]		[[file:Telekomhotspot.png\|450]]

	But the client can still communicate with the local DNS server. DNS, the service that resolves domain names into IP addresses, is integrated into the access point for most of the wisans. And for all tested wlans, it also resolves names for non-authentic clients, so you can already send DNS queries before paying or logging in. And since the DNS server needs to communicate with other DNS servers out there, a communication channel is created that can be used for tunneling.		But the client can still communicate with the local DNS server. DNS, the service that resolves domain names into IP addresses, is integrated into the access point for most of the wisans. And for all tested wlans, it also resolves names for non-authentic clients, so you can already send DNS queries before paying or logging in. And since the DNS server needs to communicate with other DNS servers out there, a communication channel is created that can be used for tunneling.
Line 122:		Line 122:
	We actually did manage to circumvent the login portals of eduroam and two different vodafone hotspots (located at S Adlershof and S Köpenick).		We actually did manage to circumvent the login portals of eduroam and two different vodafone hotspots (located at S Adlershof and S Köpenick).

	[[File:Adlershof.jpg\|500px]][[File:Connected.jpg\|650px]][[File:Koepenick.jpg\|~~800px~~]]		[[File:Adlershof.jpg\|500px]][[File:Connected.jpg\|650px]][[File:Koepenick.jpg\|600px]]
			[[File:Eudoroam.png\|600px]]

	== Metrics ==		== Metrics ==

LauraW at 21:19, 11 October 2017

2017-10-11T21:19:51Z

← Older revision		Revision as of 21:19, 11 October 2017
Line 17:		Line 17:


	[[file:IPoverDNSPrinciple.png]]		[[file:IPoverDNSPrinciple.png\|500px]]


Line 116:		Line 116:

	or just restart your networking manually by using the network manager or restart the device entirely.		or just restart your networking manually by using the network manager or restart the device entirely.


			== Trying it out ==

			We actually did manage to circumvent the login portals of eduroam and two different vodafone hotspots (located at S Adlershof and S Köpenick).

			[[File:Adlershof.jpg\|500px]][[File:Connected.jpg\|650px]][[File:Koepenick.jpg\|800px]]

	== Metrics ==		== Metrics ==

LauraW at 21:08, 11 October 2017

2017-10-11T21:08:30Z

← Older revision		Revision as of 21:08, 11 October 2017
Line 16:		Line 16:
	The attacker just needs to set up their own domain (say, "mydomain.com") with their own authoritative nameserver that resolves queries for "anysubdomain.mydomain.com". Now, when the DNS resolver of the restricted network gets a request for those subdomains, it sends the request to the authoritative nameserver. Encoded in this request, more specifically, in the subdomain, is the IP packet that goes out. The autoritative nameserver can access the internet himself, acting as a proxy, get the answer and encode it in a DNS NULL or TXT or any other large DNS record type, and send it back to the DNS resolver which will hand the answer to the client. Now the client has sucessfully communicated with the outside world.		The attacker just needs to set up their own domain (say, "mydomain.com") with their own authoritative nameserver that resolves queries for "anysubdomain.mydomain.com". Now, when the DNS resolver of the restricted network gets a request for those subdomains, it sends the request to the authoritative nameserver. Encoded in this request, more specifically, in the subdomain, is the IP packet that goes out. The autoritative nameserver can access the internet himself, acting as a proxy, get the answer and encode it in a DNS NULL or TXT or any other large DNS record type, and send it back to the DNS resolver which will hand the answer to the client. Now the client has sucessfully communicated with the outside world.


	(to be continued)
			[[file:IPoverDNSPrinciple.png]]



	== Anleitung ==		== Anleitung ==
Line 86:		Line 89:

	<code>route add -host [DNS server IP] gw [gateway IP]</code>		<code>route add -host [DNS server IP] gw [gateway IP]</code>

			[[File:SetupIPoDNS.png\|1000px]]

	==== Put a ssh tunnel through the dns tunnel for encryption ====		==== Put a ssh tunnel through the dns tunnel for encryption ====
Line 114:		Line 119:
	== Metrics ==		== Metrics ==

	Of course, tunneling IP over DNS does not allow for a very impressive ~~bandwith~~.		Of course, tunneling IP over DNS does not allow for a very impressive data rate.

	[[File:Speedtest1.png]]		[[File:Speedtest1.png]]

LauraW: /* How it works */

2017-10-11T12:53:06Z

How it works

← Older revision		Revision as of 12:53, 11 October 2017
Line 5:		Line 5:

	== How it works ==		== How it works ==

		⚫	A large part of the Wlan solutions in use is initially an open, unencrypted WLAN, which in most cases is named after the provider or the location or the hotel name. If the attacker, which at this point still acts as a normal customer, now works its network card to this WLAN and sends a DHCP request, it receives from the access point a local LAN-IP address.
		⚫	However, it can not receive and send packets, since a firewall on the access point drops all outward packets. (In detail, this means that the access point does not reject the connection by sending RST packets, but completely ignores the connection. For Iptables, this is equivalent to the "DROP" statement.) There is an exception to this categorical rejection these are connections on port 80 (HTTP). All HTTP requests are intercepted by the access point via a transparent HTTP proxy and the requests are transferred to a web page of the Wlan provider. The normal customer notices this by entering the browser, entering an arbitrary domain, and instead of the expected website, the web page of the provider appears, usually with a login option and instructions for payment.

	[[file:Eudoramsetup.png]]		[[file:Eudoramsetup.png]]
	[[file:Telekomhotspot.png]]		[[file:Telekomhotspot.png]]

			But the client can still communicate with the local DNS server. DNS, the service that resolves domain names into IP addresses, is integrated into the access point for most of the wisans. And for all tested wlans, it also resolves names for non-authentic clients, so you can already send DNS queries before paying or logging in. And since the DNS server needs to communicate with other DNS servers out there, a communication channel is created that can be used for tunneling.
⚫	A large part of the Wlan solutions in use is initially an open, unencrypted WLAN, which in most cases is named after the provider or the location or the hotel name. If the attacker, which at this point still acts as a normal customer, now works its network card to this WLAN and sends a DHCP request, it receives from the access point a local LAN-IP address.

⚫	However, it can not receive and send packets, since a firewall on the access point drops all outward packets. (In detail, this means that the access point does not reject the connection by sending RST packets, but completely ignores the connection. For Iptables, this is equivalent to the "DROP" statement.) There is an exception to this categorical rejection these are connections on port 80 (HTTP). All HTTP requests are intercepted by the access point via a transparent HTTP proxy and the requests are transferred to a web page of the Wlan provider. The normal customer notices this by entering the browser, entering an arbitrary domain, and instead of the expected website, the web page of the provider appears, usually with a login option and instructions for payment.
			The attacker just needs to set up their own domain (say, "mydomain.com") with their own authoritative nameserver that resolves queries for "anysubdomain.mydomain.com". Now, when the DNS resolver of the restricted network gets a request for those subdomains, it sends the request to the authoritative nameserver. Encoded in this request, more specifically, in the subdomain, is the IP packet that goes out. The autoritative nameserver can access the internet himself, acting as a proxy, get the answer and encode it in a DNS NULL or TXT or any other large DNS record type, and send it back to the DNS resolver which will hand the answer to the client. Now the client has sucessfully communicated with the outside world.

	(to be continued)		(to be continued)