> Mintegral SDK uses a technique called method swizzling to replace implementations of the UIApplication openURL and SKStoreProductViewController loadProductWithParameters methods at runtime, as well it registers a custom NSURLProtocol class.
That's really clever. It looks like it uses ObjC dynamic linking to swap out calls[0].
When I read stuff like this, I'm glad that I'm a "dependency curmudgeon."
I'm not sure I would have figured this out, if I had vetted the dependency (Actually, I'm pretty sure I would have missed it).
I'm wondering if Apple would be able to detect this behavior, in their review process. There are certainly legitimate uses for it, but I like to avoid these types of hacks, in my shipping apps.
Method swizzling has been well known and used for as long as Objective C has been around. It's essentially Objective C's flavor of what other dynamic languages call monkey patching. I'm surprised that the App store review process didn't catch this, especially if the SDK was used by 1200 apps on the app store.
It reminds of something I'd done to get past the App store review a long time ago. This was when the iPad had just come out and UISplitViewController was super buggy. I found that the only way to get the universal app I was building to work satisfactorily on both the iPad and the iPhone was to use one of their undocumented methods. We submitted the app for review and as I'd half expected, it was rejected for using an undocumented API. The work around was to rot-13 the selector for the undocumented method and to decode it at runtime, dynamically call the method with performSelector. That made it pass the review. And that's when I learnt that the reviewers were probably just running strings (the unix program) and grep to find apps using undocumented APIs. That was a long time ago, I hope things have gotten better by now. :)
If we all agreed that free apps (and services) come at a real cost either in data or subversive practices. Then started paying money for apps that provide value. Do we think this sort of stuff would stop?
There's no reason why free (as in either libre or beer) software has to incur privacy or subversive-practice costs -- see Linux or PostgreSQL, for example.
The issue is that the ad network economy, as currently structured, allows inflicting these costs against consumers -- who couldn't possibly keep track of them all even when technologically well-educated because there are so many apps, SDKs, advertisers and publishers -- while incentivizing application authors to take part with the assumption that they are safe in the crowd.
Rather than pay $5 for an app and hope that it won't misbehave now and/or in future, it generally seems preferable to use a competing free and open source application backed by a community that can inspect and modify it to add features and fix any discovered problems. When such software doesn't exist, it can be developed given enough demand and interest.
No, of course not. The best example is the hugely expensive big TV screen that still comes with all of this, and there isn't even any particular service it offers.
Malicious code benefits from nobody being able to see your code whether it's paid or free. If your app, build process, etc is publicly visible on Github/GitLab/BitBucket/etc malicious code can't hide.
This is very typical of mobile adware/malware to avoid triggering detection by the Apple App Store or Google play store.
Sometimes when looking for signs of malware the easiest thing to observe is either it’s use of Persistance or its checks for root/jailbreak rather than the malicious code itself.
I know there are many legitimate reasons for an app to obfuscate its code or to check if the device is rooted or running through a MITM proxy (such as banking apps for example) but I would think that if an app were submitted with these checks it should get flagged for further review at least.
> I know there are many legitimate reasons for an app to obfuscate its code or to check if the device is rooted or running through a MITM proxy (such as banking apps for example)
There's an argument to be made that even those aren't legitimate, since you can do online banking from a desktop computer where you have root. I'd be in favor of app stores banning root checks from apps that don't need root.
If a heavily sandboxed, walled-garden App Store is still vulnerable on its smaller attack surface, then the open-for-all alternative will be absolutely plagued.
> Mintegral SDK uses a technique called method swizzling to replace implementations of the UIApplication openURL and SKStoreProductViewController loadProductWithParameters methods at runtime
Naive swizzling of system API's will be detected/stopped by App Review, right? Or perhaps only if it's private methods?
I've been looking but haven't found a good systematic way to review code to find this. In the case of Mintegral, there were a number of obfuscations to make it difficult to recognize. Swizzling, while a bad practice in general, can be done for legitimate reasons. So you need to be able to detect what method they're looking up with _method_getImplementation and changing with _method_setImplementation which is the part that can be difficult. So far, I've found one old project in GitHub from 2016 that was designed to do this. However it's stale and I haven't had a chance to review it yet to see how effective it is.
Depends, as the article states the swizzling is only activated unless there is debuggers,etc or the app being in the "wrong" region.
Not entirely sure how Apple's review-process works but if a majority of it is done in Mountain View there's a large chance that most reviewer devices aren't well spread out w/r/t to setting them to other regions.
I feel like it’s been accepted wisdom for a long time that native apps are more secure than the web. In the last few months I’ve found myself wondering if that’s actually true. They both have their own, different security problems.
The challenge here is with SDKs, just like with other open source libraries and packages, once you introduce someone else's code into your app, it becomes infinitely harder to get visibility into what your app is doing and ensure that third-party code isn't doing something nefarious (or including a sub-dependency that does something nefarious).
In this case the SDK was ripping off the developer, by attributing watched ads to its own network by pinging the ad provider after it detected a ping from a different ad SDK in the running app.
For the end user they were still watching ads just the same
ChrisMarshallNY|5 years ago
That's really clever. It looks like it uses ObjC dynamic linking to swap out calls[0].
When I read stuff like this, I'm glad that I'm a "dependency curmudgeon."
I'm not sure I would have figured this out, if I had vetted the dependency (Actually, I'm pretty sure I would have missed it).
I'm wondering if Apple would be able to detect this behavior, in their review process. There are certainly legitimate uses for it, but I like to avoid these types of hacks, in my shipping apps.
[0] https://nshipster.com/method-swizzling/
woadwarrior01|5 years ago
It reminds of something I'd done to get past the App store review a long time ago. This was when the iPad had just come out and UISplitViewController was super buggy. I found that the only way to get the universal app I was building to work satisfactorily on both the iPad and the iPhone was to use one of their undocumented methods. We submitted the app for review and as I'd half expected, it was rejected for using an undocumented API. The work around was to rot-13 the selector for the undocumented method and to decode it at runtime, dynamically call the method with performSelector. That made it pass the review. And that's when I learnt that the reviewers were probably just running strings (the unix program) and grep to find apps using undocumented APIs. That was a long time ago, I hope things have gotten better by now. :)
social_quotient|5 years ago
jka|5 years ago
The issue is that the ad network economy, as currently structured, allows inflicting these costs against consumers -- who couldn't possibly keep track of them all even when technologically well-educated because there are so many apps, SDKs, advertisers and publishers -- while incentivizing application authors to take part with the assumption that they are safe in the crowd.
Rather than pay $5 for an app and hope that it won't misbehave now and/or in future, it generally seems preferable to use a competing free and open source application backed by a community that can inspect and modify it to add features and fix any discovered problems. When such software doesn't exist, it can be developed given enough demand and interest.
stefan_|5 years ago
indymike|5 years ago
benologist|5 years ago
lancesells|5 years ago
sloshnmosh|5 years ago
Sometimes when looking for signs of malware the easiest thing to observe is either it’s use of Persistance or its checks for root/jailbreak rather than the malicious code itself.
I know there are many legitimate reasons for an app to obfuscate its code or to check if the device is rooted or running through a MITM proxy (such as banking apps for example) but I would think that if an app were submitted with these checks it should get flagged for further review at least.
josephcsible|5 years ago
There's an argument to be made that even those aren't legitimate, since you can do online banking from a desktop computer where you have root. I'd be in favor of app stores banning root checks from apps that don't need root.
swiley|5 years ago
breakfastduck|5 years ago
If a heavily sandboxed, walled-garden App Store is still vulnerable on its smaller attack surface, then the open-for-all alternative will be absolutely plagued.
What is the point you're trying to make?
filleokus|5 years ago
Naive swizzling of system API's will be detected/stopped by App Review, right? Or perhaps only if it's private methods?
alyssam_infosec|5 years ago
whizzter|5 years ago
Not entirely sure how Apple's review-process works but if a majority of it is done in Mountain View there's a large chance that most reviewer devices aren't well spread out w/r/t to setting them to other regions.
untog|5 years ago
alyssam_infosec|5 years ago
syspec|5 years ago
For the end user they were still watching ads just the same