Android privacy and security: Inversion of control

Android privacy: is it a joke or the punchline?

All technical Android users are aware of the problem. You want to install a simple app, such as a Torch, but you’re greeted with this:

This torch app "only" requires access to your flash, personal files, phone calls, location and identity...

This torch app “only” requires access to your personal files, phone calls, location and identity… and of course the actual camera flash itself, which seems like more of an afterthought.

Likewise, the common Facebook Messenger app is also rather greedy with permissions:

Screenshot_2015-04-07-10-22-57

Actually, there’s a little more to it than that. An update to the Google Play Store makes app permissions more “user friendly” by hiding the extent that the application wants to access your personal data. On an older version of Play Store, the permissions for Facebook and Messenger read more like this:

Google have actively tried to obfuscate the extent to which they allow their own and 3rd party software to violate privacy of Android users. I use the Facebook apps as an example here, but there are plenty of other widely-used invasive apps around (Google’s own in particular).

How does this extreme cyberstalking survive

This survives the same way that Apple products do, given their terms and conditions… Users either don’t notice the invasive terms that they’re agreeing to, or they don’t realise the consequences of them.

Even if you don’t install these malicious apps, your communications are insecure. If any of the people who you communicate with have a spyware-laden app, it can see both sides of the conversation between you and that person. Android/iOS privacy violation operates in a similar way as herd-immunity, but for the worse instead of for the better.

So what can be done about it

By Google? Nothing, it’s their business model after all:

  1. Mine as much personal information as possible from anyone and everyone
  2. ???
  3. PROFIT!!

* ??? = target advertisements

By free open-source mods and ROMs (e.g. Cyanogen)? Plenty.

The Xposed module “App Settings” allows one to revoke permissions from an app, often causing it to crash when it attempts to use that permission.

This is an “opt-in” security measure in the sense that one must actively revoke the permission after installing the app. As an anecdote, when revoking Facebook Messenger’s ability to monitor the screen contents, I noticed that Messenger would crash (“Forced Close”) whenever I opened a WhatsApp conversation. This was before Facebook bought WhatsApp of course.

But the problem is that security and privacy are still on an opt-in per-app basis.

Inversion of control: Power to the user

By default, our system allows malicious spyware and trojans to act as soon as we hit “install”, then we must manually disable them afterwards. Disabling them may also cause the app to crash frequently, making the part of it that’s actually useful now inaccessible. What we need is an inversion of control – instead of the permissions being “All or nothing” on installation and “Access all areas unless I stop you” afterwards, we need to give full control back to the user.

Ideally the user decides what permissions they’re happy with any app being able to use, and therefore which permissions are “private”. When an app attempts to conduct a “private” activity, then it receives mock data rather than an exception – so instead of crashing the app, it simply receives false information. If we decide that an app should be able to access some “private” area, then we manually grant it permission to get the “real” data instead of mock data – now private information is “opt-in” instead of “opt-out”, and the security is “opt-out” instead. We could take this further by allowing a timeout on the private information “opt-in”, so we could allow Facebook access to our location information for the next 30 minutes, and have it automatically disable afterwards.

So if “location” is amongst our list of “private” permissions, then when Facebook requests our location it gets mock data – we could be atop K2 for all Facebook knows (although IP geolocation would eliminate this somewhat…). When it requests access to our phone calls or SMS messages, it gets fake data. If it requires access to messages to validate our number or device, then we can grant it access to new messages only and only for the next 5 minutes, then have it automatically receive mock data again after that.

Flow diagrams: Current privacy model vs. proposed inversion of control

Click to open enlarged in new window

Android privacy inversion of control

Reverse-tunnel SSH through NAT: Remote-access a computer that is behind a NAT router/firewall without manually forwarding ports on the router

Using port-forwarding over an SSH connection allows one to set up a SSH reverse-proxy server, allowing SSH access to a machine that cannot receive incoming connections (e.g. behind NAT firewall/router) by proxying them through a machine which can (e.g. a cheap VPS)

Problem: Dynamic IP, NAT and a bad router

While travelling around Europe (and now, living in Estonia), I occasionally want to connect to my home PC in order to backup photos to it from my camera, or to copy music from it to my phone. Unfortunately my PC is at the family house (now that I don’t have a UK house) and they have a crappy ISP router which “forgets” its settings every time the ISP pushes some new pointless stealth update to it.  The dynamic IP problems arising from the cheap ISP are easily resolved via my Dynamic DNS package, however that isn’t even necessary for the solution in this article.

