policy

We trust our phones to connect us to the world, and they allow us to prove our identity.
They are an authentication factor in themselves – proving we have the phone, is one measure of proving we are the owner of an account (via Email, SMS, Google Authenticator, etc).
Proving we can unlock the phone is itself another measure. (Mostly just to prove we didn’t recently steal the phone.)

So why do so many of us who also use our phones for work, agree to trust our employers with complete control over our phones?

I recently wanted to access my work email on my phone, so I installed the email app, and it told me I must have an administrator allow the connection.
So I contacted my friendly local sysadmin, and they said:

You need to install the policy tool on your phone before we can allow you to access work email on your phone.

Fine. So let’s look at the permissions this “policy” tool is requesting:

Notably, the app wants these permissions:

Erase all data on the phone by performing a factory reset.
Change the screen lock.
Lock the screen.
Enforce storage encryption.

I understand these requirements from a security perspective; they are all administrative functions I would want to have control over, if I owned the phone – which I do. The problem is that the company who I work for does not own my phone. I will never trust them to the same degree that I trust myself.

When I spoke to my colleagues about this, they all said the same thing to me:

But the company will never actually _use_ any of these permissions. – They just want to be able to delete your email from your phone if it’s lost or stolen.

This completely misses the point.

I refused to place my trust in this app for two reasons:

Apps should not be granted more permissions than they need to fulfil their purpose.
If I agree to these permissions, then it has the power to use them, regardless of any good intentions.
Whether I trust the SysAdmins of my company is irrelevant.
If a SysAdmin in my company can control my phone – then I’m also entrusting this control to a string of black-box processes and procedures that I have no control over.
I treat my phone security very seriously – *Nobody else* has the same motives to protect my phone, as I do.

If my company gets hacked – or if any one of the SysAdmin’s accounts gets hacked (and there are probably multiple Sysadmins that have the same access to control my phone) – then a malicious actor now has the ability to lock out my phone, or wipe it with no warning.

This may have the following side-effects:

Loss of personal files/photos stored on the device (assuming they aren’t all backed up to the cloud somewhere)
Loss of 2-factor login codes (because you don’t have a U2F device)
Loss of 2-factor backup codes (unless you keep them stored somewhere safe, and not in a text file on your phone)
Loss of other account passwords that you keep in an encrypted text file that you keep on the encrypted SD card in your phone (which isn’t in the cloud, for “security”…)
Inability to contact anyone (because you don’t actually remember anyones phone number anymore)
Inability to buy things (because you rely on Apply|Android Pay and no longer carry cash or cards)
Inability to use public transport (because you use an App for that)
Inability to control your house heating/lighting/door-locks (because you can’t get enough of those IoT devices)

But these issues aren’t limited to you. This policy is something that everyone in the company who wants access to their email on their phone, has to agree with and accept.

So if I’m a hacker and I’ve compromised just one SysAdmin account – I have the ability to wipe the phone of everyone in the company who has placed their trust in this app.

Does this include the CEO or board of directors?
Does this include all of the security staff?

Desired Outcomes

A malicious actor might choose to disable these devices for the following reasons:

To destabilise a company during a critical period of business, causing financial harm.
As part of a campaign to cause as much damage to the company as possible.
To inhibit security personnel from countering the actions of the malicious actor.
To restrict the short-term management of company stocks and shares.

General Motives

Individual victimisation.
Retribution against the company.
Competitor motivated or financed.
Foreign government de-stabilisation.

Victim / Target

The intended victim in this attack can vary a lot. As a user, I might intentionally be the only victim in a directed attack, but I could also just be one of billions of victims.

Single targeted user.
A group of users within a company who share a common function. (eg. Security Personnel)
The company itself (All users of the app in the company)
All users of the app (If the app or app company is targeted)
All users in a specific country (In a state-sponsored attack on a foreign government, as part of a de-stabilisation process)

Mitigation

