We covered the Newstweek, a wall-wart sized box that injects fake news stories over public WiFi connections last February, but now there’s a great walk through and it seems our doubts about this project were disproved.

The Newstweek uses ARP spoofing to change the text displayed on several news sites. After doing some field research, placing and configuring the device, there’s a simple web frontend that configures the man-in-the-middle hack. Right now, the Newstweek only allows a few news sites to be targeted, but the team is working on allowing anyone to add their own targets.

Aside from the relatively simple build, we’re wondering about the social engineering aspects of the Newstweek. In our previous coverage of the Newstweek, we couldn’t decide if this was a social commentary art project, or a real device. It looks like it’s both now. Would hackaday readers succumb to injecting, “President Bacon addressed the nation last night…” or would you do the responsible thing and put the “(D)s” and “(R)s” in their proper places?

The Newstweek team posted a video of a short demonstration, but check out the video after the break for the “incredibly geeky and thorough demo.”

Bring on the lulz…
That has to potential to be wonderfully disruptive, especially if the feed that’s being ‘got at’ is the one a journalist is reading so they did the hard work for you with a little comedy of your choosing…

LOL; as I was watching one of the videos I was thinking to myself it needs an AC power pass through, as not to hog a recp & getting unplugged. About that time someone plugged a carpet sweeper into one. That was before I found the parts list.

Certainly hacking, and on several levels what to call it beyond that I don’t know.

Also potentially disruptive, but will take a lot of long term dedication on the part of those creating similar networks to keep the faux news current with current issues. I have to admit I’m not entirely sure how the newstweek network functions. Not to mention keeping the hardware on locations as knowledge of this gets out. This is being described as an “art” project maybe they don’t intend any long term maintenance by the creators. The user of free hotspots who don’t do so know will of the learn to pay attention to the SSDI of the wifi connection they are using. That alone will have the appliance users calling for the heads of the spoofers.

That is correct, i have several ettercap filters that i wrote that does exactly that. It can intercept on any TCP /UDP connection. Meaning it can be used on more than just http requests. Mine was set to work with AIM. Once the user sent out a packet it was manipulated so the receiver saw a totally different message. Same thing happened on incoming messages.

Here are a couple of options on how to defeat this thing (ordered easiest to hardest, least effective most effective):

1: You can use HTTPS whenever possible. Some sites (like Google Reader) will work through HTTPS. Since the SSL/TLS mechanism used by HTTPS provides end-to-end encryption and integrity checks, it would be impossible for this thing to work without a spoofed SSL cert. Just be careful not to accept any new certs when visiting the sites and make sure to check to make sure you’re on an HTTPS-based webpage before accepting any news you get form it.

2: Tunnel your browser connection through an SSH-based SOCKS proxy. There are plenty of instructions on the web on how to do this. Basically, you set up an SSH tunnel to a remote machine and then pipe all your web traffic through it. This won’t help if the remote machine is being victimized, but if that machine is on a wired connection at your house, then it’s far less likely to be attacked in this way. This will even protect you when using sites that don’t offer HTTPS.

3: Use a VPN. A VPN works like #2 but will help to make sure all traffic (even non-HTTP) traffic gets encrypted and validated. So this is the best option if it’s available to you.

All of these methods also protect against FireSheep and other forms of attack based on the complete lack security around HTTP.

you can strip the SSL encryption request on the outgoing packet. This will send all information in plain text.

Same thing with the SSH connection. Since the MITM attack can manipulate any protocol it is possible to strip the request for encryption causing the incoming packet to be in plain text. They also have SSL Strip, which will do the same thing without a filter.

If you want to really secure this you can configure the router to reject duplicate IP’s. This is how the MITM attacks are performed by having the host (the box plugged into the wall) act like the router and manipulate the information that is passed through it.

This is nothing new. I worked for a company which provided IT services for various government agencies like the AF and DOD and 10 years ago someone came in and demonstrated a product like this. The device was designed to be installed at the ISP level, but could be used at individual locations of a company/agency and then any data could be changed on any website or email.

If you think you can trust information on the web, you are sadly mistaken. The government has complete control.

That router needs 5W to run; 1.5A of 3.3V. Why make this plug in? Seems to me it’d be trivial to build into a thick Frisbee-style disc with a solar panel on top. Network penetration by tossing a toy on a roof.

I hadn’t heard of the method of stripping the HTTPS from the request. I’m really not sure how that would work. If the browser is expecting the request to be HTTPS, it will initiate a connection to port 443 to send the request and initiate the SSL connection before it even sends the header. So that would probably prevent such an attack from working because the request headers are never sent in the clear over the network.

That sort of attack MAY work if you’re on an HTTP page and expecting a link to take you to an HTTPS page (such as with many sites that have logins on their HTTP pages that are supposed to post to their HTTPS sites). Of course, if you explicitly type the address (e.g. “https://reader.google.com”) into your browser (as I recommend), that sort of attack wouldn’t work.

Any sort of MITM attack with SSH or HTTPS would have to attack those protocols and/or the implementation of those protocols in order to succeed. So it would take an entirely different (and FAR more sophisticated) kind of attack for that to actually work.

So I still feel pretty confident that all three of my methods would be effective to varying degrees. The VPN and SSH-tunneling methods should be nearly fool-proof against this sort of attack (assuming users don’t accept fraudulent SSL certs or host identifiers).