Calling Bullshit On The Newstweek Hoax

If you’re not a geek, move along.

It’s become apparent this this whole thing is some kind of art project. I guess this what happens when geeks read about situationism. My reason for writing this (apparently futile) takedown of the ‘spoof’ is that I’m fairly sure that, sooner or later, some dullard in the UK mainstream media will get all shouty and panicky about this insidious new ‘device’. As you were.

There’s a thing doing the rounds today. I saw it via @LossOfPrivacy on Twitter.

 

The site detailing this gadget is here.

The story goes that:

When plugged in the device boots up automatically, looking for an open wireless network or any network for which it already has a password – something often given for the price of a coffee. It then reverse SSH tunnels (using SSH keys) to a foreign server, allowing a remote user on that server to SSH back into the machine from afar, issuing commands as they see fit.

This however is just the beginning.

The device then performs a sophisticated modification of the Address Resolution Protocol (ARP) Table on both the hotspot hardware and the clients associated with it. These include iPhones, Android devices and laptop computers.

There’s some irrelevant shell scripting smokescreen.

And there’s a neat Visio diagram that would have taken 2 minutes to put together from stock elements.

Now to call

BULLSHIT.

First, go and click through to the article and view the video clip. (Sadly, I can’t embed Vimeo)

Now, with reference to the diagram above, they claim that:

1) The device when plugged in, powers up and attaches to any open WiFi network, or any it knows passwords for. This is perfectly feasible.

2) That the device alters the ARP table on the WiFi router, and on other devices on the network. It is possible to spoof ARP responses, thus poisoning the ARP cache on devices, but it is not possible to stop the genuine device responding to the ARP request and pre-empting or overwriting the response issued by the rogue device. The result would be a collapse of the Wifi network in chaos.

3) That the rogue device is able to supplant an established WiFi network for existing clients. This is not going to be possible, because the client devices already HAVE the genuine ARP entry for the WiFi router in their ARP cache and will not, therefore issue an ARP request for several minutes, and only then after a period of making no internet requests.

Indeed, if you watch the video, you will see that the ARP entry for the default gateway in the cache shows exactly the same MAC address before and after.

4) That the rogue device acts as a transparent (if transformative) proxy. Yet, if the rogue device were to succeed in poisoning ARP caches and hijacking the IP address of the WiFi router, how exactly would it then forward requests for content to the internet, being as the rogue device, itself, is masquerading the IP address by which it would otherwise need to connect to for web access.

In summary, then, this ‘hack’ is not feasible, and if it could be implemented, it certainly would not be reliable, and would in most likelihood, if it did anything at all, just wreck the WiFi LAN until it was removed.

I’m happy, as ever, to be proved wrong.

AJ

UPDATE: It has been suggested to be that the notes beneath the video on this page explain the ARP results.

Again, I call BULLSHIT.

Those notes say:

This video demonstrates the technology behind this hack.

Two points:
1/ You will notice in the video, when we plug the device into the wall it takes a while to boot before the traffic is altered.

Innocuous, true and meaningless… carry on…

2/ We issue the ‘arp’ commands as forensic proof that the network layout was modified. As the spoofing uses ‘remote’ we are poisoning the gateway router who’s own arp table we cannot (and don’t need to see). With the second issuing of the command however, we see a new device in the arp table (the Newstweek module) that wouldn’t normally be seen without spoofing. This is the device through which traffic between router and client is passed. Note also that immediately after spoofing, the arp command can’t retrieve the hostnames, hence the "?".

Err no.

Two things.

1) We can clearly see that the MAC address against 192.168.12.1 does not change between  the before and after arp commands. This directly contradicts their explanation of how this ‘hack’ works.

2) The explanation for the “?” seen against the entries on the second arp command is the use of the ‘n’ switch, which is not used in the ‘before’ example.

This Laptop is running Ubuntu. The Ubuntu Man page for arp tells us that:

-n, –numeric shows numerical addresses instead of trying to determine symbolic host, port or user names.

The ‘n’ switch deactivates looking up the host names (‘wrt’ in the ‘before’ entry), not looked up in the ‘after’ entry, therefore the column entry is replaced by a ‘?’.

3) The 192.168.12.121 address appears in the ARP table of the laptop. This may be the IP address of this rogue device. It could have got into the ARP table of the laptop by a script running in the background on the laptop, continually pinging the 121 address. Or the rogue device could be running it’s WLAN interface in promiscuous mode, sniffing the laptop’s IP then pinging it. This would also put the 121 entry in the laptop’s ARP cache. This is someone unlikely, but it COULD be achieved by the device during the 15 seconds after it’s plugged in.

One last thing. In the video, we don’t see what keypresses are make on the laptop just before the refresh. This could have been a macro that was invoked to, eg, change the proxy settings in the browser, possibly even to point to a local proxy setup for the purpose. It’s all easy to do.

BTW, The MAC against the router belongs to a Cisco/Linksys device. The one allegedly belonging to the rogue device is for a ‘PLANEX Communications’ device. They make all kinds of wireless device chips, e.g. USB dongles, but it’s impossible to say what the device using that IP address is with any kind of certainty. It could be this rogue device, but that doesn’t mean anything.