Mobile device malware is approaching exponential growth. Mobile apps are the vehicle of choice to deliver malware. Michael P. Kassner looks at our options.
Mobile-security pundits preach incessantly about the need to be careful when downloading mobile applications. That's because many are not what they seem. According to TrendMicro's annual report, "Evolved Threats in a Post-PC World":
2012 erased any doubt that the malware threat for mobile devices is real. The number of Android malware shot up from 1,000 at the start of the year to 350,000 by year's end.
Imagine that kind of increase in your pay packet (I digress, apologies). Since TrendMicro was more concerned with types of malware, not what the malware did, I read "A Survey of Mobile Malware in the Wild" by a research team from University of California, Berkeley. What they found is more to the point:
We find that the most common malicious activities are collecting user information (61%) and sending premium-rate SMS messages (52%), in addition to malware that was written for novelty or amusement, credential theft, SMS spam, search engine optimization fraud, and ransom.
That should give you an idea of what the bad guys are looking for. So how does malware find its way onto a smartphone?
Currently, the most efficient way to load malware is through bad-guy designed mobile applications. Where malware developers incorporate their code into what appears to be credible software. So we happily install it, and in the case of Android apps, dutifully grant applications trying to install all the permissions asked for. After which, we become victims of identity or financial theft.
It's hard to get a feel for the number of good applications versus bad ones offered by app stores. I'd guess (guess being the operative word) that most are not malicious. My problem -- I really suck at guessing, so I'd appreciate being able to determine if a mobile application is safe to load or not. Thankfully, there is a way.
ZAP by Zscaler
In preparing that article, I had several conversations with Michael Sutton, Vice President of Security Research at Zscaler. Michael, being a patient sort, put up with all sorts of new questions for this article. Before I get to them, here are some preliminaries about ZAP.
ZAP provides two ways to test mobile applications -- Search and Scan. Zscaler has already tested many existing applications and by entering the app's name into the Search function, you will learn how it behaves.
Here are the results from entering Skype.
Next, the Scan function.
I asked Michael if there was any benefit to running the scan versus searching for results:
Search results provide a high-level overview of a past scan. If you want full details on an app, you'll want to run the scan feature.
In either case, ZAP checks the following:
- Authentication: Username/password sent in clear text or using weak encoding methods.
- Device Metadata Leakage: Data that can identify an individual device, such as the Unique Device Identifier (UDID).
- Personally Identifiable Information Leakage: Data that can identify an individual user, such as an email address, phone number or mailing address.
- Exposed content: Communication with third parties such as advertising or analytics sites.
Now let's get to the questions.Kassner: On the webpage introducing ZAP, you mention mobile applications behave like custom web browsers. I have not thought of them that way. Should we be concerned because they are? Sutton: What I mean there is that the apps send network traffic and the protocols of choice are overwhelmingly HTTP/HTTPS. So they behave much like a browser, but do not have the same security protections. For example, you cannot tell what remote site you're sending traffic to as there's no address bar. And, you can't tell if the traffic is being sent securely. There's no padlock to indicate whether the app is using SSL or not. Kassner: Again, on the page introducing ZAP, you mention:
Being an inline security solution inspecting web traffic, it's imperative that we're able to not only analyze traditional web traffic, but also web traffic sent by mobile applications.
What does inline security solution mean?Sutton: Being inline we can look at content actually sent to and from the application. In doing so, we're able to identify privacy implications and coding flaws. For example, an application may send your password in clear text. As this is a mobile application, and not a web browser, there is no visual indicator to inform you whether your password is sent securely or not. You must blindly trust the application. By sitting inline, ZAP can quickly and easily identify if that is happening. Kassner: When you say inline, you mean ZAP acts like a Man in the Middle (MitM). Correct? Sutton: By design, ZAP is a MitM. It intercepts and monitors the traffic between the phone and the application's remote server. Scanning this way allows us to determine if the app is leaking information.
We ask that you enter fake data into a window like the one shown above. We compare the information given us to any we find leaking from the application -- for example, the password you gave us. You enter the same password when using the app. If we see the password traversing the wire in clear text, we then know the app is sending your information insecurely.Kassner: Getting set up to run the Scan function is not for the faint-hearted; do you have pointers to make it easier? Sutton: There is some basic setup involved in using ZAP, namely, changing the proxy settings on your phone. We've tried to make this as intuitive as possible by providing a video walkthrough. Also, during the scan, a popup window will automatically show you step by step what is required. Kassner: Why should we trust your results? Sutton: We try to be as transparent as possible. When you scan an app, we show you the captured data. That way when we say an application was leaking your password, you can also see the data packet where that occurred, and know definitively the password you provided was sent in clear text.
Final thoughtsI have used both the Search and Scan functions. I like how the Scan results display the captured traffic as individual packets, something I haven't been able to do easily when testing mobile devices. To see what I mean, I'd recommend watching the video; it is extremely helpful in setting up the Scan function, and when trying to interpret the test results.
I would like to thank Michael Sutton for answering my questions, and Zscaler for providing a way for us to steer clear of malicious mobile applications.