Fortnite Android Installer allowed hackers to download and install anything
androidcentral.com
androidcentral.com
"Any app with the WRITE_EXTERNAL_STORAGE permission can substitute the APK immediately after the download is completed and the fingerprint is verified. This is easily done using a FileObserver. The Fortnite Installer will proceed to install the substituted (fake) APK.
If the fake APK has a targetSdkVersion of 22 or lower, it will be granted all permissions it requests at install-time. This vulnerability allows an app on the device to hijack the Fortnite Installer to instead install a fake APK with any permissions that would normally require user disclosure. "
CheckPoint's diagram of a Man in the Disk attack is also helpful: https://blog.checkpoint.com/wp-content/uploads/2018/08/Man-i...
Instead, through Google Play Services deals with manufacturers, they prevent this from happening at the system level, don't they, other than for phone vendor stores?
You can only blanket allow third party apps, which you have to toggle on and off every time you do a third party update, and not just add a specific store's key. At least that's how Amazon Instant Video seems to be.
Why the downvotes? It is true.
The system offers it and they didn't use it.
"Why should something like the Fortnite installer have to make any effort to ensure that other apps aren't tampering with what it downloads?"
Because it's running with exceptionally dangerous permissions that Google does its level best to prevent users from granting to 3rd party apps in the first place.
The bug report doesn't seem to be clear on whether the Fortnite installer is downloading the game to a public external storage directory or a private external storage directory. But the existence of the latter API means you can't just say "they should have used internal storage". If the Fortnite installer used the getExternalStoragePublicDirectory() API, then this is a really embarrasing bug for Epic. Otherwise, it's an Android problem, not an Epic problem.
That doesn't answer the key question. There are APIs to get public or private directories on external storage. Unless Epic used the public version, then they had no reason to expect other apps to be able to tamper with their working files. You have to dig into the fine print of the API docs to find a clear statement that private directories on external storage don't have any security, which is a surprising difference from how the internal storage works. Google calls the directories private, but they're really not. There's no obvious reason why they couldn't be secured against modification by non-root apps.
The different APIs for accessing external storage are mainly just there for filesystem tidyness and are documented as such. getExternalStoragePublicDirectory puts media files in locations where other apps and the user can find them easily, whereas the application-specific directory is deleted when the app is uninstalled. There's no real security difference and the documentation makes this quite clear. I think the API for application-specific directories in external storage was probably only added because applications were already using it for their internal files in ad-hoc ways that caused a lot of user visible clutter.
Only once you've dug deep enough. The page you linked to doesn't mention security at all. It does say: "Except for some types of files on external storage, all these options are intended for app-private data—the data is not naturally accessible to other apps." Elsewhere, it mentions that files on external storage are world-readable, but that's not a problem here. The fact that they're also world-writable is left unsaid.
Going another layer deeper into the docs at https://developer.android.com/training/data-storage/files we get this: "Private files: Files that rightfully belong to your app and will be deleted when the user uninstalls your app. Although these files are technically accessible by the user and other apps because they are on the external storage, they don't provide value to the user outside of your app." That doesn't clearly warn that "private" files on external storage will be modifiable by other apps while you're still trying to use them.
Only by going all the way down to the documentation for getExternalFilesDirs() itself do you get a reasonably sufficient and clear warning: "There is no security enforced with these files. For example, any application holding Manifest.permission.WRITE_EXTERNAL_STORAGE can write to these files."
For someone coming to Android programming with the knowledge that it's Linux-based with a fairly strict permissions model, and with so many mentions of "private" storage in the high-level docs, it's a surprise to discover that there are no file permissions enforced on "external" storage.
I don't think this was even hidden or obfuscated, doc-wise (exhibit A: doc exists), but even if it was the onus is on Fortnite.
"For someone coming to Android programming with the knowledge that it's Linux-based with a fairly strict permissions model, and with so many mentions of "private" storage in the high-level docs, it's a surprise to discover that there are no file permissions enforced on "external" storage."
If you are not an absolute expert on Android across multiple devices and api versions, then you have no damn business releasing something of this nature.
You bring up Linux. It is not a flaw that drivers run in a privileged mode. If you make a device driver and don't understand how memory is allocated and cleared or not cleared, then you have no business writing one because you're going to let people root your customer's boxes eventually.
The public filesystem is, by design, sharable between apps. This is so you can have stuff like a music playing app or a picture viewing app that interacts with files created by other apps.
Do you have a source for that? Because that detail is definitely not in the Google bug tracker. I'm still not sure you've actually understood that there's a difference between getExternalStoragePublicDirectory() and getExternalFilesDirs().
I don't know how up to date that is, but it says once unknown sources are turned back off, the app using REQUEST_INSTALL_PACKAGES can no longer install unsigned packages. My point was it should be possible to add a key for a store, so that unknown sources doesn't have to be turned back on after installing it.
But then this seems to say you can:
https://developer.android.com/reference/android/content/Inte...
Meanwhile, they have accused Google's disclosure, which is completely in line with their existing disclosure behavior that they stubbornly enforce for everybody, as being a PR move, intended to harm Epic Games for their decision to launch outside Play Store. It's clear that Android has a bad reputation for security issues and insane to think that Google would not want to make sure that the launch of a super popular video game on their platform doesn't turn into a security disaster.
I generally respect Epic Games, but I don't understand what seems to be pretty greedy on their part. If they wanted to start a discussion about the fairness of app store taxes, I don't think this will accomplish that personally.
Meanwhile, Apple's definitely looking pretty smart. They're probably making good money off of Fortnite and won't suffer any of the bad UX or security issues Android users will be exposed to.
That new malicious app then gets to somehow have more permissions than the original malicious app or the installer.
Guys, that's an Android bug. This is exactly the kind of thing that needs to be fixed at an OS level, you can't be relying on the competence of arbitrary developers to maintain the security of the system.
Of course it's an opportunity for Google to use their own broken security model as an argument on why apps should only come from their own "curated" channels (which presumably also host the malware exploiting this). It just so happens to be their source of revenue...
There are two ways to fix this. One is to not permit dynamic code loading or app installs off the Play Store. This is Apple territory and pisses people the hell off. The other is to not have any world writable filesystem at all. I guess you could do this, but this messes with features surrounding music and pictures that you do want to share between apps.
Epic literally could have used the private filesystem that is right there just for the purpose of having files that are protected from other apps.
It should not be possible for an application that happens to install other applications to bypass the user for specific permissions. The user must be asked explicitly.
This has nothing to do with being able to "sideload" apps or not. Sideloading apps is actually possible on iOS, it's just such an effort (getting a developer account) that it's rarely done in practice.
According to Google issue tracker: "This patch changes the default APK storage directory from external to internal storage, which should prevent MITD attacks during the install flow."
As indicated in the article this vulnerability has as much to do about ... the way Android's permissions model works...
> Google's security analysis efforts are appreciated and benefit the Android platform, however a company as powerful as Google should practice more responsible disclosure timing than this, and not endanger users in the course of its counter-PR efforts against Epic's distribution of Fortnite outside of Google Play.
And Google expects researchers to disclose bugs on their platform to them before disclosing to public.
type: vulnerability is new, but if you search the public bug tracker for the phrase "This bug is subject to a 90-day disclosure deadline", you can see it all
It looks like they have been pretty darn consistent about unrestricting once the patch is available. Usually faster than 7 days! They have also consistently held people to the 90 day requirement, and the 14 day grace extension they offer This is true even when the reporter is a googler or it affects only google software.
This literally took me 5 minutes to look at and analyze.
Instead of bothering to even look, epic decided it'd be better to issue a press release (as part of their pr efforts, ironically enough).
If they want to complain (like others have!) and debate what the policy should be, that is one thing.
However, the complaint that Google has treated them differently is clearly false.
If they want to argue otherwise, the data is all right there for them to use.
From the article linked above:
> Avoiding the 30 percent "store tax" is a part of Epic's motivation. It's a high cost in a world where game developers' 70 percent must cover all the cost of developing, operating, and supporting their games. And it's disproportionate to the cost of the services these stores perform, such as payment processing, download bandwidth, and customer service. We're intimately familiar with these costs from our experience operating Fortnite as a direct-to-customer service on PC and Mac.
> Google's security team first disclosed the vulnerability privately to Epic Games on August 15, and has since released the information publicly following confirmation from Epic that the vulnerability was patched
This isn’t a bug “in android” since it can only happen when the user enables permissions to install third party app stores - the Fortnite installer is essentially an App Store that could be tricked to installing any APK rather than the one it means to.
The "bug" is that it is extremely difficult for users to install 3rd party apps securely.
If it was easier for developers to securely offer 3rd party downloads, then stuff like this wouldn't happen.
There is a huge difference between no one has vetted this program and someone other than the device manufacturer has vetted this program. In a contest of "trustworthy not to contain malware" the Debian package manager beats Google Play, and you don't need approval from Dell or Microsoft to use it.
So i would argue this is not as simple as that.
I dont necessarily trust fortnite keeping their keys secure, for example.
Example here: https://f-droid.monerujo.io/
The only difficult part is the user getting f-droid on their device to begin with. If google play implemented the functionality provided by F-droid, they wouldn't need to.
Manufacturers should just put F-droid on new devices as standard.
The only people who would advocate this are Google since they gain financially from the model and those who use 'security' to promote walled gardens and moats.
Most technical people don't approve of lockdowns and loss of freedom. There is a balance here. If installing apps from the web is a problem then 90 percent of current software is 'insecure'.
Those decades were largely spent with a physical retail distribution chain taking an even bigger share of most consumer purchases, and being just as essential to reaching most consumers.
There wasn't much gap between online distribution becoming significant and app stores emerging.
That seems a little bit insane, combined with Androids kind of terrible inability to do useful things like have a place for large storage (SD card), that isn't readible and mutable by all apps.
Seems like a non issue to me, and one easily prevented if side loading wasn't an after thought.
What’s surprising about this story is tha what’s surprising about this story isnt that people are ending up with security issues, it’s that they’re ending up with security issues from the OFFICIAL download.
(The quora one is spam that leads to adware apk site on .in domain)