Bypassing ContentProvider.openFile() internal security checks in Android
[1/3]
I've discovered an interesting trick that you may use to access private information using a content provider
[2/3]
The attack is possible if: 1. The content provider is exported 2. Internally, it checks the calling UID, package name, and/or permission set as shown on the screenshots
[3/3]
It's possible to call ContentProvider.openFile() via IActivityManager.openContentUri(). It will check access rights, but then proxy the call from its context leading to Binder.getCallingUid() == 1000, and all permissions granted
• • •
Missing some Tweet in this thread? You can try to
force a refresh
#bugbountytips
An almost universal way to theft or overwrite arbitrary files on #android is sharing activities. You can find them in AndroidManifest.xml. They handle android.intent.action.SEND. Use the PoC from blog.oversecured.com/Evernote-Unive… (ctrl+f "EXTRA_STREAM") and test 4 scenarios:
1. Send a Uri to an internal file using file:// scheme (direct or using a symlink) 2. Send a Uri to an internal file using a victim app's internal content provider
now grep private file contents on SD card
3. Send a Uri to your own file like explained in the article above (test _display_name and last path segment values to be vulnerable to path-traversal)
now run "ls -la dir | grep file_name" on /sdcard and /data/data/app
You must love #Android deeplinks! They are the easiest way to get bounties 1. Decompile an app with jadx 2. Collect all deeplink handlers from AndroidManifest.xml, they look like <data android:scheme="airbnb" android:host="d"/>
3. Grep among all sources and resources a pattern from a handler, in this case, airbnb://d 4. You could find a lot of hardcoded urls like airbnb://d/openurl?url=https:// airbnb.com/blabla. That's much simpler than learning app's sources
5. Now try to put your own domains with adb (adb shell am start -a android.intent.action.VIEW -d airbnb://d/openurl?url=http:// evil.com) or on HTML pages (check out the H1 report below)