Risky smartphone travel — Part 2

This is the second post in a 3-part mini series on risky smartphone travel.

Posts in this series

1. Part 1— risks, threat actor capability, smartphone choice, VPNs, encrypted DNS, smartphone configuration
2. Part 2 — this post — contacts/accounts, the high risk travel itself, traveller preparation, mobile data -v- Wi-Fi, roaming, and monitoring
3. Part 3 — the return, decommissioning, tamper seals and long-lived roaming risks

I am on Twitter as @JoelGSamuel.

A picture of a smartphone taking a picture of a beach and sunset

Services and data available from the smartphone during travel

This is one of the most difficult parts, and there isn’t a single answer. Without knowing the business and traveller context, I can’t advise whether you give them:

• (1) a burner consumer Google Mail / Outlook.com account

The best from a ‘distance’ perspective, but the traveller will have to communicate that new account and — in advance — share all the documents/emails they need before their trip.

While it’s keeping the smartphone away from the corporate system, you won’t have any corporate control or visibility — for example, monitoring or being able to enforce multi-factor authentication (MFA).

• (2) a new corporate account (joel.samuel.travelMMYY@yourcompany.com or joel.samuel@travel.yourcompany.com)

A balance, but still requires them to share contact information in advance and files they may need, but they are doing that within the corporate domain.

A travel group/organisational unit in your system will allow you to segregate the account from being able to see data that is usually available — company intranet, people finder etc.

• (3) let them take their regular corporate account (joel.samuel@yourcompany.com)

The riskiest, if/when that smartphone is compromised, the threat actor will have access to their full catalogue of contacts, emails, documents and files. This is the most flexible for the traveller though.

It really depends on what they need — not want, because if the user is genuinely facing these threats, they hopefully will be flexible on how their IT works.

Contact lists

A full sync of all of their historical contacts may not be proportionate, but it depends on the traveller need.

The ideal would be that the corporate apps you’re providing (Google Mail, Teams, Outlook, etc) have their own in-built contacts system and the traveller is very happy to just use those.

If they aren’t, you will need to figure out with the traveller whether syncing all, or just some, of their contacts to the Contacts app is proportional and necessary. They may be OK with a handful of contacts, and they are happy to manually recreate them.

I believe WhatsApp and Signal use the iOS Contacts database.

The Contacts app on the smartphone may be a particular target, and malware or a human threat actor may have automated tools to scrape it.

Mobile phone numbers and SIM cards

The chances your traveller will want to take their usual mobile phone number is fairly high.

If you can use a burner mobile number, that is great and you should prefer that — but recognise this comes with a significant amount of pain for the traveller. Its not trivial to warn everyone they need to contact, particularly if they have sources that might be easily spooked by being contacted by an unknown number as they did not read the advanced notice of the temporary number. As they are travelling for work, it just may not be something they feel they can do.

In being safe on hostile WiFi/mobile networks I personally opted for a disposable SIM designed for travel (cheaper travel data etc). That could also be an option here though harder to manage corporately, and could complicate telco legal jurisdictional issues (for better or worse).

On the assumption they are taking their usual mobile phone number, you likely will need to pop out the SIM from their usual phone and put it into their travel iPhone.

The threat actors and roaming mobile networks will have a fair amount of information now:

• the International Mobile Equipment Identity (IMEI) of the travel iPhone
• the International Mobile Subscriber Identity (IMSI)
• the Mobile Station International Subscriber Directory Number (MSISDN)

Once again, SIM PINs for virtual and physical SIM cards please.

Getting the traveller ready to rumble

Above all else, you have someone travelling for work who is trying to do their job. The probability of them being a security or technology professional is likely slim. All of this security stuff may also be making them nervous.

The more you overload the traveller, the less security conscious and capable they may be. Do not shift tasks and responsibility to the traveller when they can and should be met by the IT team or Cyber Security team.

Provide them with a pithy, simple handbook. The numbers for the IT Service Desk, the Cyber Security SOC etc.

If your services are operated 9am-5pm and the timezone of the traveller is quite different, seriously consider operating on-call or 24/7.

Mobile data -v- Wi-Fi

There could be an endless debate on whether its better to use 3G/4G/5G exclusively or use Wi-Fi services during high-risk travel. Ultimately if the adversary is a nation state, it doesn’t really matter.

The high risk traveller should be able to use mobile data or Wi-Fi depending on what works.

