AdguardForAndroid
AdguardForAndroid copied to clipboard
AdguardTeam
More pre-installed System malware discovered
A large list @ http://blog.checkpoint.com/2017/03/10/preinstalled-malware-targeting-mobile-users/ . Could all of these be blocked like #908? Should there be new list specifically for malware system apps/packages?
Instead of blocking app traffic, we'd better find out what URLs did they use. Is there any info about it?
Instead of blocking app traffic, we'd better find out what URLs did they use.
As in #908, I think it'd be prudent to block both, so that existing apps can't update to change URLs!
Is there any info about it?
I've found no better details than that post, but there's mention of Tor (!) being used by some of the malware, so just a URL approach is unlikely to work, anyhow. Though Check Point is a security firm (& therefore might consider AG a competitor), it might be worth leaving the question as a comment on the post, or even directly contacting them.
We'd better check how many people have already upgraded to v2.8, as this rule will be quite problematic for v2.7 users.
Slightly more relevant info @ https://news.drweb.com/show/?i=9822 , mostly to do w/ the Loki variants:
-
using a special link that indicates a user account of some affiliate program focused on generating income
-
installs different applications on the infected device and displays advertisements
-
acts as a spyware program as it collects and sends information
A lot of this might be helped by the AG firewall denying all network access to these apps.
We'd better check how many people have already upgraded to v2.8, as this rule will be quite problematic for v2.7 users.
@ameshkov Is it yet time to implement this?
This is actually so bad, A LOT of people are still using the old versions.
It seems that the only viable solution would be to simply disable the old API so that they stopped receiving filters updates.
Honestly, how long do y'all plan to support frankly obsolete versions (especially whenever #1819 lands)? It hobbles the rest of us who religiously update for greater/better/'securer' features. If y'all do wish to continue such support, please reconsider serving separate filter updates for different versions of AG.
Serving different filters might be a solution. I don't really understand what prevents users from updating the app. Maybe we're doing something wrong? What if instead of the current simple notification we show an annoying permanent notification (just like Android does with system updates?).
Or something like a countdown: This app WILL NOT WORK IN 26 DAYS, 12 HOURS, 5 MIN, 6 SECONDS UNLESS YOU UPDATE (FREE!) FROM HERE: link.
Maybe they're pirated/cracked subscription versions or something, in which case it'd be good to cut them off. 🤷
@ameshkov simple: pirated version... and they just lazy to get the updated pirated version....
one more solution: do license check, if the license is invalid then block the filter update....
if one license is used by multiple device (pirated ver usually embed this license + device ID in the apk), then block it altogether....
or just move forward, ignore those users, they'll know if theirs not gonna work anymore themselves if they update the filter....
Another idea is that they're not actually AG instances, but other apps/extensions using the old filterlist server links, since they are generally licensed under Creative Commons Attribution-ShareAlike 3.0 Unported.
if one license is used by multiple device (pirated ver usually embed this license + device ID in the apk), then block it altogether....
@Crescendo-BLYAT That's a problem w/ those of us on multiple/site licenses (like those of us w/ the now-defunct Amazon version), but I suppose some heuristics, like too many devices over too wide IP geolocations, would solve that. The bigger issue would be those that're outright cracked to have no license check, but simply disabling the obsolete update servers would solve that.
or, this one's better: implement apk hash signature check against server (block filter update if hash mismatch) & block odex (auto delete it as it's usually used in Lucky Patcher, please do research about Lucky Patcher)...
Defim's app are almost immune to it...
Don't block LP altogether, its pretty usefull for auto move app + disabling ads receiver in app, I use it for that purposes.... :wink:
@TPS the answer is in your sentence: the outright cracked got NO license check.
Just put the apk hash + license + Android ID (this one is specific for each gadget) in the update request.
If no license is passed, then just refuse update.
Example: If there's 2 or more Android ID are using same license then it's pirated apk or if there's 2 same Android ID requesting update then it's pirated (since there's no way 2 device using same ID unless its embedded in the apk).
Experiment with App Cloner app for this matter.
Also link the license to the purchase receipt & registered email.
Employ several license guard methods.
The apk hash is used if AG really implement forced silent update. So if the apk is too old, then at certain point just refuse update since the pirated version can't be updated unless manually installed.
@ameshkov Now that #908 is resolved, could the package names here be blocked, also? 🙏🏾
@Alex-302 https://github.com/AdguardTeam/AdguardForAndroid/issues/1104#issue-214119788 → http://blog.checkpoint.com/2017/03/10/preinstalled-malware-targeting-mobile-users/
Unfortunately, that's how long the blocking issue has been open, & has just been resolved ~1 week ago. Per https://success.trendmicro.com/solution/1117830-loki-malware-information & https://www.thethreatreport.com/lokibot-the-android-malware-problem-since-2016/, this is still an active, evolving problem.
Tbh, I'd still prefer blocking domains and not apps, this would help in the case if some package names are missing from that list.
As I mentioned, if the packages aren't blocked, all they hafta do is switch domains (as designed for similar reasons), & they're back in business.