I recently received a new Anonabox – one with WiFi security – and have performed a very quick analysis of the security.

In summary, it’s nowhere near as bad as the first revision, but there are still so many mistakes and odd aspects to the configuration that I cannot possibly recommend anyone uses it.

Positive – all traffic is routed over Tor with no DNS leaks

Setting up Wireshark on the WAN side of the device shows that all traffic ends up on Tor. If the traffic cannot be routed over Tor, it is blocked.

This means the device is performing the key part of the advertised functionality (even if, personally, I feel that Tor is not a good solution for the man on the street).

Positive – the WiFi is secured

The device has a 24 character long WiFi password and uses WPA2.

This means that the WiFi side of the device is now secure.

In reality, this is an excessively lengthy password, and not allowing it to be changed is a serious negative. Lose the bit of paper they give you with the password, and it is game over.

Positive – the root account no longer has a default password of admin

Looking at /etc/shadow, they have removed a password from the root account:

root@anonabox:/etc# cat /etc/shadow
root:*:0:99999:7:::
daemon:*:0:0:99999:7:::
ftp:*:0:0:99999:7:::
network:*:0:0:99999:7:::
nobody:*:0:0:99999:7:::
tor:x:0:0:99999:7:::

This is better.

Negative – running an open web config interface on WLAN with no password

For whatever reason, only on the WLAN side (i.e. not LAN), you can connect to the OpenWRT web config interface using the IPv6 link local address.

Because the root password has been removed from the device, this means that the web interface now has no password whatsoever.

This means that anyone who uses the WiFi can reconfigure the device.

Negative – running ssh server on a random port (but no way of logging in)

On the WLAN side, again on the IPv6 link local address, dropbear (a small SSH sever) is running on a random port.

They have turned off password authentication, so only public key authentication could be used. There are no keys stored on the device, so there is no way to login.

Why then are they still running dropbear? Don’t run services you don’t need. A vuln in dropbear could be exploited.

Negative – serial console access gives a root console

There are three pins on the board that allow you to access a root console with no password.

A lot of embedded systems do this, but for a truly secure system, this should be entirely disabled, made output only, or at least secured with a password. I regularly see all three methods used on production boards. An end user is never going to use the serial console.

This also doesn’t align with the spin Anonabox are putting out – if you leave the device unattended you can no longer trust it.

Negative – use of public IP range for private network

There are reserved addresses for use behind NAT to avoid routing issues.

For whatever reason, Anonabox instead uses 126.0.1.0/24 and 126.0.2.0/24. This is a range used by Softbank.

This causes a number of issues – if you port scan your gateway, you in fact port scan a Softbank machine. If you want to access one of Softbank’s machines, who knows what will happen with the routing (because, as and end user, you cannot inspect the routing and firewalling).

Negative – no way of an end user to confirm Tor is in use

Most Tor routers and Tor software has a UI allowing a user to confirm that traffic is, in fact, going over Tor.

You have no way of telling if the Anonabox is working short of inspecting traffic. This isn’t good.

Negative – no means to change settings or update firmware

This is probably one of the biggest issues. If we ignore the open web interface mentioned above, you cannot change anything on the device without using a serial console. If you ignore the serial console (because most people won’t have the facility to use this), then you cannot change anything on the device.

• Mistake in configuration e.g. firewalling – you are out of luck.
• Serious vulnerability – no way of updating the firmware.
• Lose your WiFi password – no way of finding it out.
• Give your WiFi password to someone you no longer trust – no way of revoking access.

This is not a good thing even if they spin it as a plus. A competitor, Invizbox, have already put out two firmware updates in response to feedback.

Negative – strange, non-standard MAC address on WAN port

The MAC addresses of all the devices I have seen begin OC:EF:AF.

This doesn’t seem to be registered with the IEEE, making it a strange choice.

Beyond this though, plug this device into a corporate network, hotel, or anywhere else, and the network admins will instantly be able to tell you are using an Anonabox.

On a device that is being pitched as so secure, it should allow the MAC to be changed or even randomised each time it is plugged in.

Negative – openwrt leaks NTP requests so you can identify a router is connected

Again, for a privacy/anonymity device, you often want to hide the fact you are using it from your carrier. When the box is plugged in, it performs the default action of connecting to an openwrt NTP server. It’s obvious openwrt is in use – this should be blocked.

Negative – the config is all over the place

The whole thing is an openwrt router with some minor config changes. The changes that have been made seem amateurish and inconsistent. They are clearly not experts at this.

Conclusion

It kind of does what it should do, but does so many bits so badly that there is no way I would trust or recommend it.

It’s a given that manufacturers will make mistakes.

Anonabox have made mistakes.

One of those mistakes is making it impossible to fix the mistakes they have made.