SourMint Malicious SDK
snyk.io> 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. :)
>That was a long time ago, I hope things have gotten better by now. :)
Reviewer techniques of course improve somewhat and evolve over time, but in terms of basic heavy reliance on automation and the like it's doubtful much has changed. But that's ok, because the battle is about economics and layers not perfection. The final layer is what HN has been so up in arms about: eventual detection after the fact, at which point Apple bans the devs and in extreme instances can revoke certs/delete the malware in question (all while its harm is limited by sandboxing/trust chains/etc). The $100/yr wall layer stops some automated attacking and makes anonymity more difficult, the signing requirements make it harder to avoid specific attribution, the restrictive permissions model and such stop some attacks, the review process maybe catches a few more and certain softer attacks, all of which combined hopefully reduces the final volume of what gets through and the value of what can be achieved with it vs consequences to a level where post-hoc response (the most expensive kind) can keep up. And the single market means the process is hard to avoid entirely, and the interests of users can collectively push back on the power of developers.
So no silver bullets, each layer has a part to play. That's kind of expected though isn't it? It's the typical trade off scalability vs specificity.
1200 "compromised" apps in appstore for more than 6 months (I can't find when 5.5.1 of the sdk was released, it was before 3 March), and you really want to spin this as a "success" of the enlightened-dictator model...?
It's astonishing in this day and age to see people like you who still think it statistically appropriate to toss out absolute numbers for comparative systems. As I wrote the expectation is not perfection but improving the economic balance, since all general security is an economic game. That 1200 number is utterly meaningless by itself, the comparison is what the numbers would be, what the compromise can accomplish on the system, and for how long, without any of these measures in place. A major goal of iOS is to allow the general population to go browse around and install absolutely anything they like the look of with minimal concern for what it might do. And it's a good goal, sacrilegious as it's proved to be amongst techies, even if unfortunately (though unsurprisingly) Apple has brought along unnecessary baggage with it. We should and could have done better first and preempted it, but collectively could not be bothered (or even outright mocked victims).
I'm not going to bother with rhetorical questions about the state of such things on Windows, macOS, Linux or whatever because we all damn well know the answer.
Ah yes, "think of the children", that marvel of rhetorical tools. You deny others their freedom, but it's "for the greater good". That always ends up so well.
The "state of such things" on other platforms, as dangerous as it might look to your paternalistic worldview, is what enabled the PC revolution in the first place. Had Microsoft or IBM enacted policies as draconian and illiberal as Apple is doing now, we likely wouldn't be talking on a free tcp connection using free browsers, right now. It's not by denying people their freedom that you reach progress and stability, but by educating them to make better choices for themselves.
But sure, spin it round and round. You and Apple are doing your best to keep back progress, but it's not going to last.
It is a bit surprising but at the same time Mintegral did go through a number of steps to obfuscate the code to make it harder to see that it was impacting standard iOS SDK methods.
I didn't know about strings and I've been using Linux for years now. I like that there's lots still to learn.
I mean, there's a lot I don't understand about macOS but that's somehow less fun
Google Firebase SDK swizzle too, so swizzle is allowed, from here it's a cat and mouse game.
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.
Whenever you can make more money by packaging junk, somebody will do that.
Most people always go for the cheapest option no matter how junky it is, and no matter how much an improvement paying a but extra would make (exhibit A: airplane tickets for tourists).
It seems like the only working method to get rid of the junk is to outlaw it.
Are these "smart" TVs compliant with the GDPR, and if so, how?
The same way polluting industries just dump their shit around: nobody sues them until it's incredibly egregious.
Actually, this is a case where the ad SDK is behaving badly. No one signed up for that.
"No one signed up for that."
Obviously nobody wants hackwerware.
The question posed by the OP is systematic: people are willing to 'not pay' for things because the 'short term benefit' is 'less cost' while the longer term risk, ie 'hackerware' is more vaugue.
A lot of things in life are like this.
Back in the day, the fire Dept. were private, they didn't come unless you were paying them insurance.
Given the common nature of 'fire' - and especially that it 'spreads to other homes' ... it makes too much sense for everyone to have it, and so we socialised it. We all pay for fire insurance via our homes.
The argument being, is that if people paid for apps, devs wouldn't have to resort to as much trickery, and there would be less use of malware. Though it's not so clear.
Given the excessive cost of iPhones and the significant rake on apps (~30%), Apple should cover this problem. They mostly do, but obviously not entirely.
I wonder if there should be a 3rd party lib repo where the code has to be open sourced, and 'someone' has to pay for a review of some kind. And you have to stick to such repos if you want a certain kind of certification.
It's an interesting problem in 2020, and looking back, it's almost amazing that in 1999 the web was so amazingly relatively safe, and that there wasn't so much existential angst over security. How naive we were!
Would the Ad SDK have less developer interest (and as a result be a less likely target for this) if ads weren’t as attractive a source of income?
Absolutely! Every minute spent on fine-tuning an ad SDK is a minute not spent on making the app better for paying customers. Most of these SDKs are not just drag and drop, either; developers have to spend a lot of time configuring the attribution schemes and to update them periodically.
There's a huge international market of potential app users that tolerate ads but would never pay to purchase an app. Even in affluent areas, many people balk at a $0.99 app but are totally fine with ads. This, of course, is the entire business model of Facebook, Instagram, etc.
The billion dollar question is: how do you monetize non-paying users, at scale, without ads?
I do think there's a problem where companies add ad network SDKs (or, on the web, ad tags) without considering the privacy or security risks, and instead think only "more ad networks will make us more money".
On the other hand, the two main options to this are (a) people only install SDKs/tags from ad networks with strong reputations or (b) a system like AMP, where ad networks can choose between running in a sandbox (xdomain iframe) and submitting their code as an open source extension for review. Option (a) has the major downside of helping existing players and players with non-ads businesses that strengthen their reputation (like my employer). Option (b) is better, but still hard to do well.
(Disclosure: I work for Google, on ads. Speaking only for myself.)
I think a big problem here is the lack of liability.
If you are making a hardware device, decide to include a dodgy module from AliExpress and then the device starts catching fire and burning your customer's homes you will at least be subject to a lawsuit, so you won't even consider doing this.
This should be the same when it comes to third-party binaries and SDKs. Even if you respect the law (when it comes to privacy, GDPR, consumer rights, etc), you also need to do your due diligence and make sure any third-party code you embed also does respect it otherwise you should be subject to lawsuits.
The result would be that a lot of dodgy ad networks would go away (because no respectable app developer would do business with them), ad networks themselves would be more selective in what kind of ads they run (ad prices will go up to compensate for the cost of vetting them), and overall I think it'll be a win for everyone; customers are not only safer but also see higher quality ads because the "bottom of the barrel" stuff has been pushed out of the market.
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.
I think we should seriously consider and study whether advertising is bad for our health, both as individuals and as a society.
And when it's concluded that it is, we can reclassify it as assault or psychological abuse.
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.
So glad the App Store prevents malware.
It certainly helps.
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?
Counterintuitively, the walled garden may make the problem worse.
The App Store is a single target. It makes "discovery" easier for malware. Imagine if these apps had to get users the "old fashioned" way, one-by-one, word-of-mouth, etc. It also requires less initial setup for malware developers, as opposed to having to develop their own software distribution infrastructure. Every claim about the App Store making things easier for developers also applies to malware.
Moreover, the App Store race to the bottom undermined the previous paid upfront software model in favor of everything being free, supported either by ads or by "cash cow" manipulative IAP.
This is a valid point & well made.
I would argue that the race to the bottom is caused more by Apples gratuitous 30% cut than anything else, though.
Totally agree the free by default model causes more harm than good in the grand scheme of things when it comes to these app stores.
> Moreover, the App Store race to the bottom undermined the previous paid upfront software model in favor of everything being free, supported either by ads or by "cash cow" manipulative IAP.
Microtransactions were a thing even before the App Store race - remember Farmville, MafiaWars and the other host of Zynga's Facebook games?
I didn't say microtransactions weren't a thing. But clearly the App Store vastly expanded these practices.
Pointing to Facebook just proves the point. Facebook is a walled garden, but does anyone think Facebook is a "healthy software ecosystem" for developers and users?
Ancient GSM services were the starting point for those, from daily horroscope subs to java applet games sales... Apple is still eating the "take that out of GSM menus and sms orders and put it on its own dedicated internet app" cake (with same rate of tax of those ancient provider app stores took from 3rd parties).
It isn't open for all? F-Droid, surely one of the most popular 3rd party app stores has vastly stronger requirements than the Play store: https://f-droid.org/en/docs/Inclusion_Policy/
The Play store is such an unimaginable cesspit of crap that I've now stopped using it entirely except for official company apps, and then it will still suggest me malware clones every time.
Like I wanted a battery display for my AirPods and the choice was stuffed with ads, battery draining IAP from the Play store or a simple, free OSS one from F-Droid:
https://github.com/adolfintel/OpenPods
Of course, go figure, this app had to itself be modified to prevent scam artists from loading it up with advertisements and malware and putting it onto Play, where license violations are widespread and go entirely undetected.
I wasn't aiming my 'open-for-all' comment at any particular alternative.
It was more if you've got one walled and protected store and that's compromised, a free open alternative would be more likely suffer the same issues on a larger scale.
Certainly agree with your assessment of the Play Store
No. Because if we didn’t depend on someone getting funded and paying apple yearly we could use community maintained software. Are there any open source SFTP clients for the iPhone? (For example) Using SSH and SFTP via anything other than ish really creeps me out honestly.
Linux doesn’t have an “App Store” instead you have to engage with the community and publish your app source code if you want it easily installed by most users. I guess that’s still not quite a “free for all” (although there’s nothing stopping users from installing whatever they want) but it’s certainly not as strict as what apple does.
> 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).
True, but at least on the web I can inspect what network requests it sends, what the code is (even if it's obfuscated). Native SDKs are just a black hole.
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