SourMint Malicious SDK
snyk.io
snyk.io
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.
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. :)
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.
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.
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.
I mean, there's a lot I don't understand about macOS but that's somehow less fun
The billion dollar question is: how do you monetize non-paying users, at scale, without ads?
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.)
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.
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!
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.
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.
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.
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.
What is the point you're trying to make?
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.
Microtransactions were a thing even before the App Store race - remember Farmville, MafiaWars and the other host of Zynga's Facebook games?
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?
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.
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.
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
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.
Naive swizzling of system API's will be detected/stopped by App Review, right? Or perhaps only if it's private methods?
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.
For the end user they were still watching ads just the same