Reverse port forwarding

This means that my PC in England essentially cannot receive connections from the outside world. However it can make connections. This is where “port backwarding” or rather “reverse port forwarding” comes in.  In typical port forwarding over tunnels, you connect to some other device and messages sent to some port on your end are forwarded down the tunnel to the other end.  In a reverse port forward, you connect to some other device and instruct it to forward packets back down the tunnel to you.

When my PC is powered on, a service loads which creates a tunnel to one of my cloud servers. On the remote end of this tunnel, a port on the server is forwarded back down the tunnel to my home PC. Therefore, connections made to that port on the server are forwarded down the tunnel to my home PC. Hence, my home PC can receive connections from the outside world, as long as they are passed through the tunnel that it created to the outside world. This is similar to a VPN, but much simpler and also quick and easy to configure.  In order to prevent me from having to enter a password for SSH login every time the service starts, I use public key authentication*.  If security is not an issue, you can also create port forwarding (reverse and forward) via netcat and pipes.

* I actually use this between ALL my secured PCs and servers, and disable password login.  This vastly reduces the risk of Chinese botnets getting into my networks.  The server hosting this blog (and others) gets on average three failed login attempts per second from China, plus some from other parts of the world too.  An IPTables rule-set restricting connection initiation rates on certain ports also hardens security against these bots somewhat.

Remote wake-on-lan without VPN or DDNS

First, to power my PC on remotely, I issue a command to one of my cheap cloud servers. A service running on a Raspberry Pi in the England house creates a connection to my cloud server.  The cloud server uses this connection to notify the Pi when a “power on” command is received by the server.  The Pi uses Wake-on-lan to power my PC on – much cheaper and simpler than the 1980’s power-relay method.  My PC powers on and the “port backwarding” service starts.  This method does not require a VPN or my Dynamic DNS service.  Nor is my old remote wake-on-lan interface needed any more.

The code

The service on my home PC runs the following:

ssh -nNTR remoteIntf:remotePort:localHost:localPort remoteUser@remoteHost

This creates an SSH tunnel between localHost and remoteHost, and forwards any packets bound for remoteIntf:remotePort on remoteHost to localHost:localPort. Using this, we can forward ports from the remote host to any host/port on our local network. In this case, the machine creating the tunnel is also the target for the port forwarding, so we have:

ssh -nNTR localhost:9000:localhost:22 server-user@cloud-server

which listens for packets via local loopback, port 9000 on the remote host, and forwards them over the tunnel to local loopback, port 22 (SSH port) on the home PC.

I could of course use this on the Pi instead, to tunnel from Pi to server, forward from server throuh Pi to PC:

ssh -nNTR localhost:9000:home-pc:22 server-user@cloud-server

But I see no advantage in forwarding through the Pi, and it will definitely slow things down a little. Also if I decide to reboot the Pi then I would lose my connection to the home PC via this method.

Using the first method (service on home PC initiates reverse forwarding), to create an SSH connection to my home PC, I simply log onto my cloud server via SSH/Putty and issue:

ssh home-user@localhost -p 9000

which creates an SSH connection through local loopback to port 9000 – which is forwarded over the previously-created tunnel to my home PC’s SSH port (22).

If I bind the tunnel to the public IP of my server, then I can connect to my home PC from my SSH client here, rather than logging into my server first.

This has security risks, so to enable it you must first set the following in /etc/ssh/sshd_config:

GatewayPorts=yes

Service on target PC:

ssh -nNTR cloud-server:9000:localhost:22 cloud-user@cloud-server

Connection from other PC/phone/tablet:

ssh home-user@cloud-server -p 9000

Obviously, change the user-names and server names/ports to your own preferred values, I use home-user/cloud-user/cloud-server/9000 as examples here.

Post facebook updates via a potato

Use this link to post Facebook updates via “a potato”.

Post via a potato

If size matters then you’d obviously rather post your status update via a watermelon.

melonputer

For the more steampunk people out there, you can send your status updates via a carrier pidgeon!

Then when you’ve posted it and you’re back here, why not use this one to leave the site?  Or alternatively, use this one if you’re smarter and can spot an obvious rickroll.