By Lee Neely
Mobile device administrators and end users need to be more cognizant of the risks of allowing unauthorized access to their smartphones and take steps to raise the bar on accessing those devices to mitigate those risks.
This is part one of two articles on securing mobile device access. In this article, I am going to focus on securing access to the physical device itself. In part two, I will discuss on-device security APIs and how one would know they are still in place.
The case for a strong passcode
When the first smartphones were introduced, they were corporate owned, managed, and secured to business standards. Device access was on par with accessing corporate laptop systems. The number, variety, and quantity of applications and personal or sensitive information stored on the device was far less than we see in modern iOS, Android, Windows Mobile, and other devices. While there were
By Joshua Wright
In the last installment of this article
, we looked at the IsItDown
application, and how it is designed not to run in the Android Emulator, and to include a super-annoying banner ad. We showed how the Apktool
utility can be used to decompile an Android APK file, and how we can evaluate and modify the produced Smali code to manipulate the application's functionality.
In this final installment, we'll re-build the IsItDown application with our Smali file changes, then
By Joshua Wright
As a security professional, I'm called on to evaluate the security of Android applications on a regular basis. This evaluation process usually takes on one of two forms:
- Evaluate app security from an end-user perspective
- Evaluate app security from a publisher perspective
While there is a lot of overlap between the two processes, the difference effectively boils down to this: whose risk perspective does my customer care about the most?
When an app publisher wants me to evaluate the security of their Android app, I need to determine if the app employs sufficient controls to protect the required app functionality and publisher brand. Often, this
By Lee Neely & Chris Crowley
Recent updates to the Android OS have changed the permission model for external storage, and these changes will likely impact the way pen testers assess the actions and corresponding risks associated with applications, both malicious and benign, particularly when analyzing how they interact with external storage.
Consider this scenario: You are provided an application from an unknown third party to assess. Your assignment is to assess both the behavior and trustworthiness of the application. Because of the permission model changes, the application behaves differently when trying to access external storage than it would have in earlier releases of the Android OS.
In this article, we'll provide information on how the permission model changed and some tips and techniques you can leverage when you are assessing an application in your next Android pen test.
There were two changes ...
[Editor's Note: With last week's release of iOS 8, we enter a new era of security fixes and issues for Apple's flagship mobile operating system. But, even this latest version faces an issue that comes up regularly with iOS and other mobile operating systems: Lock Screen Bypass. In fact, there are dozens of different ways to bypass the Lock Screen on a device, each applicable to different versions and subversions of iOS. Thankfully, Raul Siles has inventoried a whole bunch of them in this article, providing a useful reference for penetration testers who need to show the risks associated with a given iOS feature or version number. Raul also offers tips for hardening iPhones and iPads against these kinds of attacks. Nifty stuff! --Ed.]
By Raul Siles
The iOS mobile platform has been subject to numerous lock screen bypass vulnerabilities across multiple versions. Although Apple strives to fix these vulnerabilities in various updates to iOS (