
SourMint Malicious SDK - sjmaplesec
https://snyk.io/research/sour-mint-malicious-sdk/
======
ChrisMarshallNY
_> 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.

[0] [https://nshipster.com/method-swizzling/](https://nshipster.com/method-
swizzling/)

~~~
woadwarrior01
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. :)

~~~
xoa
> _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.

~~~
toyg
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...?

~~~
xoa
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.

~~~
toyg
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.

------
social_quotient
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?

~~~
stefan_
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.

~~~
lapcatsoftware
Are these "smart" TVs compliant with the GDPR, and if so, how?

~~~
toyg
The same way polluting industries just dump their shit around: nobody sues
them until it's incredibly egregious.

------
sloshnmosh
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.

~~~
josephcsible
> 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.

------
swiley
So glad the App Store prevents malware.

~~~
breakfastduck
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?

~~~
lapcatsoftware
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.

~~~
mschuster91
> 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?

~~~
lapcatsoftware
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?

------
filleokus
> 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?

~~~
alyssam_infosec
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.

------
untog
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.

~~~
alyssam_infosec
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).

~~~
untog
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.

