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.
It's kind of hard to obfuscate network protocol traffic. Even with non-MITMable SSL/TLS/HSTS, the source and destinations are known. This can lead to tons of additional work.
ReplyDeleteAt this stage, Android, iOS, and BBOS do not gain the benefits of software protection techniques available under Windows or Mac OS X. However, as you said -- all of these can be reversed. Every software protection technique has been defeated by cracklab.ru or unpack.cn. If you are going to test your protections, then go crowdsource some talent. Pay for your protections to be broken by the people who actually break it. As a word of warning -- some require thousands of man-hours to reverse engineer. But once reversed -- the protector is known -- allowing reversers to spend a lot less time the next time they are up against that protector.
For example, if you buy Themida and wrap it around your app -- no "regular" security professional expert is going to break that tomorrow, or next week (or maybe even next month). However, this all predicates on the fact that they haven't already broke it for a previous client on a previous job. Then, they'll have the analysis on your desk by morning. This is how software protection usually works.
There are other ways to test apps, including black-box analysis of their inputs. I agree that we probably need to dig deeper, but we need to add and produce value whenever and wherever we can. It might be easier for some clients to setup a separate server-side instance of their app (running cleartext or giving the consultants the private SSL certs) than it will be to clear it with the legal and appdev departments to allow their intellectual property to be shared with outside consultants (especially if they do not have the proper tech insurance or level of trustworthiness -- some even require a full SIG v6 shared assessment).
However, it is important to apply the triumvirate of appsec "therapy" to every app assessment in order to maximize benefit-effectiveness: Architectural Risk Analysis (ARA), Secure Code Review (SCR), and Threat-Vulnerability Management (TVM).
Andre- You made some good points. The point of the post was to help people understand what they should realistically expect from both approaches, and what the limitations are in a blackbox constrained environment.
ReplyDeleteThe idea of setting up a staging instance brings up a different debate, about testing in production versus a development environment. If you want to know how your current production environment defenses work, then this isn't a viable option. In theory, it should be easy to clone the environment for testing. In reality, it usually doesn't happen. Something usually changes.
@ Jack: I agree that testers should be testing in both staged and prod environments with as-much knowledge as they can be given, including a full runtime environment and a full build of the source code that deploys into that runtime environment, in addition to artifacts such as design docs, test code, performance and network monitoring capabilities, business process capabilities/documentation, and interviews with all of the key players.
ReplyDeleteIt's called a risk assessment. The OCTAVE Allegro approach works nicely as a minimal set-standard, but we can certainly do more.
Great Piece... One of the problems with Apples application delivery mechanism is you have to escrow code. That's an issue.
ReplyDelete@Andre- Absolutely. Testing the application in the production environment is a small piece of the puzzle. Fixing code post-mortem is different than running the full gambit of threat modeling, architectural review, etc early in the development life cycle.
ReplyDelete@Boris- Thanks. It gets back to either being comfortable with a warm and fuzzy based on a limited review versus a comprehensive look at an application. In the end, our clients choose. Our duty as honorable security consultants is to be as honest as possible and guide them in the right direction.