Last month at the FOCI workshop, we presented a security analysis of the Safeplug, a $49 box which promised users “complete security and anonymity” online by sending all of their web traffic through the Tor onion routing network. Safeplug claims to offer greater usability, particularly for non-technical customers, than the state-of-the-art in anonymous Internet browsing: the Tor Browser Bundle (TBB). However, we found that the hardened browser in the TBB is very important for security, and we found a number of usability and security problems with the Safeplug, including the ability for a local or remote attacker to silently turn off Tor or modify other device settings. Our research concluded that users should run the Tor Browser Bundle if they can; if not, then there is some value in a torifying proxy like Safeplug as long as users are aware of its limitations. For the rest of this post I’ll review our findings and highlight the differences and tradeoffs between the Tor Browser Bundle and a torifying proxy, like the Safeplug.
The Safeplug. It’s a small black box that plugs into a user’s router and acts as an HTTP proxy that sends all Web traffic through Tor, which anonymizes the “from” IP address of the user’s traffic. The figure above shows the setup directions that come with the device; the company that makes the device, Pogoplug, emphasizes an easy installation and setup process and then the user can “Browse the Internet with complete security and anonymity.” It is marketed as a consumer product for non-technical users and for a broad set of devices. The Safeplug costs $49 and was released in December 2013.
Usability. We found that the activation and setup processes were simple and easy to navigate, but both the Terms of Service and the Safeplug settings page needed more information. First, we noticed that Pogoplug did not include Terms of Service in the box with the Safeplug or as a step in their activation process, and they also have a broken link to the page that fulfills their compliance with open source licenses by listing all of the open source software they use (such as Tor). Next, we looked at the settings page, which is shown above. This page gives the user the option to turn Tor on/off, add sites to a whitelist that don’t get routed through Tor, turn ad blocking on/off, and turn the Safeplug into a Tor relay. When the relay option is selected, an additional setting is available: the ability to turn the relay into a Tor exit. Unfortunately, virtually no information is provided to the user about what a relay or exit node is, meaning that users could turn on the exit option without being aware of the complications with their Internet Service Provider or other parties that may result.
Attacks. First, it’s important to understand a key problem in the implementation of the Safeplug: there is no authentication when a user modifies the settings page. As shown in more detail in the diagram above, when the user modifies the settings page, the user’s browser generates a POST request that causes a shell script on the Safeplug box to launch a binary file that updates the Safeplug’s configuration. This allows a malicious user inside the local network to silently modify the settings – they can turn Tor on/off, add/remove sites from the whitelist, etc. This attacker has two ways of doing this. Because the settings page is served by the Safeplug box over HTTP, the attacker can open the page in his browser and modify the settings there, or he can directly send the POST request, meaning that this attack can be done from a compromised embedded device, such as a router. This is an example of why the Safeplug should not be used on an open Wi-Fi network. Unfortunately, a remote attacker can also modify the settings by carrying out a Cross-Site Request Forgery attack. This is done by making the victim’s browser send a request to the Safeplug without the user knowing anything is happening. The attacker creates a website that has JavaScript code to generate the specially crafted POST request, which is sent to all the IP addresses in the common ranges of home networks. Then, the attacker embeds the link in a page that will be served to a user inside the targeted network, and once the user clicks the link, the settings are modified however the attacker intended.
Miscellaneous Security Problems. As we analyzed the device, we found a few other security problems. All Safeplug devices have the same 7-character SSH root password (thanks to someone on the tor-talk mailing list for first confirming this issue), and SSH is one of the settings that can be enabled via the unauthenticated RPC calls discussed above. Anyone who learns the root password can make arbitrary changes to the device’s behavior. Next, the device is using old software versions (including versions that were obsolete before the product was released), so a natural solution would be a software update, but there have not been any software updates for the device since it was released. Additionally, the initial installation process of the software (Tor, Privoxy, etc.) is done via a script which is downloaded over unencrypted HTTP. There is no authentication or verification of this script before it is run, which could allow an attacker at the right moment to take complete remote control of the Safeplug, possibly turning it into a surveillance box inside a user’s home network.
Is there hope for Torifying proxies? It’s clear that there are some necessary engineering and implementation fixes to the Safeplug, such as authenticating configuration changes and CSRF protections. Pogoplug should also change the common SSH root password. But there are also structural problems with the Safeplug, specifically with the way it works – as a torifying proxy. One problem is specific to mobile devices, which might leak some traffic over the cellular network when the user thinks they are using Tor over wi-fi. We are also concerned that leaks like this may also facilitate de-anonymization of the user’s Tor traffic. However, the most crucial problem with a torifying proxy is that it uses a bring-your-own-browser system, as opposed to a hardened browser, and therefore is susceptible to browser-based privacy leaks (via cookies, fingerprinting, scripts, etc.). This is why it’s better to use the Tor Browser Bundle, but if a user’s device cannot use the Tor Browser Bundle, then there is some value in using a torifying proxy like the Safeplug (but only if it is secure).
Actually when someone doesn’t know afterward its up to other users that they
will help, so here it happens.
You really makee it seem so easy with your presentation but I find this topic to
be really something that I think I would never understand.
It seems too complicated and extremely broad for me.
I am looking forward for your next post, I will try too get the hang of it!
It seems that are too many weakness to be considered before one uses it
PORTAL seems to be a better alternative
I would be interested in product that does not act as a HTTP proxy, but transparently routes all TCP connections through Tor, such that even an adversary who has compromised by computer cannot find out my IP.
While doing so might be tricky transparently, you could actively block all non-tor related connections with a pfsense box. That way the only thing that gets out is tor traffic.
The ‘Onion Pi’ project shows you how to turn a raspberry pi into a wi-fi router that sends all TCP traffic through Tor. Unfortunately it requires a lot of effort to set up, and I experienced a known bug where high Ethernet traffic causes the USB port to crash.
Check out Whonix