Editor's note
Editor's note
Editor's note
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
Figure 1. Android test platform<br />
tool that can be used for many purposes. Some features<br />
which are particularly useful are:<br />
• The ease with which a user can find relevant<br />
information about exposed application attack vectors<br />
• Command-line interaction with applications on the<br />
device in order to find vulnerabilities<br />
• The ability to write proof-of-concept exploits<br />
for vulnerabilities using a range of pre-defined<br />
commands removing the need for custom application<br />
writing in order to perform tests against a target<br />
vulnerability<br />
The advantage of this approach is that you are<br />
able to obtain wide coverage across the phone and<br />
attempt exploitation without continually rebuilding and<br />
deploying code. The toolkit we developed at MWR<br />
is called Mercury and will soon be available so that<br />
security testers everywhere can benefit from the<br />
flexibility it brings to the testing process.<br />
The tool is still under development but it has already<br />
proven itself as a viable and scalable approach to<br />
Figure 2. Commands<br />
starterkit 02/2011(2)<br />
MOBILE PENTESTING<br />
security testing on the Android platform. As a teaser<br />
here are a couple of screenshots of what you can<br />
expect.<br />
Apple iOS Testing<br />
I will offer you a warning before you start considering<br />
auditing or testing an App that has been written for<br />
iOS, you won’t get very far without a Mac to help you!<br />
That isn’t an advert for Apple, it’s a reality check that<br />
developing for iOS is pretty near impossible without<br />
a Mac and performing security testing is going to be<br />
severely limited without one. When it comes to testing<br />
iPhone, iPod or iPad Apps you will be in one of two<br />
situations, you will have source code or you won’t. I’ll<br />
start with the case that you have source code as that<br />
is much easier and even if you do have it you will likely<br />
want to use elements of the black box approach as<br />
well.<br />
On iOS your source code review will focus on the<br />
same types of things as on any other type of code, the<br />
areas that handle user controlled data, control network<br />
activity and handle security tokens of any kind. To<br />
find vulnerabilities in iOS code you will need to know<br />
Objective C and have a good grasp of the types of poor<br />
coding practice that make more traditional C or C++<br />
applications vulnerable to attack.<br />
One of the most effective methods of honing in on<br />
bugs is to gauge what type of background the developer<br />
or developers have come from. They will typically be<br />
either more experienced coders who have encountered<br />
C or C++ but use the wrong bits of their knowledge<br />
and thereby introduce memory corruption bugs or<br />
developers who are new to programming and more<br />
likely to stick to Apple objective C libraries; however,<br />
are generally less experienced in secure programming.<br />
So no matter who has written the code you have a good<br />
chance of finding security bugs!<br />
The more complex part of testing an iOS application<br />
often comes when you are looking to test an App that<br />
you haven’t been given the source for. Often this occurs<br />
when an organisation wants some assurance about<br />
the security of an application they bought from a 3rd<br />
party where they are<br />
only provided with it<br />
in its compiled format<br />
or when you just<br />
fancy taking a look at<br />
something from the App<br />
Store. In this situation,<br />
outside of playing with<br />
the application on the<br />
device and testing its<br />
advertised features,<br />
Page 16 http://pentestmag.com
Change language