13

This question might be vague, that is because I am not sure where to start.

There are a lot of books and courses on pentest focusing on networks, systems, and OS such as windows, yet I haven't been able to find anything on mobile platforms such as iOS/Android.

I am very interested in learning on how to pentest and secure mobile platforms. The real-time content (location, phone-state, phone-calls...), are valuable information, which makes it very interesting.

By my understanding, due to the hardware/components, penetration methodologies are different when dealing with mobile phones.

How and where could I get started and possible create a future profession on mobile pentest?

Scott Pack
  • 15,167
  • 5
  • 61
  • 91
Rick Rhodes
  • 1,082
  • 7
  • 13
  • 2
    Maybe this question should be broken into multiple questions? There is too much to answer - general methodology, android app testing, ios app testing, man-in-the-middle testing using SSL with or without client certificates... Then there's the whole OS/system itself which are probably full of vulns – efr4k Dec 23 '11 at 09:24
  • Also see https://security.stackexchange.com/questions/73584/android-ios-application-security-testing-checklist – Anonymous Platypus Nov 26 '15 at 12:02

3 Answers3

11

Start with the Emulator and Simulator, which are part of the standard SDKs. If you prefer certain environments over others, you will gravitate towards a reliable framework for pen-testing these platforms.

For example, with an iOS app, I always start with the iOS Simulator after building the code in Xcode. I set my Mac OS X system HTTP and SSL/TLS proxy to localhost where I run Burp Suite Professional. Then I launch the app and utilize the Xcode DTrace functionality found with the command-line dtruss tool. I tend to look at the plist files with the smartphonesdumbapps tools.

With Android apps, it's similar. These days, I go back and forth between IntelliJ IDEA and Eclipse, but both have very usable Android SDK integration points. For Eclipse, it's ADT. I like to launch the Emulator via the ADT. I like to interact with the filesystem and memory using the DDMS, which is primarily useful for debugging. When it comes to software tracing though, I tend to hop on an adb shell and strace the processes I'm interested in, along with a simultaneous logcat. For proxying, I typically use a DNS blackhole to create a transparent proxy to Burp Suite Professional using the Emulator's -dns-server flag. It's useful to look at the manifest in ADT as well, especially to look at the permissions and intents.

Much of this changes if you do not have buildable source. Even worse, you could be targeting an app that has self-modifying or self-checking code. In these situations, you will need an approach that involves disassembling and decompiling the app. For iOS, the class-dump-z, otool, otx, and i386codedump tools are a safe bet along with IDA Pro. You can find a lot of information on decompiling Android apps, although ARM debuggers and IDA Pro will come in handy for those apps that are heavily invested in self-modifying or self-checking code protections. There is a lot of information about malware and tools around malware on the Android platform that are tied to this sort of problem. For example, there's a mobile-malware mailing-list.

Some other great resources happen to be the developer documentation combined with hands-on work. Pluralsight and Raywenderlich have some excellent tutorials that cover these platforms -- I've been through all of their material. There are many books from Syngress and OReilly books on Android and iOS -- many of which that cover security and forensics topics quite in depth. There's a book on Cocoa Application Security from Wrox Press that is also worth a look, albeit dated. Most books covering the basics of the base languages (Obj-C and Java) will be useful, although it's also good to understand where mobile app languages and concepts converge (e.g. PhoneGap, MonoTouch, et al).

** UPDATE 3/26/2012 **

I tend to use similar tools, although I've branched out more to the DTrace-Toolkit and iprofiler/Instruments for iOS Simulator apps. I tend to do a lot more work using cycript on a jailbroken iPad 2, which has been an eye-opener (especially along with class-dump-z). For Android, I believe that I forgot to mention the Activity Monitor, which is very useful for launching intents.

A lot of the runtime can be viewed/analyzed/modified by using runtime Obj-C or Java/Smali, so knowledge of these languages and their platform specifics on target devices is not very optional.

Occasionally, I am asked to pen-test apps that are another format (e.g. AIR for iOS/Android, HTML5, Titanium, NDK, et al) but compile as native apps. In this situation, it is best to build (as would have the original developer) and/or reverse engineer every component using a combination of binary, static, and dynamic analysis. This may require use of Flash Professional or another IDE/build-tool.

atdre
  • 18,885
  • 6
  • 58
  • 107
4

The first step of attacking a system is understanding its attack surface. That being said, are mobile devices really all that different? Exploits are written for all software platforms, including apps for mobile platforms. The most common exploits are directory traversal, then buffer overflows.

You should study what has already been done. Read exploit code, write exploit code.

Rory Alsop
  • 61,367
  • 12
  • 115
  • 320
rook
  • 46,916
  • 10
  • 92
  • 181
1

If I were you I would start by defining the threat scenarios relevant to the platforms, then from there you can attribute the most relevant methodologies, tools, techniques and general approaches to each scenario.

The reality is, as mentioned by espengra, so many different approaches can be used to understand each aspect of the attack surface and the attack vectors that you just need to break it down into different tests. There is no "single test to rule them all" approach to this or any other type of testing.

Start off by building your attack tree against the device (Google Schneier and attack trees if you have never heard that term before) I find a decent mind mapping tool the best way of handling this. Once you have a tree, you can refine the attacks into groups and then define the primary testing approach to each major branch.

JabawokJayUK
  • 126
  • 1
  • 3