I wanted to take a few minutes to address a small problem that many of us tend to overlook. The knowledge gap regarding content management, internet security, privacy policies, and just plain old good sense application management is slightly starting to close. This is an area that users are beginning to become more and more savvy. However, opportunities exist still when it comes to trust. I will dive more into this conversation of trust later in the page. I remember when I worked solely in the DoD space as a government contractor. I was always baffled at the lack of interest and understanding the private sector seemed to have when it came to security. One of the common buzz words we used in the DoD space was the term “Hardened”. The term explicitly meant to convey a sense of security conscious when referring to Internet Protocol (IP) networks or just security in general. Everyday we would look for better ways to build hardened systems, while closing gaps in physical ports or application ports opened through the installation of software. Fortunate for us or for me rather, it opened my mind to vulnerabilities and what problems spawn from them. I tend to know what to look for and I am aware of the consequences that occur on the contrary. Well, the question to ask is simply this; “How do untrained individuals and untrained application users learn how to become security conscious?”
The answer to that question isn’t as academic as you would think. The complexity of hardening data content, implementing internet security, and applying privacy policies is “somewhat” de-scoped when you consider the technical platform being used. When I refer to the technical platform I am specifically referring to a shift from desktop application to mobile application. Let’s be clear that shifting from desktops to mobile devices DO NOT eliminate the threat of vulnerabilities. Many of us don’t need hard statistics to accept the fact that more users are giving up their desktops and reverting to mobile devices as a primary platform for digital communication. It’s the world we live in so everyone is riding the wave of the Internet of Things (IoT). Let’s shift back to our question mentioned earlier as it relates to untrained individuals and how they learn to be security conscious. Many of those that know me and are aware of my technical background are probably waiting for me to answer that question with an excerpt from a CISSP Book of Knowledge (BOK) or something very extensive. Wrong… It’s actually much simpler than that as it relates to becoming a security conscious mobile user. Basically there are 3 steps I am going to layout that are simple must-do’s that will significantly help you become a security and privacy conscious mobile user. Step [1] Read, Step [2] Read, Step [3] Read.
Yes, if you noticed steps 1 through 3 simply state the same thing, then you have interpreted the sarcasm correctly. Let’s get serious here and dive into some actual things to consider that believe it or not apply to my sarcastic 3-step process. Before I take you there I have to share an analogy of a very weird but true story that my Dad told me about a friend of his. I took my dad with me to buy my first car. I had secured my first good paying job, had a steady income, my expense were very minimal and all looked well for me. I decided to have my dad join me so we could make the car buying process a big deal. However, I knew that my dad being the stern coach that he was, no matter the outcome I would learn some sort of lesson in some way or the other. Moments before the deal was done my sales guy comes out with all of the papers to sign with the car keys to my new car on top of the clipboard of highlighted signature points. I grab the pin and my dad says “hold-on” lets take a closer look at the finance charges that are built into this car payment. Immediately we both discovered that the finance charge or interest rate was 22%. My dad turned to me and asked me if I was willing to give away the farm to get this car. I turned to him and said “what farm” given that I had not heard that slang or saying before. He laughed and said son…My best friend owned several hundred acres of land. His main crop was corn. My friend told me that his property taxes on his farm were eating into his seasonal profits generated from his corn. He had an idea that he would gift his farm land to a relative to assumingly reduce the taxation [doesn’t sound very legal…but, ok] while he would retain his corn business and resume sales to his suppliers. He signed over the farm to his relative, they worked out a corn arrangement and a year later the land was taken under a legal statue called eminent domain. His relative was paid a huge settlement because he was the legal and rightful owner of the land, and the corn was destroyed. Then my dad turned to the sales guy and said, “by the way my friend got nothing but a bad deal by giving away the farm”. Although a strange and really questionable analogy from my aging dad, there is parallelism with regard to giving away the farm as it relates to security policy. Most security vulnerabilities are either a result of the installed software or the permissions installed software have granted. I distinguish installed software to make a distinction between that and native software comprising the operating system of devices. Many of us can relate to installing software that met some sort of interest or need. A small population of developers utilize this eagerness and anxiety against us. Often times software developers know that we really want their application and we are in many cases hesitant or unlikely to read before we install. In many cases of vulnerabilities found on mobile devices that were a result of a software or application install, findings show that the disclosures existed prior to installations but the users failed to read and interpret potential outcomes prior to application installation. A good example of such disclosure, but without the threat of vulnerability is Apple. I own every type of product Apple retails from the Mac mini, iPod, iPhone, iMac, iPad, to the Apple TV. Those of us who use Apple products undoubtedly utilize the iTunes store. It seems like clockwork that every few months 
Apple updates its Software License Agreement (SLA). How many times have you actually read this before downloading and automatically installing your software? Of course there is a population that do, every single time in comparison to a doubly larger population that don’t, every single time.
We now reference the term “Trust” that was used early on. We tend to trust Apple and are likely to click-through to the install without fear of something being in this agreement that will be harmful. Referencing Apple in this case implies a scenario of software distribution service or a developer whom we trust. Is it still a security conscious mentality to not read even when it’s Apple? Absolutely not! How do you know whether you are giving away the farm when you click agree if you don’t read? Let’s look at the other alternative to Apple, which is Google. A few years ago I began to look at what resources were being given to an application when it was installed. The concept behind resources is pretty straightforward. We ask ourselves what things are needed to do a basic task. If I downloaded an application that I could use to make internet calls I can make some very basic untrained assumption that this app would need to have access to my device speaker to allow me to hear, my device microphone to allow me to talk, and probably my touch screen and subsidiary functions to allow control of the software. In this example app, do you think the app needs access or resources to include my contacts? You could make a simple argument and say yes, if you are using an internet calling app it makes sense to have access to your contacts. This is where things get really grey, then cloudy, before turning black. Once we grant unrestricted access to certain resources we become susceptible to information sharing that can potentially be harmful. However, such things are done with our consent. Often times we know, but in reality we don’t know. We don’t know that we are actually giving away the farm.
As I shift to Google and their software platform I first want to highlight the following example is not unique to Android platforms, but the general concept of awareness or non awareness is subject for inspection across the board. I’ll begin with a typical want that inspires many of us to find an app. We generally find an app in an app store that performs a want or need. I recently had a not-so-good experience with a company and I wanted to show my appreciation by posting my experience on Yelp so that others could be aware and of course show my customer loyalty [in my sarcastic voice]. The main objective here was that I simply wanted to post a review. A prerequisite question could be, “What do I have to sacrifice from a securities and vulnerabilities perspective in order to download an app that will let me post a review?” The short answer should be nothing. I shouldn’t have to sacrifice nothing to post a simple feedback reply on Yelp. I must admit that I love Yelp. I think the concept was duly needed from a customer service perspective. But, let’s just step through what’s needed to do such a basic task.
The very first thing I noticed after finding the Yelp app in the Play Store and clicking the install button was a splash screen with about 6 access permissions that you essentially have no modification options to selectively enable or disable. If you take a closer and calculated look at the splash screen “before” you click install you notice that the app needs to access your [1] Identity, [2] Contacts, [3] Location, [4] Photos/Media/Files, [5] Camera, and [6] Microphone. To the untrained and uninformed individual you could or would click on the install button under the assumption that ALL apps yield these permissions. If your thought process is in line with that assumption, you are indeed wrong. We reference again the use of the word “Trust.” Should we allow our perception of Yelp as a company, it services, as well as their notoriety, justify installing the application? It depends! It depends on whether you have enough understanding of the functional capabilities or whether you understand the intended restrictions/limitations of the specific resources being granted. In most users don’t bother to even read the graphical security policies and proceed with installation under assumed good faith. This in fact is a hard and sometimes costly gamble. in this specific instance of Yelp, we could give the app the benefit of the doubt that the resources used are essential for the app’s functionality. On the contrary this isn’t the case with all app’s and not reading before installing could be problematic.
Ok, so we can assume that we all make this mistake sometimes and just install software without applying the necessary due diligence of reading and understanding application permissions prior to install. What do you do after the fact, or what could you do right now? I’ll address this question on an Android platform. In the case of the Yelp app, I installed it and immediately noticed a warning in the device notification window. For starters I want to take a step back and first point you to a handy too
l for Android users. I’ll have to do some research and append an update for compatible apps for iOS, but if you are an Android mobile device user you’re in luck. I highly advice going out to the Google Play Store and downloading a handy device called ES File Explorer. The
core functionality of this app is to provide an ease of use file browsing and file management system. However, the app is much more than that. The app has a nifty analyze feature that scans your phone for vulnerabilities, describes the vulnerabilities, and categorizes the vulnerability by risk level. This process can be done manually by using the analyze button within the app.
Alternatively, once you have the ES File Explorer app installed, it automatically will perform an analysis of newly installed applications unless you manually adjust the settings otherwise. Let’s take a moment to look at our Yelp app again. We saw previously what resources the Yelp app potentially utilizes once installed. Assuming that you installed an app or in this example an app like Yelp, lets dig deep to get a better understanding of what we’ve done or implicitly just how much of the farm we’ve given away.
Using our example app (Yelp) the following permissions were automatically granted during install:
Account Data
Granting account data access is probably one of the most misunderstood and in some cases potentially the scariest permission to grant. In essence this permission looks at various accounts resident on your mobile device. Your device may include such accounts such as Facebook, Twitter, Google, ….etc. This particular permission allows an app to access such accounts and potentially any data attached or accessible to it. This permission has risk potential when the accounts in question contains sensitive information. A good example could be a user who shares and stores their bank account statements on Google drive. Well, you could ask “Who does that?”… Answer: A lot of people! Maybe not things as sensitive as their bank account information, but I most certainly can tell you that many people utilize cloud base services and cloud based accounts to virtually eliminate paper. You could assume anything that could be shared or seen on a piece of paper could find its way to a cloud based account like Drive, Dropbox, etc… Again, why is this relevant? When we consider apps that grant permissions for account data, this sort of accessibility “IS” on the table.
Contacts
The contact permission should be as straight forward as it sounds. In some scenarios it completely makes sense for an app to require access to contacts. However, in other cases access to contacts just don’t make a lot of sense. Given a scenario where an app utilized a sharing resource to aid in email, text message. When we consider contact permissions, an obvious use case would be an app accessing your contact data to allow you to send a message to someone whose contact information already resides on your device. Other obvious use cases could be using your contact information to dial a phone number within a voice-based app. We get it. These are obvious use cases when granting contact permissions are straightforward and just make sense. Well, when does it not make sense to require the use of contacts? I can assure you that nearly every app you install now days grants this permission. If you are using an app that has content that is susceptible to being shared either via text or email you can almost be assured that the developer has written this permission in, and yes…you have allowed access. Well, this actually couldn’t be so bad, right? What if you are someone like me, who uses your contact information for a lot more than just an email and a phone number? Suppose you’re that individual that attached images/pictures to your contacts, their home address, their work address, identifying information of individuals that you frequently need, or God forbid your kid’s school ID or social security number in the contact “Notes”. Folks…these things happen. We are all sometimes guilty of trying to dodge information overload and tend to use technology as a mean to do a quick hand-off. It should be clear how granting this permission could be an eyebrow raiser.
Location
One question that was once very simple is no longer simple at all. We use to be able to answer the question, “What is a mobile phone used for?” Now that mobile phones are smart, when we ask that same question you can no longer say, “make calls.” Your mobile devices either tablets or smart phones do much more than send/receive email (tablets) and route calls (phones). We can consider two aspects [1], what you want your mobile device to do and [2] what it’s capable of doing. Most people like me make a phone call without consideration of the maximum capability or all that our device can do. We just simply want to enter a number, press the green button, and wait for someone to say hello. So, to execute such a simple task, why does your phone need to collect your location data. Phone companies have had this sort of access for many years. When you make a call your phone connects to a tower within proximity. Wireless carriers have a general idea of where a call was generated. Law enforcement have benefited from such data for years. So, why does your Dunkin Donuts app need this data [used as a metaphor]? The answer is mostly based on marketing data used to learn behavior. Companies want to know where you spend your time, how long you are there, and the frequency of your visits. This information is extremely valuable to certain companies. Ok, it’s valuable to companies…we get that. Why do you need to disclose your location when you are simply calling Aunt Sally to see if she took her medicine today? Answer: You don’t! This particular permission should be straight forward, but just in case there is doubt lets drive this one. When this permission is granted within an app you essentially disclose where you are, where you’ve been, and how often you go. Imagine if you went to your friendly Psychiatrist every Friday at 4:00pm. Yes, an app with this permission could validate that. You could also imagine if you worked for a company or had a career that was not-so-public knowledge. This permission could easily make what’s not knowledge, knowledge.
Photos/Media/Files
Photos/Media/File permissions are without a doubt the most concerning. Lets consider the first attribute of this permission, Photos. We all tend to like to snap a good photo when the opportunity presents itself. Now that my mobile device has a 16MP camera (which by this time next year will probably be laughable), I love taking great high-definition pictures of just about anything. The ability to browse to my photo gallery and recall that special moment or a thought-provoking moment is pretty cool. However, that’s my call when I want to do that. How would you feel if that one private photo you took was now sitting on someone’s server while the server owner and their friends were enjoying your photos? Right, not so cool when we think of it this way… When we consider the second attribute (Media), many of us that have phones with the expansion capability go out to the local Best Buy or neighboring electronic store and purchase SD cards. This is a great way to maintain resources, save local storage space, and also have some privacy control by saving to your SD. Well, at least one of those are not quite so. Media granting permission in almost all cases include internal AND external accessibility, which means just because those pictures from Vegas are on an SD card, they are free game to your app when this permission is granted. The third attribute (File) is just flat-out dangerous when in the hands of the enemy. Let’s face it, there are a lot more helpful and really good apps in comparison to those that are truly unhelpful and designed to do harm. In reality we have to face the truth and that truth is that there are some developers who play by different rules. Those different rules include unwanted file access, file manipulation, and even permission changes. In the layman’s term this permission allows others access whom you didn’t intend to, changes to documents or files that were not wanted, and possible allowing something to take place that you actually didn’t want. When this permission is granted you should be extremely cognizant of why this permission is needed.
Camera
When making a mobile device purchase many of us tend to take a moment to assure that our mobile device has a camera. The uses of cameras have also evolved over time. We no longer live in times where a camera’s sole purpose is to take pictures. Actually picture-taking is slowly beginning to take a back seat to streaming video. With add-on apps such as OoVoo, Skype, Tango, Hangout, Peer, and native apps such as FaceTime many users are getting their bang out their buck as it relates to camera usage. It’s simple, we can either take a snap-shot at the ideal moment or capture the moment in video to tell an even better story. Well, what happens when these thing become arbitrary or random task? Specifically, what happens when you phone is sitting there on the coffee table and all of a sudden your camera starts recording or similarly your camera starts taking still shots without you knowledge? This type of control of your camera can indeed be granted via permissions. Even worse, if you combine permissions such as “Account”+”Media+”Camera”, and app could essentially take a picture store it locally, then transfer that image to a shared folder within a cloud account. The camera permission allows an app to have direct control of your camera. The account permission could essentially allow a remote user to create a cloud folder (ie..Google Drive, Dropbox, …etc) and add themselves as a shared user or owner of the folder. Media permissions allow the app to capture a picture locally and potentially sync the image to the mentioned cloud folder. You guessed it, that’s exactly how private pictures you didn’t take or conversations you made reach the internet and potentially to the tabloids if you’re an individual that’s in the public spotlight. Granting camera permissions in itself can be risky. However, when you combine camera permissions with other permissions as discussed throughout, the potential for harm because extremely high.
Microphone
The microphone obviously is an essential component of a mobile phone. When we blanket this discussion as it relates to mobile devices, permissions such as microphone access may not seem all that relevant when you consider devices such as tablets. It may or may not be obvious to some that tablets have very similar hardware to that of mobile phones. In fact when you consider some of the higher-end tablets that include 3G/4G wireless connectivity, the hardware becomes remarkably similar in contrast to a typical smart phone or mobile phone in general. The use case for a microphone is straightforward when you consider making a call. A standard call is simply connecting to your call recipient and speaking into the phone’s microphone to engage your communication. From a software perspective we rely on the visual use of the green go button as a trigger to begin our call and the red stop button to end our call [assuming smart phone application]. The use and understanding of this common human factors design approach also links our perception that when we press the green button to start our call the microphone turns on once the receiving party accepts our call. Additionally, the linked perception is that when we press the red button to end our call [again, assuming smart phone application] the microphone turns off. Given what we’ve already discussed thus far you can already predict where this is going. If you assumed that granting microphone permissions can change the state of when a microphone is on or off outside of the common applications of starting and ending a call, your assumption is correct. Can you imagine your phone resting on your charger at night and all of a sudden the microphone turns on without any visual indicator? There are not-so-many use cases that I can think of where an application needs to have access to your microphone. If an application is not providing voice calling, video chat, or some sort of voice capture, it just doesn’t seem like a permission that makes sense. Again, reverting back to our Yelp app as an example, you could ask yourself, should I grant permission to use my microphone when installing this app just so that I can post a restaurant review?
Clearly these are interpretations and decisions we need to make “before” we click install.
SUMMARY
The breakdown of granted permissions and their potential are eye-opening. I’d like to reiterate that these are not arbitrary permissions but specific permissions that we are required to grant with an installation. Obviously there are technical alternatives to disable some of these permissions, but the how-to is most certainly outside of the scope for this discussion. I’d like to conclude that if your take away about security policies and specifically permissions are much more enlightened than before, then you are probably going to be a lesser or unlikely candidate for some of the broad and installation-type vulnerabilities. The intended audience for this article are those with somewhat of a technical background. However, the target end-user of this article are individuals with less awareness of permissions, data intrusion, and privacy evading. My hopes are that we share this understanding with Mom, Grandma, or the kids that are increasingly likely to install software (an app) without much regard to the topics mentioned here.
[polldaddy poll=9306175]
About the author:
Darren Johnson is a technologist trained in engineering, cybersecurity, product design, software, and systems integration.
Would you like to research other technical areas? Contact Darren today to be connected to research partners geared to providing technical analysis and investigation.
http://www.darrenjohnson.org | All content published and distributed by TEAM with expressed consent
Copyright darrenjohnson.org © 2019. All Rights Reserved.
