07 Jun, 2011

Blackbox Vs. Whitebox Mobile Security Testing

by Ken Johnson

When you distribute a mobile application via any of the app stores (Apple, Android Market, etc), it is important to understand that your code can be and will be reverse engineered.  Non-obfuscated Android apps are generally the fastest to reverse engineer, but with enough time any application will suffer the same fate.  Code obfuscation is more of a speed bump than a roadblock.  If you are paying a third party consultant to reverse engineer your application, keep in mind that this is time and money that could likely be better spent looking for serious security issues within the application instead.

The first type of testing we’ll discuss is pure blackbox testing.  Anyone that has performed a blackbox mobile application assessment against a compiled application has likely encountered scenarios that made testing extremely difficult.   Funky encoding formats, proprietary protocols, and other issues to deal with can consume a considerable amount of time (billable time) while assessing an application.  

While this may be acceptable for an attacker (with unlimited time), in a time-boxed assessment this can eat into the amount of time spent looking for real security issues.  Issues that may be trivial to detect with enough time can be overlooked in a pure blackbox scenario simply because the consultant ran out of time at the end of the engagement.

In a whitebox scenario, the security tester has complete access to the original source code.  With source code for the client-side app, a security tester can execute and debug the app within an IDE.  The application still runs on an actual device or emulator/simulator, but the application’s flow of execution can be tightly controlled through the IDE.   Methodically debugging in Eclipse or Xcode is much more efficient than other methods of testing.  Having the luxury to set breakpoints at key areas within the application can give a skilled tester the ability to do magical things. 

In addition to being able to quickly and accurately validate issues on the client, a security tester can easily deal with issues like custom encoding or proprietary transmission protocols by hooking in methods to fuzz the application when source code is provided.  This makes testing the mobile app itself much easier, as well as testing remote services.  Increased efficiency = your money is best utilized looking for security problems and offering solid remediation guidance.

When we scope mobile assessments for our clients, we explain the pros and cons of each approach.  We’ve found that upon giving a detailed explanation of both approaches and setting realistic expectations upfront, clients favor efficiency and a more comprehensive review.  Security by obscurity has never worked, and will never work.