Implementation of the attack

Figure: The scenario used for the real life implementation of the attack described in section 11.2.1. Node B has Internet connectivity and declares itself as a HNA gateway to the Internet.

To do a real-life version of the attack described in section 11.2.1, a very simple scenario was set up as illustrated in figure 11.1. The rouge node B announces Internet connectivity so that A will route all its Internet traffic to B. B wants to intercept all traffic to the geek news-site http://www.slashdot.org. B issues a DNS query for www.slashdot.org and receives the IP address 66.35.250.150. Node B running GNU/Linux sets up a virtual interface eth0:1 and assigns it the address 66.35.250.150. Then B starts a local HTTP-server. When node A now points its web-browser to http://www.slashdot.org its DNS query will result in 66.35.250.150 and a HTTP GET command is sent to that address. The HTTP query will be received by node B, and B will not forward the traffic. B recognizes the TCP connection to be destined for itself, so B will be the actual end host on the TCP session. B then serves a fake web page to A. A screenshot of the result is shown in figure 11.2.

Figure: What node B in the scenario from figure 11.1 sees when requesting http://www.slashdot.org in its local web browser. This is obviously a forged version of the real slashdot page. Note the hostname in the address bar.

While this particular attack did not do to much harm, but one can imagine an attacker acting as a proxy to much more sensitive services, such as on-line banking. Even though such services usually are protected using Secure Socket Layer(SSL)[16] or Transport Layer Security(TLS)[29], users will often not have the knowledge to detect a phony certificate or the lack of SSL/TLS encryption.