Apps Publishing Security Policy

BSkyB has become the latest high-profile victim of a security blunder which has caused them to suspend all their Sky Android applications from the Google Play app store.

The hackers would appear to have used a combination of phishing and social engineering techniques to compromise a trusted computer and steal corporate login details for third-party sites such as Google and Twitter.

The storefront for Sky’s Android mobile apps was defaced, with the app descriptions changed and screenshots replaced.

Sky Go defaced

To make a bad situation even worse for Sky, one of their official Twitter accounts was also compromised and the hackers used it to draw more attention to their handywork.

skyhelpteam

Fuelled by the ‘official’ Twitter misinformation, customers were led to believe that the apps had also been tampered with, although this has been subsequently denied by Sky on their Help Forum:

We have temporarily removed our Apps from the Google Play store following a security alert.

All Sky Apps were unaffected and any Sky Android apps previously downloaded by customers are safe to use. There is no need to remove them from your android device.

As soon as we have restored the apps on Google Play we will post up an update.

In a related security breach, Twitter has locked access to @SkyHelpTeam, which is why we are currently unable to tweet from this account. However, help and info is available via @SkyHelpTeam1Facebook and here on the Sky Help Forum.

The tweet that was made from the @SkyHelpTeam twitter, in the early hours of Sunday morning, advising customers to unistall their apps was NOT an official tweet from Sky. Twitter security immediately detected this vogue messaging and locked account as part of agreed standard security process.

Sky have suffered this humiliation as a result of sloppy security practices. With a robust security policy the damage from this attack could have be limited or prevented entirely.

My recommendations for an apps publishing security policy:

  • Use a dedicated Google account for the Google Play Developer Console, not an account used for other Google services. Do not divulge the email address of this account.
  • Enable 2-Step Verification on your Google account and use Google Authenticator to login. Make sure that you properly sign out of your Google account when you have finished each session.
  • Only use a bookmarked https link to access the Developer Console. Never click on links contained in emails or on other web sites.
  • Tightly limit access to the Developer account. Only permit access to those directly involved with apps publishing, usually just the Apps Manager and their deputy.
  • Wherever possible use discrete private keys to sign each application – see the Signing Strategies section of Android Developer Tools. This limits the damage should the private key for an individual app be compromised.
  • Store your signing keys securely, preferably using a hardware-encrypted USB flash drive (such as an IronKey). Physically store the keys in a locked safe.
  • Use a standalone computer for code signing and never connect it to a network. Treat all networks as untrusted, even your corporate LAN.
  • Have a well rehearsed contingency plan to ensure business continuity if the worst does happen.

EvoCam vs SecuritySpy

The options for network camera recording software are a bit limited on Mac OS. The two most popular products in this space are Evological’s EvoCam and Bensoftware’s SecuritySpy.

So which is best?

On price alone you might be tempted by EvoCam as it costs just $30 (under £20) for an unlimited number of cameras, while SecuritySpy will set you back £30 for a single camera license and a whopping £500 for unlimited camera support.

I’ve had an opportunity to evaluate both products and have come to the conclusion that you really do get what you pay for.

EvoCam does the job well enough and has a more polished user interface, but it also suffers from a major problem that lets it down badly, almost to the point of being unusable. For reasons unknown it ties up the processor for even a simple one camera recording setup.

Activity Monitor output taken for identical recording sessions is below:

In these examples (from a Mac Mini 2.26GHz Intel Core 2 Duo with 4GB RAM), EvoCam consumes 85% CPU and 90MB real memory, while in comparison SecuritySpy consumes a meagre 6% CPU and 21MB real memory. That’s quite a difference and it’s very noticeable when you try to use the same host machine for other work.

So if you have the luxury of a dedicated powerful server for your camera recording then EvoCam is probably the most cost effective option, but if you want something that works reliably and doesn’t take over your machine then SecuritySpy is well worth the extra investment.

Remote SSH using Back To My Mac

One of the less well publicised features of Apple’s iCloud service is Back To My Mac.

This service provides a private IPv6 network which you can use to securely connect all your Mac hosts.

To use BTMM you will need to upgrade all your Macs to OS X Lion and sign them all into the same Apple iCloud account. You will also need your unique BTMM account number.

When you are signed into iCloud you can discover your BTMM account number as follows:

$ dns-sd -E
Looking for recommended registration domains:
Timestamp     Recommended Registration domain
12:07:46.550  Added     (More)               local
12:07:46.550  Added                          icloud.com
                                             - > btmm
                                             - - > members
                                             - - - > 123456789

The final line shows your individual BTMM account number.

