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


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.


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 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 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.


16 thoughts on “Calling Bullshit On The Newstweek Hoax

  1. Pingback: Hertzian Hacktivism «

  2. May a DHCP-attack work? I could imagine, if the newstweek-device bounds itself to all available IP-adresses in DHCP-range (via virtual interfaces, different mac-adresses), the orignal router would return a DHCP-NACK to every new user, while the newstweek-device could send an DHCP-ACK – assuming there won’t be an error at client-site, now the newstweek-device can route and manipulate all the traffic via regular uplink or may as well use Tor.


    • Sounds like that might work. It’d probabably need a beefier piece of kit to load a hypervisor etc, as I think you can only bind 4 virtuals to a native Linux eth port.

      That said, in order to work, the device would have to issue a new default gateway IP to DHCP clients e.g the 121 address, from which it could forward requests to the .1 address.

      Masquerading as the .1 address would still conflict with the router’s interface IP, which cannot be changed (without the router’s admin credentials) and is not subject to a DHCP attack.

      What might be interesting is for the device to set itself up as an IPv6 gateway, attracting traffic from Windows & Mac (and Linux?) clients.

    • A further thought. If I was configuring a wireless router for a public hotspot, with a high turnover rate of clients, I’d think about two things:

      1) How large a DHCP range would I want? I’d probably want more than a /24.
      2) And/or a very short DHCP lease time.

      Both of these would add challenges to the DHCP hack proposed.

    • That’s quite an eye-opener.

      It could possibly would work, as described here:

      Nevertheless, the demo in this case, does not show the ARP cache poisoning vis MAC address change.

      I’d also be interested to know if the spoofed ARP packets received by the Windows machine would be acknowledged and overwrite the genuine ARP record, if the Windows machine already had an established IP conversation with the router.

      It’s tempting to set up a proof of concept.

    • and the packet filter described here:

      … could do modification of strings in HTTP packets.

      It’d be limited in scope and throughput though, I’d expect. Not very dymanic, so better employed for modifying underlying data, such as HTTP GETs and POSTs.

      The DNS_Spoof plug in could also be used for some interesting mischief.

  3. I think itś pretty safe to say after findings here and my own research that the site itself is a hoax (called “newstweek” after all) but the device isnt .

    Looking around, all the technology they are using checks out, right down to the version of libpcap they have on the machine.

    ARP Spoofing has been around for years. Sure the weirdness with the arp table coming up unchanged for the gateway MAC was weird in the first video but I have seen this happen in the past with the arp when you don´t wait for resolved hostnames (no idea why). Anyway, why would they show that in the video after describing ARP spoofing in the diagram, to discredit themselves? The second video they made is pretty clean and would be proof enough for any good security prof I think.

    They have built the weird newstweek rip off site to promote the project, playing with the idea of tweaked news to get their message across: “The technology is out there. Itś scary. Here´s how to build it”

  4. Oh behave. I’ve not been proven wrong.

    This is a hoax.

    Yes, what it purports to be is technically possible, but putting an alarm clock with some wires on a bus isn’t the same as including a kilo of semtex, is it?

  5. I thought you were misguided. Now I wonder how often you have been criticizing other people’s projects just because you’re not up to date with the stuff and you are too arrogant to admit it.

    It is, indeed, disappointing. I thought you were cool.

    In any case, your ignorance will eventually catch up with you. The device works exactly as it sais it does. I have seen it, along with another 150 hackers, in the geekiest event in europe. You can keep foaming for as long as you want.

    so long, Al Jahom

    • fair enough.

      Perhaps you could explain why the video doesn’t show the hack working as described?

      Is there another video, that shows an actual ARP cache poisoning?

      • I have no idea why the other video doesn’t show ARP poisoning. This video does:

        They said they will publish the whole howto very soon. I assume anyone interested should be able to test it at home, or anywhere else.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.