> (apkmirror) We're especially concerned about security, given how dangerous downloading apps from third-party sources can be, so we go out of our way to manually review and vet every APK that hits the site.
Kudos. I wonder why PlayProtect didn't catch this? On one hand project-zero does stupendously well and on the other a project like PlayProtect fails at checks that an untrusted third-party routinely does. It can't be incompetence? It can't be blind reliance on AI?
Android has a 2B install base, and security will quickly turn into an unprecedented nightmare as more and more people get exposed to scamware, spyware, scareware, malware for the first time. This is not even factoring privacy encroaching viral apps like Helo, ShareChat et al that have in some cases 100M+ installs.
GPZ has some of the very best whitehats in the entire world and they are evaluated based on what they find, not what they fail to find. They have the time to review code in depth. They are also usually investigating vulnerable code rather than malicious code, which doesn't seek to hide from investigation.
PlayProtect needs to be able to evaluate every app in existence (millions of apps on the Play store, ??? off the play store, and dozens or hundreds of versions of each of these apps). Malware authors are incentivized to perform all manner of tricks to avoid detection (code obfuscation to prevent static analysis, environment detection to prevent dynamic analysis, etc). It needs to do so in a (presumably) fully automated fashion since there are so many apps. It also gets little credit for when it works and instead only makes the news when it fails.
So 100% of the coverage of GPZ is positive and 100% of the coverage of PlayProtect is negative.
I get your point but my intention was not to highlight the different areas of security GPZ and PlayProtect tackle, but the gulf in class in competence and level of execution between those groups (if I may say so from the armchair I'm sitting on).
That said, the last bit abt a 100% coverage rings true. The signature check; however, seems like one of the important things to do (of course, there are lot of edge cases to be taken care of)? It can't be any more expensive than the AI they run on millions of apps.
"It isn't that hard" isn't always a good reason to implement something. I don't know the details, but it could be entirely reasonable that at every prioritization step people have decided that something else was higher impact.
Add to this the fact that signing keys are often shared in weird ways (usually with OEMs) and maybe it doesn't make too much sense to use "this is signed weirdly" as sufficient evidence to remove from Play.
I expect that they do so for the high profile apps, since the negative press from a compromised Facebook/Snapchat download would probably kill the site outright.
but they discovered random 3rd party apps signing with the facebook key. apps with a package name like com.testmusicapp
so to detect this manually, they'd have to be checking every single app! more likely, they've an automated system that detects new APKs signed with prominent keys.
Yeah, that's what I would expect - global automated testing, and specific manual testing.
Although it's very possible that the thing you mentioned is a fluke and somebody decided to ask the question "We should probably keep all the Facebook apps definitely-safe, so which ones are signed with this key?"
Does anyone have a recommendation for what best practice for Android app signing key maintenance is (or maybe multiple people strongly suggesting entirely opposite ideas ;P), under an assumption that one absolutely intends to be distributing their app via numerous sources (not just the Play Store)? Our app (which hasn't launched yet) is security critical for the user (it is a VPN client, and so can see all of the user's traffic, as well as a cryptocurrency application, and so has access to some amount--not likely a large amount for various reasons: this isn't really a wallet--of money), and so with the appeal of "immediately steal money from users" we expect it/us to be targeted even with lower install counts (so this isn't a pipedream with a reality check of "we are never going to get popular anyway").
We are totally willing to do "weird" things with hardware signing keys in the name of security... it just isn't really clear what the correct thing to do is :(. Should we be using Google Play App Signing for the Play Store, even if we can't do that for other distribution mechanisms? As I kind of remember unrelated stores being able to manage and upgrade apps (particularly free ones) from different stores, as they just get a list of installed apps from the OS, it would seem problematic to use a _lot_ of different keys (such as one per store)? I will again note that, due to our constraint of being pretty sure we will have off-App Store distribution (some of our key markets don't use the Play Store much), we need to solve the key security problem for non-Play Store distribution "anyway", and so can't just fall back on "don't do local signing".
Meanwhile, I didn't even know yet about the Android 9 key rotation feature mentioned in this article, which I could see maybe having major changes on best practices here, though maybe only "going forward" (given how few users have upgraded to Android 9 so far, and now that I think about it probably won't for years to come...). In a world where you can effectively never change your key, it seems really important to have your act together on "day 1" to get stuff right (though I also am not even sure what is reasonably possible, given how I think it all fundamentally relies on a single key? so we can't do some kind of multi-sig? I also don't know if we can do sub-certificates with short signing duration with a root certificate backed by a vaulted key, as people often do for SSL?)
Whatever you do, if you are high value then you should consider the risk that your source repository could be compromised too. Using separate hardware signing keys for git/whatever is something you should therefore also strongly consider I think.
Reproducible builds can also help you to mitigate this risk - so you then can cross check that the source is properly signed and produces the right binary before signing the binary. If you are publishing source code then your customers can also double check this as a second vector, should they want to.
If you have to do local signing at some point, then an offline HSM protected by a quorum of unlock keys would be one way to make sure your key won't end up somewhere you didn't intend and is resistant to single internal compromised employees. Crack open the safe, take out the HSM, turn it on, sign the build, and then put the HSM back into its safe. If you want to go the extra mile, some of the HSM's have ways to generate the same key onto two HSM's, and you can put the second one in a bank vault for backup.
There is also the possibility these other apps sharing the same key are secretly owned by Facebook and are another arm of their covert data harvesting tactics.
Kudos. I wonder why PlayProtect didn't catch this? On one hand project-zero does stupendously well and on the other a project like PlayProtect fails at checks that an untrusted third-party routinely does. It can't be incompetence? It can't be blind reliance on AI?
Android has a 2B install base, and security will quickly turn into an unprecedented nightmare as more and more people get exposed to scamware, spyware, scareware, malware for the first time. This is not even factoring privacy encroaching viral apps like Helo, ShareChat et al that have in some cases 100M+ installs.