Every so often I get asked to do something that’s not related to my employer, or is stuff that results from my activities for my employer. Frequently this is some form of informal consulting/discussion. There was the cloud expo presentation. I’ve been on a couple of “Customer Advisory Boards” because of my container opinions (I have opinions; sometimes people want to listen to them).
This time I was asked to look at a mobile email configuration. This small company was wanting to move away from their expensive solution to a cheaper, more native, setup. I’d been chatting with one of their security guys down the pub and expressed some reservations, so he asked me to take a look. He created me an account on his PoC project and showed me how to onboard my phone.
How I went about this
Now I’m not a blackhat. I’m not a pen-tester. I don’t have toolkits to try and break stuff.
What I do have, though, is decades of experience in building things. And in making mistakes.
So I look at this as “If I was building this, how would I do it? What mistakes might I make?“. This works out pretty well when it comes to supporting vendor products (if a bug appears I can pretty much understand how it came about and so have meaningful conversations wit the vendor; one of them told me I knew their product as well as their own devs).
It can also help find some of the errors in integration between products; when product A and product B need to be combined to provide a service, there’s a chance for errors.
Now in this case the organisation wanted to use an MDM (Mobile Device Management) to provision to mobile phones and use the native email client to talk to an on-premise Exchange environment. They had worked hard on protecting the gateway (need a certificate to authenticate to the perimeter firewall; username/password to authenticate to the Exchange service). However I still felt this risky; it allowed for more ways of leaking data from the device, itself.
SafetyNet
The first issue was getting my phone registered. I had a Moto X Pure that I’d wiped back to factory defaults… except it had an unlocked bootloader. Apparently this was enough to prevent the app registering, saying it tripped SafetyNet.
SafetyNet is a routine that Google provides that will evaluate your device and report on its trustworthiness. It seems they recently updated the tests to report on the bootloader as well.
Fortunately, MagiskRoot made rooting the phone easy. Since I had an
unlocked bootloader I was able to boot into TWRP (not install, just boot),
flashed Magisk, rebooted… and now adb shell and su works. That maybe
the easiest device root I’ve ever done.
Hiding root
This lead to the next problem… now the MDM app refused to register because it detected root. Magisk has a “root cloak” option. Let’s turn that on for the MDM app. Try again. Failure! Hmm.
Oh hey… the MDM app has a debug mode and an option to send logs to any email address. So turn on debug mode, fail to onboard, send the logs.
Ah! It’s detecting /sbin/su exists and so aborting.
Intereresting, /sbin/su is just a symlink to /root/
And hmm… The MDM gets to work. Away we go!
I now had a rooted phone and with the Android “work” profile installed and configured.
What can we find
Because this using the native mail client (“gmail”) inside the profile,
it’s possible to read the contents of /data/user/10/com.google.android.gm/databases/EmailProvider.db. And, yes, this showed the test emails that had
been placed there. Unencrypted, easy to extract. Complete with attachments.
So I’d already proven my point; it’s easy to take an untrusted device, onboard it and extract the data.
Further I was able to see certificates in /data/misc/keystore/user_10.
I didn’t bother to try and decrypt them (they’re stored encrypted, but
the primary key is decryptable using the device password). In theory
this would allow me to connect my Linux desktop to the Exchange environment.
Definitely a way for data to leak the company
But it turned out to be easier
It turns out I wasted a lot of time and effort on this, though. It was a lot easier to export data.
Inside the “work” profile was a copy of the ‘Google Play’ application. This allowed me to install other apps, such as “Word” and “Excel”. It worked well; I could open attachments from email directly in Word and view them. But it also opened a gap; I could connect Word to my personal Dropbox account and then save these attachments to it. Whoops!
Take Aways
The company realised there would be a massive gap in their security posture. I was able to demonstrate two actual paths for data exfiltration (one didn’t even require any specialised knowledge), and one potential. Since “insider attacks” are a big issue, this is something to be concerned about…
They are now looking at enhancing MDM with MAM (Mobile Application Management). The MDM will restrict what applications can be installed to Microsoft ones (Outlook, Word, Excel) and the MAM will restrict what those applications can do (e.g. force encryption at the app layer).
This introduces more complications, but improves their security.
Summary
I’m not a fan of “BYOD” type stuff for email. It really makes keeping your data secure a lot harder. Security of the data is inherently dependent on security of the device and protection of the data stored on that device. This means there a natural tension between the owner the data (the company) and the owner of the device (the employee); the company may want to enforce strong passwords, long PINs, force rotation, disable cut’n’paste… all stuff that may make it harder for the user to use the phone for their own purposes.
This is why “sandbox” applications were popular in the early days; they provided a (semi-)secure environment to hold the company data, while only minimally impacting the device owner.
Mobile operating systems are growing in functionality; Android user profiles are a start in this direction. But they’re still not a sandbox. So using MAM on top of MDM is a necessary component.
I hope I’ll get a chance to kick the tyres on their new setup!