Based on your view as a security researcher, do you feel the mobile industry is improving in security?
Yes, security is always moving forward and forcing attackers to take different approaches to be successful. Over the last couple of years Android exploitation has been getting increasingly annoying for attackers with technologies like ASLR, SE for Android and the beginning of dm-verity, etc but unfortunately these technologies don’t stop poorly written apps from wrecking havoc, leaking data, and therefore leaving low hanging fruit on the table. Mobile devices have such rich APIs that most of the valuable data an attacker would like is exposed not just at the OS layer but at the app layer as well. Containerization isn’t the silver bullet here either. The mobile space has changed an attacker’s focus from being primarily web browsers to a broader set of apps that each have potential for unique implementation flaws. While you might think iOS would be less affected by this because the system provides so much functionality, we’re still seeing SSL issues on apps in the App store. Android has also caught up to iOS on some security features like ASLR but has some challenges around forking from Zygote and return oriented programming attacks. I’d encourage folks to check out the Android Hacker’s Handbook for more information on this… or hit up @pof :-) At the end of the day vendors always have the really difficult job of trying to defend a huge attack surface on general purpose operating systems and it seems Apple sometimes has the upper hand in rolling out updates because of the monoculture. I also prefer Apple’s privacy controls regarding access to contacts, photos, etc, and was a little disappointed when Google pulled the UI for App Ops which seemed like a step in the right direction. The good thing is that for Android there are other choices like Cyanogenmod which opens up access to useful power-user tools like XPrivacy. But not everyone can or wants to go down this path and they really shouldn’t have to.
How often do you find new malware on mobile devices?
We’ve created tools that enable us to find new types of bad/malicious apps and behaviors rather than focusing on creating signatures for day to day malware findings. the malware analysis market is already fairly saturated and quite frankly it’s too easy for a malicious actor to change up the malware’s signatures and potentially go undetected. Usually once a signature is available the malware author has already probably reached their goal. Techniques for creating polymorphic malware are highly developed and have been long before mobile technology was around and are just as effective today. Signature detection also has a huge hit on battery performance for mobile devices and so the experience of waiting for malware checkers to run on laptops is just a non-starter for mobile tech and especially the IoT. rather than looking for malware I think we’re more interested in apps that leak privacy related sensitive information or have vulnerabilities that allow for things like remote access and/or privilege escalation on people’s devices. however, we have run many app file hashes through malicious signature detectors and have found known malware on user devices, often malicious apps from third party markets. Occasionally we find an app on a user’s device that was pulled from the Google Play store and this can be a hint that Google took it down for perhaps a good reason and might be worth investigating further. lastly there are pretty sketchy virus scanner apps out there… I always find it interesting to figure out the origin of the companies and the larger organizations they may be a part of. Using our app people might be surprised to learn about where these companies host their data centers...
What is the most common use case you are solving?
Privacy and security scoring of applications. We want to give our users the ability to know what issues exist in their applications before they install them and make an informed decision about the risk of continuing to use the apps they’ve already installed. when a new discovery is made about the security/privacy of an app we also want to have a mechanism to inform users of that vulnerability and how it affects their risk score. We also have built a web portal for securely informing developers of the flaws present in their apps when we can find contact information. We provide information to reproduce the issue as well as CVSS scores and the CWEs that are relevant to the vulnerabilities. We wish every developer had a security@company.com email address to contact for security issues. It’s not industry standard yet it seems. Another thing we want is to detect when developers copy the same vulnerable code from stackoverflow and use it in their applications. To that end we’ve looked at tools to help us index reverse engineered source code and to help us find these patterns in a scalable manner. For the research community we are also very interested in having easy access to the newest version of applications but also tracking trends in the older versions. We have in our data stores many terrabytes of applications including the old versions and it’s incredibly interesting to be able to go back and see what a developer may have been thinking. We can see the evolution of WhatsApp’s encryption of messages and see the improvement over time, what algorithms they may have used, etc.
“I must admit, I didn't even know there was a security issue in the Webview component of Android, until a new update showed up on my Nexus7 tablet. It was called "Android System Webview", and it looked like a system component that has been made updateable thru the Play store. Sure enough, I found a few articles that describe why this was done: http://www.androidauthority.com/google-webview-lollipop-devices-593846/ https://www.infinum.co/the-capsized-eight/articles/the-updateable-webview-on-android-5-lollipop-what-is-it-and-why-should-you-care So I was hoping you could comment on the severity of this Webview Exploit, and the implications of Google not fixing it, and expecting the smartphone vendors themselves to provide a patch.”
I reached out to the R&D team to get a little more consensus on an answer here. The devices < 4.4 devices are currently under control of the OEMs and it’s generally considered that the carriers/manufacturers are probably the ones to finger regarding delayed updates. Google helping OEMs patch this specific issue is probably much less a priority than helping the OEMs getting to the latest AOSP versions which have fixes for this and many other important issues. We have at least one example of a bug that we’ve been working on disclosing where the OEM is challenged by working with a carrier to try and get patches pushed out and that timeline is around 6 months at a minimum--originally they wanted us to hold off for a year. We’re working with US CERT to get that disclosure process completed in a more timely manner because we don’t believe such long disclosure timelines are good for our users or the industry. Similar to our findings with #corrupdate but more severe and pernicious...
How did you get into security research?
Curiosity with video games, reverse engineering, open source and software development, tinkering/breaking hardware and software. I spent some time reverse engineering diablo and starcraft back in the day--for interoperability purposes... :-) In particular I was very interested in the aspects of network authentication and client-server trust relationships in multiple video games...
What are some of the favorite tools that you utilize for research and testing?
- Xposed/Cydia Substrate -- dynamic analysis, hooking dalvik to get function traces, do taint analysis (data tagging)...
- IDA Pro -- reverse engineer/static analysis
- JEB decompiler - decompile dalvik back to mostly functioning Java
- mitmproxy/burp - MITM of network connections
- drozer - in situ agent for exploring devices and OS
- node.js/python for writing new tools!
As a director, where do you determine when your team will automate testing and where they’ll do complete manual testing?
It’s rare that one of researchers finds an application without a single flaw. each time we start a new analysis of an application we take previous experiences with us and the tools that we’ve built along the way. once we find a certain class of bug we will try and go back in an automated manner to find it everywhere else... often we’ll start w/ manual testing to get inspired and find common design flaws / workflows Example: Dropbox sdk issue was announced, now use our automated analysis and signature checker to find all applications on the store that use the vulnerable version of the SDK... Occasionally we get some inspiration from standardized lexicon of design flaws, i.e., CWE, OWASP Top 10 and make sure the basics are covered Common flaws like lack of integrity checks or SSL MITM attacks which enable other things like potential for remote code execution in some situations, like #corrupdate. Sometimes these require actually executing the applications and so we’ve written tools to automate the UI interaction with the applications, detecting UI elements like username and password boxes and automatically entering the data where appropriate. We’ll also taint the data that the apps receive so that we can see when it’s transmitted over the network for example. As NowSecure has its roots in forensics, we often spend some time thinking about the ramifications of certain local attacks. We like thinking about different attack vectors from the perspective of local vs remote attacks and lately we’ve been much more focused on remote attacks. As for our tools we’ve really been adopting the unix philosophy for building new tools, keeping them small and narrowly focused. I’m also a big fan of docker and removing the burden of gathering up dependencies for tools and instead creating containers. Our VP of Engineering Paolo Fragomeni has had a lot of influence on some of our thinking about how we write our tools in Node.js.
What are some of your favorite projects?
- radare -- pancake (sergi) works @ NS now!
- APTNotes -- tracking public disclosures of “advanced persistent threat” activities. very few mobile things here so far but history repeats itself….
- android security awesome -- collection of awesome tools and readings on Android security
- droidsec -- collection of Android security experts