Tommy Skaug
a4adbc2b1c
16 KiB
Travelling with electronic devices is a challenge, and this is certainly the case if you do not have a travel program for your employees, where you must tinker with a new setup on a case by case basis. The complexity of the matter is though, even when it comes to resources, as it requires full time attention.
Some organisations choose to ignore the problem all together, others again does not fully respect their own threat model. The latter may be just as dangerous, as it may lead to a false sense of security for the travellers.
This article is about establishing a technical laptop setup that can be re-used with ease. Thus, other operational and strategic aspects are left out. The information presented evolves around organisations, but might as well apply for a private travel of exposed individuals.
Main Drivers
With that out of the way: multiple overall factors are left for consideration. The following factors are the main drivers and equally important when developing a technical model of an abroad operation.
- Threat resiliency. Equipment on travel can really never be secured well enough, but it can be hardened to the degree that a threat actor needs to risk exposure to compromise it
- Usability for the traveller. Equipment that feels inconvenient will be avoided by the traveller at some point
- Usability for the supporting organisation (both security and IT operations). Such setups may require much time and attention to develop and if there are an increasing number of travellers to high risk areas the setup needs to scale
- Cost. A travel program is a balance between environment, security and cost. If the cost and environmental impact surpasses the value that needs to be secured, the travel program misses some of its value. Critical infrastructure organisations is a different ball game than other industries on this point.
When it comes to threats, the most prominent one is the evil maid infiltration vector - which is basically someone gaining physical access to a computer. Motherboard recently published an article on how a malicious party could add a backdoor to a Dell (example used) laptop in less than 5 minutes [1].
Other examples of relevant techniques used against travellers are: electronic eavesdropping using cell networks, physical monitoring of hotel rooms (e.g. camera surveillance), malicious charging stations and so on. More details on general infiltration techniques can be found in the Mitre ATT&CK's "Initial Access" category (each described on their Wiki [1,2].
Conceptual Overview
Now that we have reviewed the main drivers, the question is if you can protect against the given threat model in an easily achievable way. To assess that we will first have to a look at an conceptual model for travel. Taking a top-down approach, the travel setup will in most cases consist of two components:
- The devices used for travel
- The server side infrastructure
There are arguments for a standalone operation, but the legal ramification and practical impact of sending an employee into a hostile environment with anything but local encryption is risky at best. To note: that is, if the user will actually produce or carry anything of value. If not, a standalone setup may in some cases be argued for.
Tactical no-brainers when travelling are the following:
- The system should disclose as little as possible about the traveller's pattern of activity and content
- As little information as possible should be at rest on devices at risk
- It should come at a high cost to compromise the end-point both for physical and technical exploitation
- The equipment should never be connected to an organisation's service infrastructure directly before, during or after travel
- The system should not be obviously provocative to locals - e.g. during airport inspections.
As far as I have found, there are currently one desktop system that sufficiently meet these criterions - and that is ChromeOS which comes with sane default settings, has a really minimal configuration and is usable to an average person. However, ChromeOS is not a mobile operating system - and for that purpose iOS and Android is a better fit even though they do not tick off all the above boxes.
With that in mind the following model, that I have named "The Tactical Travel Protection Model", provides a hardened, basic infrastructure setup that uses cloud providers to hide in plain sight.
The model further detailed in the following section.
Scalability and Technical Implementation
With the conceptual model shown in the last section, it is time to dive into implementation in a practical situation. The beauty of the model is its modularity, so a component - such as a cloud server, can easily be put in a local and physically controlled location. Thus, please consider the technologies mentioned as an example - the power of the model comes to play when you start switching things up.
Server Side Components
Consider theavailability of external services in all parts of the process. Ideally a travel device should store information only outside the regional location of a traveller. Balance storage with requirements of availability. An example of such is that an enforced VPN connection may not always be available, which would practically leave an SFTP link exposed or down.
For the example technologies used in the model shown in the previous section, following sections shows the use.
Cloud Policy, Provisioning, Device and User Management
The reason we really need to use a device management service is the scalability of deployment. Using a standalone approach may work and provide some additional security due to the independence of each device, but it is inevitable in the long run if you handle even a low amount of travels.
In this case, especially due to using ChromeOS, G Suite is the most straightforward choice. It is important to focus the solution on managing devices when speaking of travels, not pushing sensitive configuration files and so on. If encountering a compromise of the G Suite administrative account - it is possible to push threat actor-controlled applications and configurations to devices. Due to this it is essential to clean out the management domain or create a new, untraceable one once in a while.
G Suite is a granular solution. Examples of recommended policies are: enforced use of security tokens and the disabling of other two factor authentication options, screen lock upon lid close and so on.
When testing G Suite and ChromeOS I figured that it is easiest to
provision VPN configuration files (.onc) and certificates
manually. For iOS the same goes with .mobileconfig. Doing this
adds another protective layer.
VPN
For VPN, my experience is that the most reliable option is using native supported VPN clients in the operating system used for travel. In this case it is ChromeOS with OpenVPN and iOS with IPSec. This adds a bit to the complexity as iOS does not support OpenVPN which runs most reliably in some countries that censors the Internet. However, ChromeOS does. The solution to this is using two VPS nodes for tunneling traffic:
- OpenVPN service through ansible-openvpn-hardened [4]
- IPSec service through [5]. Lenny Zeltser created a deployment-guide on algo recently [6]
Again: to reduce exposure through centrality, you should not provision device-specific keys from central management consoles. Also, make sure to use certificates by any service that needs to connect to the Internet.
OpenVPN:
Configure according to the README on the
ansible-openvpn-hardened Github page. When you deploy the
OpenVPN server, you will be left with a file named something like
<user-id>@<random-word>.preregistration-pki-embedded.ovpn in
the fetched_credentials/<domain> directory. Just like Apple
has its mobileconfig format, the Chromium Project uses the
Open Network Configuration (ONC) [7]. In order to convert this
format to a working configuration file, use ovpn2onc.py [9] like
the following.
python3 reference/convert.py --infile *-pki-embedded.ovpn \
--outfile vpn_configuration.onc --name my_vpn
This results in a configuration file named
vpn_configuration.onc. ChromeOS will not give you any feedback
here, so make sure to read through everything to get it right the
first time. If you end up troubleshooting, I found that the
Chromium project do have some working examples [9]. Import
vpn_configuration.onc in Chrome as shown in the next section.
Due to the hardened setup, be particularly strict to configure with an OS version according to the repo README. For instance Debian 8.10 won't work.
Algo: Has great docs as-is.
SFTP
An SFTP service is simple to manually deploy. However, when
scalability hardening matters it is best to automate the
deployment. Through testing available Ansible scripts I ended up
with Johan Meiring's ansible-sftp [10]. Again, the configuration
is self-explanatory. You should however note that public
keys should be put in a files/ directory under
ansible-sftp root. These can be generated with
ssh-keygen, the private keys needs to be stored somewhere else
for manual transfer to the laptop accessing it.
Since this is a traveller setup you should seek to create a disconnect between cloud drives and rather use local storage and SFTP. Disable OneDrive in Office 365 Business and Google Drive in G Suite.
Deploying an Out-of-Band (OOB) Channel
Communications is king and perhaps one of the most important things you configure.
I described using Matrix and Riot for OOB recently [11].
Security Keys
Nowadays, strong authentication is so easy that everyone should use it. In a hostile environment it is hygiene. Google uses Yubikeys and Feitian tokens in their authentication services and so should a traveller [12,13,14]. This eliminates some of the uncertainty when authenticating against remote servers and is something the traveller can keep on-body at all times. For this setup not every service can maintain usability when using tokens. Those services - such as a mounted SFTP share should use certificates.
Client Side Components
So why a Chromebook?
- Has a minimal configuration. Everything you do is in the browser
- You get granular control through G Suite
- Based on the Linux-kernel, which means it is different from Windows and may require some extra effort from a threat actor
- A lot of work has gone in to the user interface in ChromeOS, so it will feel familiar and intuitive to users
- ChromeOS has a lot of security features built-in [15], such as: Secure Boot, Security Key login and so on.
G Suite will help you a little bit on the way when it comes to configuration control. However, it requires some client-side configuration.
The client side consists of components. I chose to model these as five layers:
The Traveller. The most important asset on the travel is most likely your human traveller. This asset will have some values assigned to it, such as security keys, credentials and his own knowledge. Anonymise information stored here. In other words, make sure to use an identifier and not the travellers real name.
Device and information. When selecting devices and putting information on it you have entered the device and information exposure layer. This will typically consist of all hardware peripherals, such as cameras, and content such as calls made from a handset. Other things to consider here for ChromeOS is deploying PGP and its keys with Mailvelope and Office from Google Play Store.
Content. It was actually kind of interesting to model this from an iOS and ChromeOS perspective, because ChromeOS keeps most of its applications in the browser while iOS has native apps on line with Chrome. This again means that the exposure surface of ChromeOS is more uniform than on iOS.
Native applications. This is the actual applications installed in the operating system directly. For iOS this has larger exposure with native applications for e.g. communications, while on ChromeOS you will basically only install an SFTP plugin to the file system and use Chrome for a travel.
Transport. When travelling to a hostile environment, tunnel all communications to and from the system as far as possible. Both iOS and ChromeOS has sufficient mechanisms here as we reviewed in the previous section. For encryption keys:
- Transfer encryption keys stored in the
.p12file and the configuration to the Chromebook -
Install encryption keys inchrome://settings/certificates. Use the "Import and Bind" option to install the certificate to TPM -
Import the VPN configuration (ONC) inchrome://net-internals/#chromeos
That is basically it.
Conclusion
The art of balancing threat resiliency, usability and cost is an intriguing problem.
The technology out there, presented in this article, is in no way designed to survive in hostile environments when considering the capabilities of nation state threat actors. Fundamental security mechanisms are lacking in this regard, and only companies like Microsoft, Google and Apple can provide the basis to change those. We can however slow these actors down considerably.
An important aspect to consider, in order to compensate for the above weaknesses, is that organisations needs to handle these problems on an operational and strategic level as well.
Using cloud environments are a solid choice for travel. However, when considering threat actors that are able to gain access to the hosts of those environments they are not sufficient. To solve this, the most valuable services may be moved in-house or to a hardened cloud environment. End-to-end encryption is also required when using cloud services, such as when using the included inbox of G Suite.
Please keep in mind that The Tactical Traveler Protection Model is a core model. This article does not cover every aspect. An example of such is encryption and protection of external peripherals and memory devices and operational and strategic considerations.
Organisations have yet to prove a working model resilient to capable adversaries. Hopefully this article will be a foundation to discuss variations and weaknesses in the community.
[2] https://mitre.github.io/attack-navigator/enterprise/
[3] https://attack.mitre.org/wiki/Initial_Access
[4] https://github.com/bau-sec/ansible-openvpn-hardened
[5] https://github.com/trailofbits/algo
[6] https://zeltser.com/deploy-algo-vpn-digital-ocean/
[7] https://www.chromium.org/chromium-os/chromiumos-design-docs/open-network-configuration
[8] https://gist.github.com/tommyskg/6d0eeecc5bab65a49d72f5b16e086976
[9] 32352ad08e/chromeos/test/data/network
[10] https://github.com/johanmeiring/ansible-sftp
[11] https://secdiary.com/2018-07-11-matrix.html
[12] https://krebsonsecurity.com/2018/07/google-security-keys-neutralized-employee-phishing/
[13] https://www.yubico.com/product/yubikey-4-series/#yubikey-4c