Any app you require your users to install on their devices, should only have the permissions required to serve its purpose.
The ability to perform actions on users’ personal devices must be restricted to those who absolutely need it.
Multiple SysAdmins should be required to act as a “group action” to carry out a non-reversible process such as ‘wiping a device’.

Summary

As a company, we need to be less cavalier about what we ask our users to trust us with.

As an employee, we need to be more protective of our own devices, our data, and our privacy.

As system designers, we need to allow for multi-admin safeguards, to ensure any action that results in any action against a user’s device can only be carried out as the collective actions of an authorised group of administrators.

As system engineers, we need to ensure any actions that are carried out are recorded and audited, so that misuse of the system can be identified, reported, and investigated thoroughly.

The simple reason is obvious – you don’t want other people to be able to access your stuff when you don’t want them to.

The more complex reason, is the legal one. Businesses, Websites, Internet Service Providers, Internet Cafés, nearly everyone infact, has a document or set of documents called an ‘Acceptable Use Policy’. In this document, they specify (or at least they should specify,) that any password or key they provide you with is not to be shared with anyone else, under any circumstances.

The reason for this is not just to protect you and your stuff – this is to protect whoever is providing you with access to it. Because if they didn’t explicitly state that sharing these credentials with someone else is against the rules, then if your account becomes linked with some kind of activity that IS against the rules and they want to come after you, they might then have no way of proving you did it – because anyone you have given your password to could have access to it.

Let me put this another way.

Alice is given a password to access example.com
Alice gives her password to Bob, to upload some files.
Bob uploads some illegally downloaded MP3s to example.com using Alice’s password
example.com finds the illegal music collection, and wants to prosecute Alice
Alice then tells example.com that she didn’t put the files there
Bob never agreed to the usage agreement on example.com, because he just logged in using Alice’s password
example.com is then stuck because the usage agreement hasn’t been broken – they forgot to put in a clause about sharing passwords

Here’s another example.

Charlie owns example.com
Derek works for example.com
Charlie creates an email account for Derek, and hands him his password
Derek is not allowed to change his password, because Charlie wants to keep a copy of it, for “security reasons”
Derek sends an email to Edwin using his example.com email account
Edwin takes offence at Derek’s email, and decides to sue example.com
Charlie tries to fire Derek for sending the offensive email to Edwin
Charlie cannot prove that the email was sent by Derek – as both Charlie and Derek have access to Derek’s password
Charlie therefore has no reasonable grounds to fire or take other action against Derek due to the email.
If Charlie fires Derek anyway, Derek may try to sue Charlie for unfair dismissal.

If you work for a company who keeps a copy of your password written down somewhere, or stores your password unencrypted in a database, or stores it in any way that could enable anyone to read it – then it’s a reasonable assumption that someone else could have your password, without you having given it to them.

Passwords Are Secrets – Nobody should ever know any of your passwords. They are secret and should not be shared. No exceptions.

Providing access to another individual, either deliberately or through failure to secure its access, is prohibited.

SANS.org AUP

User ID’s and passwords are not to be shared. Those who use another person’s user credentials and those who share such credentials with others will be in breach of this policy.
Initial default passwords issued to any user must be changed immediately following notification of account set up.

University of Bath AUP

Each user is issued with a valid username and password that must be kept confidential and must not be shared with anyone else.

University of Salford AUP

You are responsible for properly using any user IDs, personal identification numbers (PINs) and passwords needed for the service, if any, and must take all necessary steps to make sure that you keep these confidential and secure, use them properly and do not make these available to unauthorised people.

BT Terms and Conditions

To protect your Google Account, keep your password confidential. You are responsible for the activity that happens on or through your Google Account.

Google Terms of Service

I did come across several policies that do not specifically mention passwords or access credentials – not all of them need to, as they can protected themselves with other related clauses, but adding a password clause like those above to any policy is such a simple addition that adds a lot of protection with very little effort.

stampycode

The Security Architect

phones: don’t be complacent with your trust