Thursday 11 May 2017

Assessment Methodologies Part 1: Pentesting IOS Applications


Introduction


Over the next few weeks and months, we will be publishing our step by step guides for how we complete certain areas of Penetration Testing.

The guides include an overview document, usually simply called steps, which is a high-level explanation of the steps to follow and is aligned to a checklist. The checklist approach can be very useful in keeping track of specific tasks status when working in a team and divvying up the work, but it also helps you to focus as you work through an assessment in a methodological approach.

This approach is usually aligned to an industry-standard methodology, such as the OWASP Application or Mobile Application testing guide. Although they have been tailored in order to accommodate certain types of assessment, such as red-teaming, black box, grey box or white box testing etc.

Also, to align to a typical expectation of effort needed to complete an assessment, in order to provide consistency when scoping work and submitting costings for proposals.

Each methodology or assessment walkthrough also comes complete with a set of technical notes, which includes the actual syntax to use when performing certain tasks, such as command line, bash scripts, calling python scripts etc.

The entire folder structure is located via an online share, which will allow for the documents to be updated by us.

With regard to information sources included within the documents, they are essentially a mixture of content copied from the internet, other blog pages, tool setup and manual files and some of our own wording.

Due to this, we are not claiming to own or have copy write over any of the documents, as they are simply a structured collection of information that is usually either freely available on the internet or has been documented in some other format.

We also don't believe in the idea of keeping knowledge of the type of work we do to ourselves, some people in the Profession do still try to do this, which can be extremely frustrating and unhelpful for people entering the industry hoping to pick up skills in order to enhance their own skill set.

Therefore, these document can be freely copied, adapted and used by anyone who thinks they may be of use, without any cost. The idea that by sharing knowledge and information in this way, others can benefit from the know-how in order to apply this when advising clients on how to secure their environment.

Part 1: Pentesting IOS Applications

The first post in this series is a look at how to perform an IOS application assessment on an Apple Iphone, Ipad, Ipod device.

The theory behind the methodology we adopt is that you are looking for design and implementation weaknesses in the application in accordance with industry standard guidelines (OWASP Mobile Application Guidelines)

The security of the device itself is not included in this assessment, as this is a different area of testing (Mobile Device Testing) although, there is an assumption that the application and any data contained may be compromised if a device is stolen or accessed by an attacker.

Therefore, there is a strong emphasis on encryption and authentication, through an application users perspective. To complete an IOS application assessment, you really do need a jailbroken IOS device, there is no getting around it at present and there are no emulators that are up to the Job.

I would suggest a 64-bit iPhone 5s running at least IOS 10.2 - otherwise, you aren't going to be able to assess applications that make use of the more up to date hardware or IOS version.

With regard to prerequisites, you will also need a MAC operating system in order to run the binary analysis and decompilation / code tampering elements.

Do you need to be able to code in C or swift, it would be of huge benefit of course, but altering the code and repackaging the application is a very advanced area, although it's pretty straightforward to remove functionality or amend something, a termed called patching. This can sometimes allow you to bypass a jailbreak detection function or alter SSL cert pinning, all of this is relatively straight forward to do without really knowing much about the code.

The mitigation of this is to obfuscate the code so it can't be decompiled and understood. Realistically, if you have access to decompiled source code and you can recode it, essentially you can do anything you want with it.

The mitigation will be the same, no matter what you can do with the code, it will be to obfuscate it. You can see if the code is ciphered or not without knowing how to write code so you can make the recommendation without knowing how to code just the same as someone who has managed to recompile it.

You will still need to know how to analyse a binary and search through this using strings (looking for hardcoded credentials etc) and how to dump class headers, which may allow you to perform run-time analysis and method hooking to access data in memory or bypass certain features.

This is how certain tools work on a jailbroken device in order to perform jailbreak detection cloaking or cert pinning bypass, such as ssl kill, they hook common classes used by application developers, at runtime.

There is also a need to complete other elements of testing when completing a mobile application assessment if the mobile device interacts with a web service, which most will do.

Therefore elements of a light touch approach to testing the web-based API endpoint - usually via proxying your device through Burp Suite Pro. This is very similar to web application testing, albiet via JSON.

Also, the endpoint application server would need to be included from an infrastructure perspective, which is aligned to the configuration management phase of the OWASP web application testing guide.

These additional elements are usually included in order to provide adequate security assurance of both the mobile application on an end user's device and it's supporting web service and it's supporting infrastructure.

Overview / Checklist / Technical Notes