With the advent of instrumentation frameworks such as Frida (1), mobile application assessment methodology has become increasingly sophisticated. Modern Enterprise environments almost always include a mobile device component and when performing a security assessment for the Enterprise, having the ability to rapidly introspect mobile applications is hugely beneficial to an assessment team.
Most Enterprise mobile applications are essentially just web service specific browser implementations in the sense that the application heavily interacts with a, often obscured, back-end web API.
Because the developers have in their heads an implicit assumption that only they are going to be peeking under the covers of their application, they often miss the subtle things that can be done with their API or the data they are sending to the mobile device.
So as a penetration tester, you can ask yourself these questions:
What data is available to the user of the application that could be used in a sensitive way. Is there geolocation data for other users? Is there information sent to the mobile device that is not displayed, but is highly interesting and can be correlated with other data to reveal something sensitive?
How much of the application's security is client side and not enforced by the server? This used to be common in web applications, but in mobile applications it is now a huge problem. Remember all the old bugs where you could set a price to -1 dollars and get something for free...
What rate limits are set on authentication attempts, if any?
Are there any input injection vulnerabilities in the back-end servers? Can I send weird data to another mobile device that confuses it?
These are all questions that you would ask in any web application assessment, but now, you want to ask them in the mobile world. And of course, these questions cannot be answered by automated static analysis, so exposing this to a human is a key feature of any toolset.
Having the ability to take an existing application and instrumenting it to interact with its back-end service in controlled ways hugely increases the ability to determine API semantics and attack surface scope without having to jump through a lot of code analysis hoops. It also allows you to quickly change the behavior of an existing application in an effort to make the back-end service perform actions it was never intended to perform or return data that was not intended to be visible to the end user.
Most Enterprise mobile applications are essentially just web service specific browser implementations in the sense that the application heavily interacts with a, often obscured, back-end web API.
Because the developers have in their heads an implicit assumption that only they are going to be peeking under the covers of their application, they often miss the subtle things that can be done with their API or the data they are sending to the mobile device.
So as a penetration tester, you can ask yourself these questions:
What data is available to the user of the application that could be used in a sensitive way. Is there geolocation data for other users? Is there information sent to the mobile device that is not displayed, but is highly interesting and can be correlated with other data to reveal something sensitive?
How much of the application's security is client side and not enforced by the server? This used to be common in web applications, but in mobile applications it is now a huge problem. Remember all the old bugs where you could set a price to -1 dollars and get something for free...
What rate limits are set on authentication attempts, if any?
Are there any input injection vulnerabilities in the back-end servers? Can I send weird data to another mobile device that confuses it?
These are all questions that you would ask in any web application assessment, but now, you want to ask them in the mobile world. And of course, these questions cannot be answered by automated static analysis, so exposing this to a human is a key feature of any toolset.
Having the ability to take an existing application and instrumenting it to interact with its back-end service in controlled ways hugely increases the ability to determine API semantics and attack surface scope without having to jump through a lot of code analysis hoops. It also allows you to quickly change the behavior of an existing application in an effort to make the back-end service perform actions it was never intended to perform or return data that was not intended to be visible to the end user.
Normally dealing with such analysis on mobile OSes can be frustrating as usually one would rely on the availability of public jailbreaks in order to jailbreak the device and then bypass the restrictions imposed by the mobile OS itself on outside application instrumentation. This is specifically true for iOS. But being too low level is a huge problem! You want to interact with the application the way the developers do - using the objects and functions they created!
As such, our consulting team has a reoccurring need to fully instrument and alter the runtime behavior of a given mobile application on iOS, but without having to rely on jailbreaks. This spawned the development of BLACKBUCK: a jailbreak agnostic iOS application instrumentation framework which we use to perform our mobile assessments (as you know if you are a customer :).
BLACKBUCK
BLACKBUCK builds on top of a variety of existing analysis frameworks. It currently links frida-gum, capstone and a ctypes bridging framework that allows us to interact with Objective-C directly from Python. BLACKBUCK is essentially an iOS injectable dylib that provides a runtime Python-based bridge into the iOS application's runtime internals including its Objective-C objects and methods.
BLACKBUCK currently only supports iOS. For BLACKBUCK delivery on non-jailbroken iOS we use a second Immunity tool which we called JOEY.
JOEY
The way you generally modify an iOS mobile application without relying on a jailbreak is to first obtain a valid certificate from Apple, then modify the target mobile app Mach-O binary so that it loads a custom dynamic library, re-sign and re-package everything, and then re-install the app to the device.
This is the general modus operandi for non-AppStore apps. Such as apps that are given to you by e.g. the Enterprise customer you are performing an assessment for and which lack the usual AppStore encryption layer. For AppStore based apps, you would first dump the decrypted application from memory and then proceed just as you would with a non-AppStore app.
JOEY automates the non-AppStore scenario, since there are already tools available to perform the memory dump rebuild for AppStore apps, JOEY currently does not include such functionality. It is, however, on the docket for a future release.
JOEY is written in PyQT and as such JOEY's front-end can run on anything that can run Python and the QT framework. The JOEY back-end has to run on Mac OS X which is where the actual code signing occurs.
The way JOEY works is very simple: you pass the original IPA package, the dylib you want to inject, and provide a destination path for the re-signed package. JOEY will then build the repackaged application it for you that includes your custom dylib.
BLACKBUCK IN ACTION
BLACKBUCK is written in Python and provides an API to interact with all the frameworks we rely on, which means we can directly access a lot of the features that are normally internal to e.g. Frida.
As mentioned previously we also have the ability to interact with Objective-C code directly from Python. This Python layer allows you to implement an Objective-C class entirely in Python, hook Objective-C methods with Python methods, and so on and so forth.
Currently you can interact with BLACKBUCK either by uploading Python modules to have them executed or imported, or by accessing the BLACKBUCK web interface.
 |
| BLACKBUCK web interface |
The BLACKBUCK web interface is very useful and allows us to interact with and control our hijacked application via BLACKBUCK. You could also use the alternate interaction method (file upload) to upload a Python module and then import it into the runtime session to start inspecting and influencing the application.
So now that you have a basic idea of what BLACKBUCK is, let's have a look at a demo:
1. Frida - http://www.frida.re
No comments:
Post a Comment