focused on Custom URI Schemes and Webview Exploitation Performed Code Review on Popular Applications (100+) Found interesting Scenarios and Misconfigurations
Kotlin • Real-World Vulnerabilities • Based on my research on URI Scheme and WebView Exploitation • Replicates Vulnerabilities disclosed by Well-Known Mobile Researchers
Webview. Theft of Auth tokens: May result in account takeover if authentication tokens are passed to websites that are opened in webview. Phishing: Possible If you can load any arbitrary URL in Webview. Load Local files in webview: Possible if setAllowFileAccess(true) is set in Webview. DOS: Possible if a malformed deeplink can be used to crash the application.
parsers. These parsers don't recognize backslashes in authority part Payload: http://attacker.com\\\\@legitimate.com/smth • CVE-2017-13274 - Fixed for API level 28 and above
to validate Redirect URI parameter, thus allowing attackers to steal access tokens. A lack of scheme validation may also lead to leak of access tokens. Redirect URLs are a critical part of the OAuth flow. After a user successfully authorizes an application, the authorization server will redirect the user back to the application with either an authorization code or access token in the URL.
If you can load any arbitrary URL in Webview • If setJavaScriptEnabled(true) is set in Webview [Disabled by default] • If setAllowFileAccess(true) is set in Webview [Enabled by default]
If you can load any arbitrary URL in Webview • If target app can read data from External storage <uses-permission android:name="android.permission.READ_EXTERNAL_STORAGE"/> • If setAllowUniversalAccessFromFileURLs(true) is set in Webview [Disabled by default]
was found that more than 80% of apps contain this vulnerability. DEVELOPERS often create proxy components (activities, broadcast receivers and services) that take an embedded Intent and pass it to dangerous methods like startActivity(...), sendBroadcast(...), etc.
name of the component to be invoked by activity and we use explicit intents to start a component in our own app. Does not specify any name of the component to start. Instead, it declares an action to perform and allows a component from other apps to handle it. INTENT
receivers won’t work when registered in the AndroidManifest.xml. • To use Implicit Receivers in your application, you need to define them programmatically in your code, using registerReceiver().
this in a real scenario? • How are you going to issue an attacker provided certificate to the Android user and capture the traffic originating from their device?
and host validation check or either they don’t implement that correctly. Loading arbitrary URL in webview may give you authentication tokens. Also, try to exfiltrate data from local sandbox to the remote domain (depending on the webview properties enabled). Note, Google has fixed the Symlink attack as part of the system webview update. So symlink attack won’t work on latest android devices or devices with the updated system webview. IPC components can introduce many vulnerabilities if not properly configured
often pass sensitive data via Implicit intents which can be intercepted by other apps on the device MITM vulnerabilities are too common in android apps. Developers often override SSL error which makes app vulnerable to MITM attack (eg. Unsafe implementation of onReceivedSslError ). Hardcoding API keys and secrets in mobile app is common. You must understand the purpose of hardcoding these keys, check the API docs and see if the keys are supposed to be public or private