Is iOS really more secure than Android, and why? What are the pros and cons of biometric authentication? How can you know which apps are safe to use, anyway? In episode 46 of Cyber Security Sauna, we dive into a range of common mobile security issues. Who better to answer our questions than a couple of mobile security experts? F-Secure’s Ken Gannon and Ben Knutson joined the show to discuss app permissions, company mobile device management, mobile hygiene tips, signs your phone’s been hacked and more. Plus, is your Facebook app listening in on you, or not?
Listen, or read on for the transcript. And don’t forget to subscribe, rate and review!
ALL EPISODES | FOLLOW US ON TWITTER
Janne: Can you guys briefly talk a little bit about your work in the mobile security realm? Like what do you mainly do?
Ken: I mostly do mobile security at F-Secure for customers. I test applications, devices, really anything that has to do with Android or iOS.
In terms of what I look for, I like to think about mobile security in terms of three different perspectives. The first one is: An application should be able to protect its data from other applications on the device. The second perspective is that an application should be able to protect its data from unauthorized users. And the third perspective is that a device’s software should not be responsible for compromising sensitive information.
If I think about MobSec from those three perspectives, that’s how I usually test my targets, how I go about my day-to-day duties as a mobile security consultant.
Okay. So what about you, Ben?
Ben: I joined the mobile security team with F-Secure around two years ago now. Since then, I’ve been testing apps for all sorts of different clients – mobile applications on iOS and Android, doing device security reviews, reviewing mobile device management solutions and even reviewing some smart devices that pair with smartphone apps.
Throughout that time I’ve learned an awful lot about what goes on under the hood in iOS and Android, and what kinds of common security vulnerabilities can be found in these applications and how they can really ruin your day.
Cool. The first thing I want to get out of the way is there’s a lot of talk about how iOS is secure and Android isn’t. Can you take me through the arguments for both sides?
Ken: So this is something I both love and hate. With Android, it being open sourced and how much it’s been looked into, we have tools, we have techniques, we have methodologies that are tried and tested for the Android operating system itself and those applications. In general, it’s a lot easier to test for Android vulnerabilities. Whereas for iOS, it becomes more of a quote-unquote “hacky solution” where maybe this will work, maybe this won’t work…I might have developed a method of testing X, Y, Z in iOS or their applications….
Ken Gannon
On top of that, I would say, is also how with the Android operating system itself, we have a very fragmented operating system across different OEM vendors. People, either aren’t buying newer devices, or vendors are not updating the devices with the latest security patches. So unless you’re running the latest Google Pixel or Samsung device, then there’s a chance you’re not running a secure operating system with known issues.
While on the other side of that, there’s Apple devices with several years of device support and the only developer of iOS. So unless you’re running a really old device, which on average is like five years now for Apple standards, you’re probably running the latest operating system patches out there.
Ben: I definitely agree with you on the issue of making sure that your OS is up to date and making sure that you have all the latest security patches applied.
I will say though, that in some ways the open source nature of Android and our general understanding of how to test Android applications has made it a lot easier for both developers and security practitioners to assess these applications and has made it a lot easier for Android applications to be developed securely, as opposed to iOS. Of course, you know, we have testing methodology for both. We have tools for both, but I feel like the bar is lower maybe to get into developing a secure Android application versus a secure iOS application.
Okay. One of the frequent arguments I hear is that the iOS, the Apple walled garden sort of protects you from the worst mistakes, cause they don’t let people do as much with the device. So what do you guys think about that?
Ben: I guess my comment would be that Android definitely gives you enough rope to hang yourself, with all of the ways of easily sideloading applications and easily accessing other app stores. But realistically, neither the Google Play store nor the iOS app store are entirely free from malware. And even with the stringent review process that Apple puts in place, even with them requiring you to pay money to get a developer account, people still will put out malicious apps on iOS and they will still get through.
So I don’t think that the walled garden inherently makes iOS more secure. It just makes it a little bit more difficult for the user to do something bad to themselves.
Sure.
Ken: Another perspective to look at that from is how stuff is actually implemented. For example, with both iOS and Android, there is some kind of biometric authentication. So there are going to be a lot of features that are shared between iOS and Android. What it comes down to is how those features are implemented. I will say for sure that there have been cases in the past that I’ve personally seen where a function is implemented securely in iOS when compared to their Android counterpart. A banking app could have a fingerprint authentication, for example, and the way that the banking app implemented fingerprint authentication on iOS was considered secure and uses all the security features, all the fundamental stuff. Whereas for the Android version, it did not.
What it comes down to there is also the developer’s understanding of how to implement specific functions securely and the best practices when it comes to developing for that specific operating system.
You mentioned biometrics there and I definitely want to get back to that, but one of the things that comes up when you’re comparing the two ecosystems is the app stores. Apple only has the one, but on Android, you can find several app stores and find your apps on each one of those. So how does an Android user know which ones are okay to use?
Ken: I personally am not a fan of this question because I ponder this a lot. And the only answer I have right now is probably the least customer-friendly answer out there. Cross-reference the app with the company’s website, and stop downloading random apps on the app store. Which sounds like the most depressing answer I could give for this question, but I’ve been pondering this for a long time and I honestly cannot think of a better solution.
There’s going to be apps developed by reputable companies, and there’s going to be apps developed by non-reputable companies. And there’s going to be just random apps all over, if we’re going to talk about Google, specifically the Google Play store or the Samsung Galaxy store or whatever. What it comes down to is cross-reference with the company website and make sure you have the correct app installed from the company website. And just try to declutter your life from random apps from the app store that you don’t need.
Ben: I would also echo Ken on making sure that you don’t download apps you don’t need, because realistically, how many flashlight applications do you need on your phone? Consider when you’re downloading a new application – both Android and iOS will pop up a million pop-up boxes asking about permissions anytime you download an application. So take a second, if you do end up downloading an app like that, to think, why would this app need this permission? Does my flashlight really need to know my location? Does this NFC reader really need access to all my contacts?
That makes sense. But before we go into the permissions, I’d just like to point out that famously for example, right now, Epic Games is fighting a battle against the Apple App Store. And presumably we might see initiatives like that in the future as well. Where a company just for financial reasons chooses to go outside of the various Android stores, the official ones. So I don’t think we can just say that it’s always going to be bad to go outside of Google Play or the Samsung store or whatever, but does there seem to be like a short, clear answer we can give people, like, this is how you know?
Ben: I think the short clear answer is look into who developed the application and make sure they’re reputable.
Right, okay.
Ken: Like, I’m not going to download Fortnite from mywebsite.attacker.net. I’m going to download Fortnite from whatever Epic’s website is, I forgot right now. But yeah, it’s that kind of security practice. If you’re going to travel outside the app store, make sure you’re downloading it from a reputable site. And if you’re going to download something from the app store, make sure that the app is developed by reputable company.
Yeah. But even if you’re downloading something from like Google Play, there might be malware on it. Ben, you mentioned that every now and then something slips past the iOS radar. So you can’t just trust the app store entirely, is that correct?
Ken: That’s correct. Unfortunately, that’s the world we live in. This is one of the reasons why I also always say don’t just install random stuff on your phone. Just keep what you need on your phone that is minimally required for your daily life.
I would say the biggest example in my head right now is like a level app. You know, a tool that you use to make sure everything is on a flat surface. With phones and the gyroscopes, you can now use an app to measure that. I’m pretty sure if I were to pull up the app store right now there’s at least five different level apps on there. I don’t know which one has malware on it. And then it becomes more of a, do I want to risk that one of those apps has a piece of malware on it?
The truth is, is that unless I decide to sit down on a weekend and decompile the app and look through the source code and see what I can find and look at the HTTP traffic, all the other stuff, just to make sure that the app is not rooted with malware, I’d rather just go to the hardware store and get a level at that point.
(Laughing) Okay. So, well, not all of us have the capability to reverse engineer the application. So I guess Ben, you started talking about the permissions. So maybe that’s something we should be looking at.
Ben: Sure. So obviously it’s not ideal to be looking into the security of an application after you’ve already downloaded it on your personal device, because, you know, by that point it could have already done something malicious. But if you can get a cursory look at, you know, this developer seems at least like a legitimate entity, then you can, once you’ve downloaded the application, then you can take a look and see what happens when you first open it up. Is it going to be asking you for permission to access everything on your phone from, you know, your contacts, permission to make phone calls, permission to read your device’s local storage, things like that?
Some apps do legitimately need those kinds of permissions, but it should always be fairly obvious why an application might need something. For example, Ken, you mentioned the level. That would make sense why the app would need to access your phone’s gyroscope. But if a mobile game is trying to access your location, that should give you pause. If it’s Pokemon Go, then sure. That makes sense. But if it’s just like, you know, a block breaking app, then you should try and think, well, why exactly does this need my location? And should I give it that permission?
Feel free to say no when an app is asking for permission. A lot of the times a legitimate application will recognize the fact that the user doesn’t want to give a permission and will operate with a limited feature set if it actually legitimately needed that permission in the first place.
Ken: That’s a good point.
Ben: Whereas a lot of malicious apps will just say, Oh, sorry, we need your location or else this app won’t work. At which point you can just delete the app and find a different one.
Yeah, that makes sense. Okay. So if I know the app is being developed by a certain party, check their website and see, you know, where the links download the app take me from there. If I know the developer of the app, make sure that the app store I’m using has the correct name as the developer, and so forth, I look at the permissions the app is asking for. But other than that, like talking about the handset itself, what’s a good level of mobile or a minimum level of like infosec hygiene that I should have, passcodes and things like that on my phone?
Ken: I’m going to tell you what I have, and I’m going to tell you what I think the average user is going to tolerate. So for me specifically, I have a 15-character password with fingerprint authentication and a 15-second lockout on the screen where after 15 seconds of inactivity, it completely locks up and requires my fingerprint. Every 48 hours, I think, it requires me to enter my 15-character password again. So as you can imagine, just 15 seconds of inactivity locking itself up ,that right there, I know for a fact that the average user is not going to tolerate that. I tolerate that because I am a security-paranoid person.
For the average person I usually recommend an eight-character password with biometrics, whether that be recognizing the face or the fingerprint. And usually I would recommend like a minute lockout timer. Realistically, if you’re not using your phone a minute or two minutes, that means you’re probably doing something else anyway.
That makes sense. So what are the pros and cons of fingerprint or face ID? I’m not so much worried about like the bad guys faking my face. I’m thinking about situations where like a mugger face IDs me on my phone at gunpoint, or a child is using a sleeping parent’s finger to ID, stuff like that.
Ben: Well, first of all, if a mugger has a gun to your head…this is not just a mobile security thing. This is just a general life tip. If someone has a gun to your head, then just give them what they want. It’s not worth your life.
But on a more general note, obviously the big advantage of biometric authentication is the convenience of it. It’s very quick to just tap a thumb on the home button or just hold the phone up to your face. It’s also actually quite secure, if properly implemented, I’ll add that as a caveat. And I would say that both Android and iOS on an operating system level, like in order to unlock your phone, have implemented biometric authentication securely.
So from an application perspective, as long as the developer has implemented biometric authentication securely in the way that the operating system intends you to, then it can be a very secure method of authentication, because no one can steal your thumb, for example, barring some particularly out-there scenarios.
The downside of biometric authentication is that, first of all, you can’t exactly change your face or your thumbprint. So if, say for example, someone were to, and this has happened in the past by the way, come up with a way to transfer a thumbprint or a face in a way that fools the biometric sensors on a particular device, then that is pretty much compromised forever, because as long as someone has your biometric information, they can just do that as many times as they’d like. So at that point, you have to fall back on a password.
The other nice thing with a password is that you kind of get to decide how, where you want to make the tradeoff between security and convenience. So obviously a 64-character random password is really, really secure, but you’re not going to be able to remember that. Whereas a passphrase of say, 20 to 30 characters of just English words chained one after the other, it’s fairly easy to remember and is pretty secure.
And oftentimes you don’t have to strictly decide between the two. You can use a combination, like for example, how phones can be unlocked with a passcode. And then once that passcode has been entered can be unlocked by a fingerprint or a face for some period of time.
What I do is I use my finger to log on to my phone, but then to my banking apps and the like, I have different authentication methods. So is that like prudent infosec or just farfetched paranoia?
Ben: I think that that is actually a fairly good idea. Just because I cannot tell you the number of times that I’ve been testing an application and the password login is fine. You know, it, it sends a password to the server, the server checks it against what it has on record, and you’re good to go. There’s no way to bypass that from the application’s perspective.
But if you go over to the biometric side of things, the way that biometric authentication generally works is either that the application is asking the biometric sensor, Hey, was this authentication successful? Or the application is pulling some sort of secret from the secure enclave or the secure device storage of your device, and relying on that secure storage to perform the biometric check. And the first of those two ways, just asking the sensor whether or not you succeeded, can be bypassed really easily.
And a lot of the time I’ll find that developers will do things that way, just because that’s what comes up when you Google how to implement biometric authentication.
Ken: Wish he was wrong on that, but it’s true.
Ben: That’s a finding that I have in, I would say probably around 50 to 60 percent of applications that I inspect.
That’s what comes up in Stack Overflow.
Ben: Yeah. So I would say that that’s actually a very prudent way to go about things, just because without actually performing that test yourself, you can’t really know whether the developer has implemented it securely.
Ken: One thing I want to add on to that is if you’re in a situation where you can confidently enter your password into your banking app, I’m hoping that the password you have used for your banking app is a long, unique passphrase that you only use for that app, period. Or bank or whatever. Ideally I’m hoping you’re actually using a password manager.
That’s the main takeaway I get, whenever I hear someone entering their password on the banking app, like what kind of password do you have? I’m more concerned about someone being able to log into your banking app from the desktop or from a different device, if you’re able to easily enter your password every single time into the banking app.
Yeah. Well, I mean, that’s actually what got me started down this path because I’m having this ongoing feud with my bank. They make me choose like a four-digit PIN code and I’m like, why guys? Why are you limiting me like this? And they’re like, well, that’s all people can remember and use. And I’m like, well, screw those people. I can do more, so let me do more.
Ben: Yeah. The real answer is that that PIN code needs to be stored in a server that is 40 years old and cannot accept anything more than four characters.
(Laughing) Yeah. I mean, it’s not quite that bad. There are other factors there, but yeah. Okay, so are there any settings on the phone itself that the user should absolutely have on, or off? Something that’s there by default and you want to make sure you switch it?
Ken: This is definitely a how-paranoid-are-you-type scenario. I’m going to speak strictly on Android right now, because that’s what I use. I use an Android device. By default the Google Pixel line of devices will track your location with Google Maps. I personally like that experience because I like to go back and be like, this is what my life was like in the year 2019, the good old days of 2019. But I know that there is a lot of people out there who don’t like the idea that their phone is tracking them, or don’t like the idea that Google assistant or Siri is technically waiting for that key command to start responding to. It all comes down to what you want out of your life when it comes to privacy.
Now, when it’s security related, I always tell people stop using a four or six digit passcode, use a passphrase for your phone, make sure that the phone asks for your password on bootup and make sure you’re using biometrics, whether it’s fingerprint or facial recognition, and make sure that you have the minimal amount of biometric keys on your device. I’m talking about only your fingerprint, and making sure that only trusted ones like your spouse or someone in case of emergencies, again that’s up to you.
So as a company, what are the things you want to take into account about managing your device fleet?
Ken: This is another answer I’m going to say that’s going to be very controversial to some people, but…just don’t give options. And I’m going to expand on this. So both Ben and I have done tests for different devices, for different deployment solutions and that being, bring your own device or a company managed device. There’s been pros and cons of both scenarios for both Android and iOS or what have you, Blackberry, all that stuff.
What it comes down to though, from what I’ve seen is the more options there are for mobile device solutions in terms of deployment and operating system, the more issues you’re going to run into. It’s going to be a lot easier to, to on the company itself to say, you are going to carry a second iPhone with this company data, and you cannot say, no. It’s going to be easier for the company to manage a single fleet of devices in a single deployment method because they know what to expect.
Whereas if you were to try to deploy bring your own device over Android and iOS over managed devices, and there’s Samsung devices, Pixel devices, Nokia devices. Now you’re expanding the amount of things that need to get tested by the company on a yearly basis. Or even before deployment, what is good, what is bad, that kind of stuff.
Now, that’s strictly from a company perspective. I know for a fact, there’s going to be people out there telling I do not want to carry two devices around. I know people out there who are asked to carry two devices around, and so they take their second device and just forward all the emails to their personal email account on their personal device.
There is going to be a pushback. And the best way to put it is I’m talking from a purely security standpoint, in a perfect world. In a perfect world where people’s feelings don’t matter. Which, let’s face it, people’s feelings matter.
Ben: Yeah. Security on a corporate level is always a mix between technology and office politics. So there’s always going to be that trade-off there. I would generally tend to agree with Ken that as few options as you can give people the better, because realistically your attack surface is the sum total of all of vulnerabilities in all of the options you offer, not any intersection of those.
So if you have bring your own device and corporate owned on both iOS and Android and maybe some Blackberries thrown in for good measure, then you are opening yourself up to a lot more potential problems, because there are just more ways that an attacker can go at a device with corporate data on it.
And for Ken’s example of users setting up their second devices to just forward all their email to their primary device, ideally you’d set up your email solutions so that’s not even possible.
In general, I would just say that I agree with Ken, but in reality, there’s always going to be that level of pushback and how close you can get to that ideal reality is going to depend a lot on political capital and just, you know, office politics in general.
Yeah, okay. We were talking about how to secure your own device and use the user passphrase and so forth. But is there anything a company should do for their managed fleet of devices to make them more secure, sort of beyond what a reasonable user would do?
Ken: The biggest threat to devices and the company’s data are rogue applications, or applications that have not been tested, or applications that have potential malware on it. The biggest example is going to have to be limiting what kind of apps get installed on the device and limiting the types of options that a user can set on their device, making sure that the user cannot lower the, the passcode options, making sure that the user must have X amount of characters in the password and has to change it every so often. I personally don’t like that rule, but I know some companies do.
Okay, so the phones are also devices that have microphones on them, so listening devices. When is it time to leave phones outside the meeting room?
Ken: How big is your tinfoil hat?
Ben: Yeah, exactly. I feel like that’s more of a movie plot line than it is something that’s actually a realistic threat. Because when you have a meeting that is that sensitive, there are probably going to be notes taken of the meeting, correct? And those notes are probably going to be stored somewhere. And from an attacker’s perspective, I really feel like if you have that level of access on someone’s phone, you can probably just get that data through some other channel.
Yeah, okay. So unless your actual threat model actually includes like foreign intelligence agencies, maybe that’s not something you have to worry about.
Ben: Exactly.
Ken: Yeah.
What about Facebook listening in on me?
Ken: My take on that, and this is my personal take is, I have a small tinfoil hat when it comes to that, admittedly. I will say I’ve uninstalled Facebook from my phone, but that was purely because of power and other aspects. It wasn’t because of the listening aspect.
But I have heard stories, I have seen in the past when discussing stuff with your phone around you, all of a sudden Facebook is recommending the thing. I have seen quote, unquote “articles” about how Facebook is listening on you, but I haven’t seen any actual physical data. It’s something I wish I can give a definitive answer on. That’s where I’m at. Small tinfoil hat with that one.
Ben: Yeah. So from my perspective, like Ken, I haven’t seen any actual hard data that shows that Facebook is listening to people. I’ve just seen anecdotal data of, “Oh, I was talking about Brand X and then Facebook advertised Brand X to me.”
And I feel like with an application as high profile as Facebook, and with an application that has that many rumors going around about it, I feel like if it were actually true, some security researcher somewhere would’ve made a name for themselves and just proven that fact. Because ultimately it’s an application on your device, a device that you control, and given enough time and effort, you can reverse engineer anything that’s going on on that device.
From what I’ve read and from what I’ve seen, a lot of that feeling of, “Oh, Facebook is listening to me” is just a testament to just how good their machine learning and how good their tracking of your browsing habits is. Because for example, I am into audio equipment. I look up things about various pieces of audio equipment all the time. And so at some point my friend asked me what I recommended for a headphone amplifier. And so I gave him some options. And then they said that later on Facebook was suggesting those same things to them.
One possibility is that Facebook was listening to us. But another possibility is that Facebook is using your location to see that you come to my house fairly often. And therefore you are correlated with me as a person and may have the same interests. Which one of those is true, hard to say.
But like I said, if Facebook really was listening to people, with the amount of press that’s receiving, someone would have probably proven it by now. That being said, if you’re concerned about privacy as a whole, you probably shouldn’t have a Facebook account in the first place.
Yeah. I don’t think people understand how powerful marketing algorithms are.
Ken: All hail the Facebook algorithm.
There we go. (Laughing) Getting back to your work in mobile security, are there any interesting vulnerabilities you guys have found when looking into people’s applications?
Ken: I am currently looking at the Samsung S20 device. And the only reason I can talk about this now is because Samsung actually patched this issue two weeks ago now, I want to say.
There was an issue at one point where if an attacker was on the same network as you and you happen to click on a malicious link, you could force the Galaxy store to download and install any application you want on the Galaxy store. So then what I did is…we have a testing application called Drozer. It can act as a quote unquote “simulated malicious application” on the device. I managed to get that published on the Samsung Galaxy app store.
So in this case, the attack scenario is I’m an attacker, a person is on my Wi-Fi network. They click on my link and then I automatically install my malicious app on their phone. And then from there, I can…it’s technically remote code execution capabilities on the device itself, but that’s a whole new discussion of application sandboxing and exfiltrating sensitive data, all that stuff.
But yeah, as I said, Samsung patched this two weeks ago as of when this podcast was recorded. So by the time this podcast goes up, I should have something up on our external labs site anyway, discussing what the issue was.
And we’ll certainly link that in show notes. Okay, here’s a couple of questions from our listeners: “I sometimes get approached by people who tell me that their phone was hacked by this or that party. Are you guys seeing a lot of like actual phones getting physically hacked or is there something, some telltale sign is that the users should look for?”
Ken: The biggest telltale sign, I would actually say, is heavy battery usage. If you find that your device is running out of battery faster than what you’re used to, then that probably means that something is running in the background, that should not be running,
Or you just killed your battery doing something crazy, like exposing it to the elements.
Ken: I’m not exactly a fan of the term “My phone was hacked” because that can mean so many things. So my first question would have to be, how, why do you think was hacked? How was it acting differently than what it was before?
Ben: I will also say, if you are concerned about something like that, a real easy way to basically brute force solve the problem is just flash stock firmware on the device, if it’s an Android device. Or restore it via iTunes or Finder on a Mac device, if it’s an iOS device. And that way you can be pretty confident that unless someone is using a zero-day exploit to you know, install a rootkit on the phone, you’re, you’re probably going to be safe if you just reset the device to the way it was when it first came out of the box.
Yeah, okay. And change passwords and all the usual tricks.
Ben: Yep. All the usual security stuff when you feel like your phone may have been, or when you felt like any account may have been compromised.
Ken: One of the benefits of modern devices is that they can automatically self-verify if an operating system has been compromised or self-verify that this operating system is 100% stock. And so if you have an application that’s been installed on your device without your knowledge, in a default scenario where there’s nothing done to the bootloader or nothing done to how the device boots itself, doing a factory reset will for sure get rid of anything that was stalkerware-related or anything malicious on your phone, because at the very end, as long as the boot loader or anything boot-related to your device, wasn’t tampered with, then the operating system itself is also guaranteed to be in a perfect, secure condition.
Cool. Well with that, I think it’s time to thank you guys for being with us today. Thanks guys.
Ben: Good to be here.
Ken: Good to be here. Thank you.
That was our show for today. I hope you enjoyed it. Make sure you subscribe to the podcast, and you can reach us with questions and comments on Twitter @CyberSauna. Thanks for listening.
Categories