Mobile data has a higher chance of ‘just working’, with hotel/conference Wi-Fi systems being easier to implement VPN blocks, captive portals and other network conditions.

The corporate side of the responsibility horizon

I put the corporate responsibility first as I’ve seen a fair amount of user-blaming in my time.

Tell them simply and clearly what you’d like them to do on the trip

1. Completely turn off the smartphone when in an airport or going through any security checkpoint
2. Keep an eye out for the VPN, if it isn’t connecting do X, Y, Z — that might be to change Wi-Fi network, go to 3G/4G/5G or try the 2nd VPN you’ve given them one
3. Use whatever data works (Wi-Fi or 3G/4G/5G)
4. Don’t leave the smartphone alone — ever (though probably don’t take it into the shower)— and to let you know if they have done so even if nothing seems wrong
5. If the tamper-evident seals look tampered, they’ve lost it or its been stolen — contact the IT Service Desk or SOC
6. Signs of ‘the phone being weird’ includes overheating, it being really really slow and/or lots of data use when not expecting to use lots of data
7. Reject SIM card updates
8. Restart the smartphone once a day
9. Use the provided data blocking cables

Edit: 2023–06–23
https://9to5mac.com/2023/06/23/turn-off-your-iphone/ is interesting, in reality the vast majority of people do not need to do this. Frequent restarts help shake exploits which do not persist through a full restart, however it doesn’t mean the exploit can’t be re-applied by the attacker or the exploit is re-triggered (for example, the exploit is based on an iMessage image which is re-processed when iMessages is opened the next time).

Give the traveller the things

1. The smartphone
2. The tamper-evident labelled chargers, USB data blockers etc
3. A faraday bag or two, that will fit the smartphone
4. The small print out of contacts/instructions

Tell them what you’d like them to do before coming home

1. Forward anything from WhatsApp, Signal and Camera Roll they would like to keep to their mailbox or into Google Drive, OneDrive or DropBox
2. De-register from WhatsApp and Signal — this depends on if you’re going to rotate their mobile phone number or not though
3. Logout from all the apps — Google Mail, Microsoft Teams, Outlook and so on
4. Drain the battery down to single digit percentage
5. Reset the iPhone — Settings, General, Transfer or Reset iPhone, Erase All Contents and Settings — unless there is a suspicion of compromise you wish to forensically understand
6. Turn the device off once back at home (they may have used the smartphone for the taxi home, etc) — unless you wish to preserve for forensics
7. Put the device in a faraday bag
8. Schedule the time/date to hand back in the phone

Detect the good, bad and ugly

The job now is to monitor their accounts which travelled as best you can, keep an eye on the roaming bill, and pick up the phone if they call.

Depending on the length of the trip, the device may fall out of compliance if Apple release a software update that they are not applying — you should have decided in advance what you do and don’t care about.

There is a long list of potential detection use-cases, the typical ones are:

• impossible travel
• mobile device management (MDM) advises of a device jailbreak
• MDM advises desired app uninstallation (corporate VPN client app is deleted, etc)
• mobile application management (MAM) advises of device jailbreak
• changes to MFA
• password sets
• email forwarding rules
• account delegations
• bulk file downloads
• connections to known-bad IP (C2, etc)
• DNS resolution attempts for known-bad domains (C2, etc)

Examples of challenging ones to configure:

• DNS lookups of newly registered domains
• DNS lookups/IP connections to unexpected services (cloud storage providers the traveller isn’t meant to be using)
• Disproportionate outbound data connections and usage
• High amounts of NXDOMAIN DNS lookups
• High entropy subdomain DNS query names
• High entropy DNS query responses
• DNS lookups without subsequent IP connections
• RFC1918 IP connections (other than to DNS/gateway) from VPN client IP — network scans, trying to find local network services etc

The traveller side of the responsibility horizon

You’ve given them advice, guidance and instructions, and they are off to the airport.

They should already be comfortable with the smartphone configuration, VPN, WhatsApp/Signal etc.

If they tell you something feels weird, or they left their phone unattended (whether the tamper-evident seals look modified or not) you need pre-written playbooks on what you will do, when and why.

If this is group travel, maybe you sent IT staff with them who have spares.

If they are all by themselves, you may not want to disable their phone or productivity accounts because they probably still need to do their job and stat in touch. It will depend on what has happened (or not happened) and the level of monitoring you have around the productivity account.

The next and final post in this series (Part 3).