Risky smartphone travel — Part 1
This is the first post in a 3-part mini series on risky smartphone travel.
As usual, I have sat on this draft for a number of months and decided to dust it off after Kaspersky started discussing Operation Triangulation.
In April 2018 I wrote ‘Being safe on hostile WiFi/mobile networks’, and tangentially related in August 2021, Michael Brunton-Spall and I wrote ‘How to keep your smartphone safe from spying’ as a persona-led way of talking about (and managing) cyber security threats through smartphones.
Neither posts really touched on the end-to-end high-risk smartphone service as something that needs provisioning, management and monitoring from corporate IT and cybersecurity teams.
A really tempting default position is that travellers are given a new burner smartphone with temporary everything (accounts, mobile number etc) but in the real world this often has a terrible traveller user experience and often isn’t very practical.
This mini 3-part series is written for cybersecurity and IT teams who provide services to high risk personas (government officials, corporate executives and investigative journalists) as they travel with their smartphone for work.
Smartphones are targets ‘at home’ as well, however this is a travel specific series. A number of the configurations and ideas in this mini-series are readily applicable outside of travel scenarios.
Posts in this series
- Part 1 —this post — risks, threat actor capability, smartphone choice, VPNs, encrypted DNS, smartphone configuration
- Part 2— contacts/accounts, the high risk travel itself, traveller preparation, mobile data -v- Wi-Fi, roaming, and monitoring
- Part 3 — the return, decommissioning, tamper seals and long-lived roaming risks
I am on Twitter as @JoelGSamuel.
Michael who co-authored ‘How to keep your smartphone safe from spying’ with me is the author of CyberWeekly (a weekly roundup of interesting tech / cyber security content presented with a small amount of editorial comment). Michael is on Twitter as @BruntonSpall. Michael did not co-author this mini series — so none of the typos and waffle are his fault.
Travel can be a risky business
The vast majority of people do not need to worry about high risk travel threats.
For a travelling government official, corporate executive or investigative journalist, optical surveillance, technical attacks (side channel, etc), cyber attack and physical risks (including staged muggings and evil maid) are all potential things.
This is huge contrast to individual tourists, families, small businesses and so on where its far more likely to be loss, opportunistic theft or street crime — which is where the vast majority of people sit, and why this mini-series is directed at enterprise IT and cybersecurity teams.
The threat actor — who may be the local intelligence service/government — may be after work in progress policy, negotiation information, draft financial statements and strategies through to journalistic sources.
The risks vary wildly between country-country negotiations, share prices tumbling through corporate espionage, kidnappings and revealing of journalistic sources (which could mean life or death).
With successful compromise, the threat actor can readily impersonate the traveller and would have access to the data on the smartphone — this includes pivoting into their productivity account (Google Workspace, Microsoft 365 etc) and all that those accounts contain and have access to.
On a bad day, that could be years of their documents, documents they have access to (shared with them), emails, distribution group content and so much more.
Once again, the vast majority of us need not worry about being targeted by intelligence organisations, and it would be disproportional to try and defend against such capabilities.
Threat actor capability
We assume very little is off the table.
Binoculars, staged street robbery, rummaging through a hotel room, Wi-Fi / mobile data interception and manipulation, SS7 attacks, baseband attacks, or deployment of service/tools such as NSO Group’s Pegasus or Hermit.
Pegasus (and other services/tools like it) may be readily applicable during travel scenarios compared to when the smartphone is on a home telco network where the service claims not to operate.
An official formally travelling for work to represent their government on a government-class visa may not be concerned with the smartphone being used to locate them through constant SIM location checks, but a journalist travelling to meet sources might.
Apple iPhones with iOS
This series is underpinned by the assumption of using a modern, corporately owned and managed Apple iPhone.
Apple invest heavily in security — examples include Lockdown Mode and Apple’s (sometimes fascinating) Common Criteria (ISO/IEC 15408) documents. Apple Security Research launched https://security.apple.com in November 2022.
It is far more likely that an organisation reading this can consistently and repeatedbly provision and manage an iPhone, compared to a custom Android variant — to the same level of user experience, security, corporate security monitoring and corporate management. I am not suggesting Apple iPhones/iOS is the most secure option.
GrapheneOS is one of many privacy-centric Android variations, however the enterprise deployment, management, monitoring and lifecycle is much more complex. For some this is within grasp, and they can choose to re-apply some of the thoughts in this series. Manufacturers reportedly do cooperate with jurisdictions in which they operate or sell into.
This series can be readily applied to Apple iPads, with or without SIM cards.
To VPN, or not VPN — that is the question
In general terms, the vast majority of people in the vast majority of circumstances do not need a VPN and corporate VPNs by default should also be a thing of the past.
However, in this scenario, a VPN is likely essential.
With the local Wi-Fi and mobile data should be viewed as actively hostile, and in that scenario it's important to get as much traffic as possible away from the local networks.
Understanding the device’s network traffic is key to detecting command and control traffic or data exfiltration, whether in real time or after the fact.
Corporate VPN or third-party?
A corporate VPN service you control is strongly preferred. You can log and monitor the traffic and apply policies you understand — such as filter DNS, block/detect known Indicators of Compromise (IoCs) and retain logs for retrospective investigations.
A large-scale cloud-based VPN solution (Palo Alto Prisma Access, etc) may be better than a private VPN solution deployed on a single IP in a single region — the latter is much easier to block with hostile network conditions.
Hostile networks often attempt to manipulate the client device (a smartphone in this case) by allowing VPN sessions but mothballing VPN tunnel data. This could make the user try to switch off the VPN, or serves as an effective denial of service attack.
A VPN that negotiates between good IPSec and TLS (SSL VPN) will also help establish connections based on local network conditions.
VPN network configuration
I am assuming whatever VPN solution is used is well configured and well maintained.
The VPN should be a conduit to the internet. It should not provide access to internal systems, and definitely not offer lateral access to IT infrastructure (print services, file servers, Active Directory etc).
Backup third-party VPN
Where practical, you could also offer a third-party VPN (for example, TunnelBear) as a backup, and allow the user of the smartphone to switch between the VPNs — this is hard to do from a mobile device management perspective, as you can’t just specify an always-on VPN and need to put more control into the hands of the traveller.
The balance here is that if the corporate VPN isn’t working, they could fallback to a third-party VPN as its still much better than the assumed hostility of the local network.
The downsides are you wouldn’t have any control or influence over that VPN solution, because TunnelBear won’t let you get a copy of the traffic or inject your own rules.
Source IP access control lists (if you’re using them) will be harder, as TunnelBear’s egress IPs will be their own and used for all of their customers.
The VPN isn’t your magic bullet
I phrased it as ‘as much traffic as possible’ because VPNs drop. This will either be because there are scenarios where traffic misses the VPN, boot time network races, or the local network blocking VPNs.
Assume from the outset that the VPN will drop, may be stopped or otherwise not work as you predicted.
One thing to note: when the iPhone is in Personal Hotspot mode, Apple does not tunnel the hotspot client traffic through the VPN (and that makes sense).
As good practice, but also to support the eventual VPN issues, the applications you provide to the traveller must use good TLS and be resistant to network-based downgrade attacks — apps such as Google Mail, Microsoft Teams, Microsoft Outlook, WhatsApp, Signal etc will all be fine.
The VPN will flip-flop, but hopefully any data exfiltration or C2 continues while the VPN is ‘up’ so you can capture it.
Encrypted DNS
While Apple’s network modules can sometimes conflict between encrypted DNS and VPNs, the net positive is that if the VPN is ‘down’ (as it often will be), the DNS traffic remains protected.
I’m a fan of NextDNS however you should ensure you are able to log, monitor and filter the DNS traffic.
Cisco Umbrella and things like it are good enterprise-grade options. Running your own encrypted DNS would give you a lot of control, but be wary of blocks on hostile networks, performance and having to solve DoT/DoH authentication issues etc.
Encrypted DNS protocols can also be blocked, and most VPN configurations will fail-open to unencrypted DNS.
Smartphone configuration
I won’t repeat all of what is already in ‘Being safe on hostile WiFi/mobile networks’, and ‘How to keep your smartphone safe from spying’.
A lot could be said here, I’ll try to keep it snappy:
- an iPhone that is registered to your Apple Business Manage account, so it is corporately owned, managed and will re-enrol into the mobile device management system if reset
- disable personal iCloud
- disable the public app store to minimise the sprawl of applications that can be on the device— applications should be available from the corporate App Store (VMWare Workspace ONE for example uses the ‘Hub’ app)
What I mean here isn’t to deny all their app requests because its fun to say no. Your traveller will want to stay in touch with the office, family and friends, doom scroll on instagram, and use taxi apps.
Prohibiting apps not overly for work may seem like a good idea but you should take the balance of allowing these applications and warning users of the perils, rather than blocking them and making them resort to a personal device which will be unknown and unprotected by you.
Modern mobile device management platforms will allow you to be more specific on the permissions the app can have, so you may be able to allow taxi apps for the country they are going to, but not let it sync Contacts.
- enable erase after 10 incorrect passcode attempts
- enable FaceID
- enable Personal Hotspot — I know roaming 3G/4G is expensive, but if they have another device (you’ve given them a SIM-free table or laptop) they will appreciate being able to get online and keep working (note: as above, the hotspot traffic is not VPN protected by the smartphone, the tablet or laptop needs its own VPN)
- name the iPhone something unique but not “iPhone Joel Samuel”, iPhone and then some random characters is fine — this is to help with when being used as a Personal Hotspot, as just calling it “iPhone” is really annoying in a Wi-Fi menu
- disable Bluetooth
Similarly to apps, there are times this is useful as a user. Syncing contacts to rental cars not so much, but wireless headphones may be a legitimate user requirement.
- disable iCloud backups
- fully patch the device — then disable software updates but keep Apple Rapid Security Responses enabled
The balance here is a tough one — signed software update caches in the local jurisdiction may be manipulated by a nation state (so therefore as would the RSRs) but RSRs are about dealing with active threats in the wild and Apple developed the RSR update system for a reason.
Software updates are by default a great idea, so it may boil down to the duration of the trip and capability of the jurisdictions being travelled through.
- provide WhatsApp and/or Signal — don’t forget to ensure they set a PIN and recovery email
- disable iMessages — use Signal, WhatsApp, MS Teams etc
- provide a cloud storage system (OneDrive, Google Drive, Dropbox etc) — will be used later to sync files from the travel iPhone before its erased (touristy snaps, food pics for the gram)
- provide a password manager (the Apple native one is fine) — they’ll need a place to store the passwords for any accounts they are taking
- enable Lock Down mode before they leave for their trip
- enable screenshots — if a threat actor is on the device you’ve already lost, disabling this is usually just annoying the traveller
- set a PIN for the physical and virtual SIM cards
Seriously, Lock Down mode — turn it on.
Think about device configuration carefully, and don’t just turn things off without understanding the traveller needs — depending on your profile structure, updating the configuration later will require profiles to be removed and re-added which could expose an attack surface if done after the traveller is already on the trip.
Lets get physical
- screen protector to reduce viewing angle for shoulder surfing and optical surveillance
- tamper-evident seals — over the SIM card tray and the edge of the casing — remember though, the tamper seal may rub off due to sweaty palms or perhaps just being in a bag/pocket
Take pictures of the seals before the traveller is given the smartphone. This way you know where it was positioned and its condition, along with the serial number of the seal. Do not send the traveller with spare tamper seals.
I debated whether to include tamper-evident seals given poor quality seals, sweaty hands and pocket/bag friction but they are probably still a net useful security detective tool.
You could also seal the device shut with glue/resin, if simplicity of approach and good likelihood of detecting physical manipulation is more important than device servicing and warranty.
- charger or two— tamper-evident seal the charger
- a few USB data blocking adapters and cables
- a faraday bag or two for them to use — if there is material suspicion the smartphone has been manipulated
