Shit · 2016/06/22 10:11
author:[email protected]
0 x00 “Hotpatch” profile
IOS App developers often ask this question: When a new version online and found there is a serious bug, likely as a logical problem lead to payment is interfaces exist while the risk of wool, this time can do is to repair the security issues and make appstore audit, in the quickly push users to update as soon as possible, avoid to cause serious security consequences. To solve this problem, there are a lot of “real-time patching” solutions for apps, and there are basically two main types of “hot fix” projects.
The basic principles can be divided into the following two categories,
The principle is also a bridge to build the conversion between JS script and Object-C language.
-
WaxPatch (Lua calls OC)
-
JSPatch (Javascript call OC)
“Hotfix” technology greatly reduces the time developers have to update patches and the cost to the business, but it puts at high risk the security ecosystem That Apple has worked so hard to build — the strict censorship rules for apps on the Apple Store. This technology allows you to update your App’s native code directly after launch, in a way that circumvents Apple Store censorship rules.
0x01 Principle Analysis
This approach is implemented through the Built-in IOS javascriptCore. framework mini-framework, which is officially launched by Apple after IOS7 mainly used to provide a Javascript environment in Objective-C.
Instead of using the JSExport protocol to intercommunicate with OC code, JSPatch uses a JSBinding and Runtime in Objective-C, Using javascriptCore. framework framework as the engine to parse javascript, and the client code real-time interaction dynamic modification OC method of a scheme.
The entire client object conversion process is as follows:
Javascriptcore. framework is used as a Javascript engine to parse Javascript scripts, execute Javascript code, and bridge with objective-C code. On the other hand, the method swizzling approach in objective-c runtime and ForwardInvocation of messages make it possible to call any objective-c method in JavaScript.
General execution process:
Javascript-> JavaScriptCore Framework-> Objective-C-> Runtime -> Dynamically modify IMP
(More like Webview code execution with Android?)
The following figure shows how to embed JSPatch in client code.
After that, the client will download and request the JS script to update the client code each time the client starts.
0x02 Security risks Exist
JSPatch does have a lot of benefits for IOS developers, but such a high level of access can lead to malicious users doing bad things with it if not used properly.
The foreseeable risks mainly come from the following aspects:
Transmission process security problem
Server in distributed JS update patch if if Https is not used in the process of transmission, or when the Https certificate do not strictly check, or to do data tamper-proof plan, update patches in the process of transmission is a malicious attacker hijacked to tamper with the patch data transmission, can cause great harm, such as command execution, etc..
Practice is the mother of wisdom. Since we did not find a suitable App to demonstrate, we used virtual machines as jumpers to simply set up a middleman scenario:
Vm IP: 10.180.145.17 This machine acts as a middleman.
This machine builds a simple server for App update script server, which is used to deliver Jspatch scripts.
Add the url for the patch to be updated to object-c in the test App (embedded in JPEngine) :
Url: http://10.180.144.1:8081/static/js/test.js
This JS patch was originally intended to print 222 numbers on the screen, but the App did not use Https for secure transmission and did not tamper with transmitted data when updating the patch, such as the following scenarios:
-
Https is not used during the transfer
-
Https is used during transmission, but the Https certificate is not verified correctly.
-
Https is not used and data is not tampered with.
The entire transmission process is visible in clear text:
After the patch is loaded, the following information is displayed:
Then we create a new patch to deliver:
By default, Apple does not allow calls to private apis (which are reviewed by the App Store upon launch), but with the JSPatch engine, it is possible to call private apis to access private device information.
An accounts. framework is loaded to get account information from the device.
Replace remotely loaded Js:
After that, JSPatch was successfully used to update the client code to read and retrieve the device account information :46
Forty-six accounts are displayed in the App.
In addition, there are many private frameworks to call, of course, this is only suitable for jailbroken phones, such permission is very scary.
Malicious third party SDK
Similar to the security of the transmission process, third-party SDKS greatly expand the functions of the App, but it cannot guarantee that the developers of these SDKS are free from malicious developers. Malicious SDKS can use JSPatch to issue malicious scripts and steal sensitive data or do some sensitive operations on the system with the permission of the App.
Three local tamper downloads updated javascript scripts
If the local update script is downloaded without encryption, it can be modified to execute any OC code js script by tampering with the local update patch, which can also execute any code.
0x03 Other Risks
Patch Transmission Security
When using JSPatch, you must pay attention to the security of the transfer process. Use Https transfer, or use RSA recommended by the author to check the JS patch delivered, or use the Loader provided by the author.
The third party SDK
When using the THIRD-PARTY SDK, it is necessary to check whether JSPatch is embedded, so as to prevent the use of App permissions to do some bad things to the system, or steal App user information.
The local store
When updating patches, encrypt the stored patches to prevent code execution caused by data tampering.
reference
- www.fireeye.com/blog/threat…
- Github.com/bang590/JSP…