For example, if you Computer Name (set in System Preferences > Sharing) is mymac and your BTMM account number is 123456789, then the fully qualified domain name of the host is mymac.123456789.members.btmm.icloud.com.

If you have spaces in your Computer Name then replace them with dashes, e.g. “My Mac” becomes the hostname my-mac.

To test connectivity to your remote host use ping6, e.g.

ping6 mymac.123456789.members.btmm.icloud.com

To list all the SSH enabled hosts on your domain:

dns-sd -B _ssh._tcp

You would SSH into your host using this command:

ssh -2 -6 username@mymac.123456789.members.btmm.icloud.com

Note that you will only be able to communicate with the other hosts on your iCloud private network if the Mac you are using is also signed into the same iCloud account.

You can also use an open SSH connection to access your non-Apple hosts on your internal network by using SSH port forwarding. This tunnels the destination traffic over the BTMM private network via your remote Mac.

For example, if you have a web server running on a host with the IP address 192.168.1.2 then you can use this SSH command to set-up a forwarded port:

ssh -2 -6 -L 8080:192.168.1.2:80 username@mymac.123456789.members.btmm.icloud.com

To access the remote host from your local machine you would go to http://127.0.0.1:8080/

Dropbox & EncFS on OS X Lion

I previously wrote about a method for creating a super-secure filesystem using Dropbox’s cloud storage.

After updating to Mac OS Lion I struggled to get the MacFusion GUI to work and so I wrote an application to automate the mounting and unmounting of the EncFS filesystem.

I also took the opportunity to switch from the now abandoned MacFUSE to Fuse4X, which is a properly maintained fork of MacFUSE started in June 2011.

The install procedure is much simpler than before, you install Fuse4X and EncFS, but instead of using the MacFusion GUI you just call my script instead.

To the instructions!

First download and install Fuse4X and a version of EncFS which uses the Fuse4X APIs. Thanks to Simone Lehmann for providing an EncFS Mac installer at http://www.lisanet.de/?p=128 (also mirrored here).

To create a new encrypted volume (stored locally at first to prevent the EncFS key from being synchronised with Dropbox):

encfs ~/Desktop/_Encrypted ~/Documents/_DropSec

Answer ‘yes’ when prompted to create the new folders and choose ‘p’ for pre-configured paranoia mode (256-bit AES encryption). Enter a secure EncFS password when prompted and you’re done.

Now the filesystem has been created we can deal with securing the key.

umount ~/Documents/_DropSec
mkdir ~/.keys
mv ~/Desktop/_Encrypted/.encfs6.xml ~/.keys/dropsec.xml

The commands above move your key from the EncFS filesystem into a hidden folder in your (local) home directory

Now move the entire ~/Desktop/_Encrypted folder (minus your key) into your Dropbox:

mv ~/Desktop/_Encrypted ~/Dropbox/

Finally download my DropSec application and copy it to your Applications folder.

The first time you run DropSec it will prompt you for your EncFS password which it stores in your local login keychain. The password must match the secure password you set in a previous step.

To mount or unmount the encrypted filesystem simply run the DropSec app. For convenience copy it to your Mac OS Dock for quick access.

Opting-out of Google Location Server

In September Google announced their intention to comply with requests from European data protection authorities and offer a method for opting-out of their Google Location Server (GLS).

Peter Fleischer (Google’s Global Privacy Counsel) has today published an update on the European Public Policy Blog and Google have added specific opt-out details on their Maps Help page.

What is GLS? It’s a location service that most Android smart phones use to request your current location. Your smart phone could simply use satellite positioning (GPS) to accurately pin-point your location, but GPS consumes battery and generally only works outside.

Instead of using GPS your smart phone attempts to discover your location by scanning for nearby WiFi access points. It gathers the relative signal strengths, network names and unique network addresses and sends the details to the Google Location Server (GLS) for processing.

The GLS checks its database of WiFi access points and returns an estimate of your location. If your local WiFi access points are known and already in the GLS then it will return a fairly accurate location, almost on a par with GPS, for a fraction of the power.

Google built their WiFi location database while collecting data for Google StreetView and it is constantly updated and augmented by smart phone crowdsourcing. The manner in which Google collected this data has been controversial and Google have been investigated for breaches of interception laws. As a result Google has been forced to offer this opt-out scheme to appease regulators.

So what do you need to do to ensure that your own WiFi access point is not included in the Google Location Server database?

Simply append “_nomap” to the SSID of your WiFi network and Google will remove it from their database the next time a device sends information to the GLS.

It’s undoubtedly an inconvenience to change your WiFi network name and re-associate all your wireless devices, but if this scheme is adopted by all the mapping services (Microsoft, Apple, Skyhook) then it could well be worth it.