CVE-2026-52200

UZ801 / ES-U3TS MifiService Fehlerhafte Zugriffskontrolle

Sicherheitshinweis und technische Notizen zu einem Problem mit fehlerhafter Zugriffskontrolle in der eingebetteten Web-Management-API, die von MifiService.apk auf der OEM-/White-Label-Plattform UZ801_v2.1 für mobile 4G-LTE-Wi-Fi-Geräte bereitgestellt wird, die auch unter dem Namen ES-U3TS vermarktet wird.

Dieses Repository dient der Unterstützung einer koordinierten Offenlegung und der CVE-Zuweisung. Es konzentriert sich auf reproduzierbare, nicht-weaponisierte technische Belege.

Zusammenfassung

Das betroffene Gerät stellt einen Jetty-basierten HTTP-Verwaltungsendpunkt unter folgender Adresse bereit:

http://192.168.100.1/ajax

Der Backend-Anfrage-Dispatcher ist implementiert in:

com.mifiservice.server.AjaxSevlet

Obwohl die Weboberfläche eine Anmeldeseite anzeigt, erzwingt das Backend für die meisten Verwaltungsfunktionen keine gültige, authentifizierte serverseitige Sitzung. Infolgedessen kann ein Angreifer im angrenzenden Netzwerk sensible funcNo-Operationen ohne Authentifizierung direkt aufrufen.

Der verifizierte Einfluss umfasst:

• Auslesen des aktuellen Wi-Fi-Passworts im Klartext
• Auslesen von IMEI, Firmware-Informationen, SIM-Status und Netzwerkkonfiguration
• Auslesen der DHCP- und MAC-Filter-Konfiguration
• Änderung und dauerhafte Speicherung der Verwaltungskonfiguration ohne Authentifizierung
• Auslösen eines Konfigurations-Resets und eines Geräteneustarts ohne Authentifizierung

Zusätzliche Hochrisikofunktionen wurden durch statische Analyse bestätigt, darunter:

• Neustart in den Bootloader
• Aktivierung versteckter ADB-/Qualcomm-Diag-USB-Modi mit anschließendem Neustart
• Undokumentierte IMEI-Überschreibungsfunktion

Umfang und Benennung

Die getestete Hardware scheint zu einer OEM-/White-Label-Gerätefamilie zu gehören. Der genaue ursprüngliche Entwicklungshersteller ist derzeit unbekannt, und es wurde bisher kein zuverlässiger Sicherheitskontakt des Herstellers identifiziert.

Dieser Hinweis verwendet daher die folgende Produktbenennung:

• Plattform: UZ801_v2.1
• Beobachteter Marketing-Alias: ES-U3TS
• Beobachtete Firmware: UZ801-V3.4.3
• Beobachtete App: MifiService.apk
• Beobachtetes Paket: com.mifiservice.hello

Wenn weitere Marken oder Wiederverkäufer gefunden werden, die dieselbe Firmware, APK, Web-Assets und dasselbe funcNo-Verhalten ausliefern, sollten diese als wahrscheinlich betroffene Varianten derselben Codebasis behandelt werden.

Betroffene Komponente

• /ajax Web-API-Endpunkt
• MifiService.apk
• com.mifiservice.server.AjaxSevlet

Grundursache

Hierbei handelt es sich in erster Linie nicht um ein Problem mit Standard-Anmeldedaten.

Die Grundursache ist eine fehlerhafte Zugriffskontrolle in der Backend-API:

• Für die meisten Verwaltungsanfragen wird keine authentifizierte serverseitige Sitzung erzwungen
• Es ist kein CSRF-Schutz vorhanden
• Es ist keine Origin-Validierung vorhanden
• Es ist keine Referer-Validierung vorhanden
• Für die meisten sensiblen Funktionen ist kein Sitzungscookie oder Token erforderlich

Die Anmeldefunktion existiert, bietet jedoch für den Großteil der Verwaltungs-API keine aussagekräftigen Autorisierungsgrenzen.

Bedrohungsmodell

Primärer Angriffsvektor:

• Angreifer im angrenzenden Netzwerk, der mit dem Geräte-Hotspot verbunden ist

Sekundärer Angriffsvektor:

• Browserbasierte CSRF-/Drive-by-Ausnutzung gegen ein Opfer, das derzeit mit dem Geräte-LAN verbunden ist

Dies ist standardmäßig kein aus dem Internet erreichbarer Remote-Angriff. Der Angreifer muss entweder:

• direkte Layer-2-/Layer-3-Erreichbarkeit zu 192.168.100.1 haben, oder
• einen verbundenen Opfer-Browser dazu bringen, Anfragen an den Geräte-Endpunkt zu senden

Status der Belege

Alle unten aufgeführten Ergebnisse sind als betroffene Funktionalität desselben Problems der fehlerhaften Zugriffskontrolle enthalten.
Wo relevant, ist jedes Element ausdrücklich gekennzeichnet als entweder:

• Live validiert
• Durch statische Analyse bestätigt

Diese Unterscheidung wird aus Gründen der Genauigkeit beibehalten. Hochrisikofunktionen werden nicht fälschlich als live getestet bezeichnet, wenn sie absichtlich nicht auf öffentlicher Hardware ausgeführt wurden.

Technische Ergebnisse nach Funktionsgruppe

Nicht authentifizierte Informationsoffenlegung

Nicht authentifizierte Konfigurationsänderung

Nicht authentifizierte störende / administrative Aktionen

Undokumentierte oder wartungsartige Funktionalität

Herstellerstatus

• Ursprünglicher Upstream-Hersteller: unbekannt
• Produkttyp: OEM-/White-Label-Plattform für mobile Router
• Zuverlässiger PSIRT-/Sicherheitskontakt: nicht identifiziert
• Aktueller Offenlegungsstatus: Hersteller nicht erreichbar / kein bestätigter Sicherheitskanal des Herstellers

Zum Zeitpunkt der Erstellung dieses Dokuments scheint das Gerät über OEM-/Wiederverkäuferkanäle mit inkonsistenter oder fehlender Kennzeichnung verkauft zu werden, und es wurde kein vertrauenswürdiger Kontakt zum ursprünglichen Entwicklungshersteller hergestellt.

Sichere PoC-Beispiele

Die folgenden Beispiele sind absichtlich auf schreibgeschützte oder risikoarme Validierung beschränkt. Sie dienen dazu, die Schwachstelle zu demonstrieren, ohne einen weaponisierten Ausbeutungsworkflow bereitzustellen.

1. Aktuelles Wi-Fi-Passwort ohne Authentifizierung lesen

curl -s \
  -H "Content-Type: application/json" \
  -d '{"funcNo":1002}' \
  http://192.168.100.1/ajax

Erwartetes Verhalten:

• gibt JSON zurück
• enthält ssid
• enthält pwd im Klartext

2. Geräteidentifikationsinformationen ohne Authentifizierung lesen

curl -s \
  -H "Content-Type: application/json" \
  -d '{"funcNo":1029}' \
  http://192.168.100.1/ajax

Erwartetes Verhalten:

• gibt JSON zurück
• enthält imei
• enthält fwversion

3. Nicht autorisierten persistenten Schreibzugriff mit einem risikoarmen Feld demonstrieren

Aktuelle Sprache lesen:

curl -s \
  -H "Content-Type: application/json" \
  -d '{"funcNo":1030}' \
  http://192.168.100.1/ajax

Sprache setzen:

curl -s \
  -H "Content-Type: application/json" \
  -d '{"funcNo":1031,"Language":"Chinese"}' \
  http://192.168.100.1/ajax

Den ursprünglichen Wert danach wiederherstellen.

4. Browserbasiertes CSRF-Konzept

Dieser Endpunkt erzwingt keinen Sitzungszustand oder eine Origin-/Referer-Validierung. Ein verbundener Opfer-Browser kann daher missbraucht werden, um Hintergrundanfragen zu senden.

Minimale Demonstrationsseite:

<!doctype html>
<meta charset="utf-8">
<script>
fetch("http://192.168.100.1/ajax", {
  method: "POST",
  headers: {"Content-Type": "application/json"},
  body: JSON.stringify({funcNo: 1002})
});
</script>

Dieses Beispiel ist absichtlich auf eine schreibgeschützte Funktionsnummer beschränkt. Setzen Sie es nicht gegen Benutzer oder Produktionsgeräte ein.

Nicht öffentliche / Hochrisiko-Anfrageformate

Die folgenden JSON-Formate werden nur für defensive Analyse und Triage dokumentiert. Sie werden hier nicht mit Ausführungsschritten versehen.

2001 - versteckte Debug-Schnittstellen aktivieren

{"funcNo":2001}

Beobachtetes Verhalten im Code:

• führt setprop persist.sys.usb.config rndis,serial_smd,diag,adb aus
• führt sync aus
• startet das Gerät neu

2004 - IMEI-Überschreibungspfad

{"funcNo":2004,"imei":"<redacted-test-value>"}

Beobachtetes Verhalten im Code:

• ruft einen Pfad auf, der AT+WRIMEI=<value> entspricht
• prüft den Erfolg über einen nachfolgenden IMEI-Rücklesepfad

Hier ist kein öffentlicher Live-Test enthalten, da rechtliche, Compliance- und Geräteintegritätsbedenken bestehen.

Belegauszüge

Beispiel einer nicht authentifizierten Antwort für 1002

{
  "results": [
    {
      "dns1": "8.8.8.8",
      "ssid": "4G-UFI-8E1",
      "dns2": "8.8.8.8",
      "mask": "255.255.255.0",
      "pwd": "1234567890",
      "wlan_ip": "192.168.100.1",
      "IP": "192.168.100.1"
    }
  ],
  "error_info": "none",
  "flag": "1"
}

Beispiel einer nicht authentifizierten Antwort für 1029

{
  "results": [
    {
      "manufacture": "Qualcomm Technology",
      "dbm": "",
      "fwversion": "V3.4.3",
      "imei": "863993064154463"
    }
  ],
  "error_info": "none",
  "flag": "1"
}

Warum dies ein CVE-Kandidat ist

Dieses Problem ist ein starker CVE-Kandidat, weil es:

• auf einem kundenkontrollierten Gerät reproduzierbar ist
• von einem Angreifer im angrenzenden Netzwerk erreichbar ist
• nicht von undokumentierten physischen Modifikationen abhängt
• nicht nur ein Problem mit Standardpasswörtern ist
• Auswirkungen auf Vertraulichkeit, Integrität und Verfügbarkeit hat

Vorgeschlagene Klassifizierung:

• CWE-306 Fehlende Authentifizierung für kritische Funktion
• CWE-862 Fehlende Autorisierung

Vorgeschlagener CVSS:

CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

Offenlegungsstatus

• Statische Analyse abgeschlossen: 2026-05-11
• Live-Validierung abgeschlossen: 2026-05-12
• Vorbereitung des Herstellerkontakts abgeschlossen: 2026-05-12
• Öffentlicher Advisory-Entwurf erstellt: 2026-05-12

Gegenmaßnahmen

• eine gültige serverseitig authentifizierte Sitzung für alle Verwaltungsfunktionen verlangen
• alle sensiblen funcNo-Anfragen ohne Authentifizierung ablehnen
• CSRF-Schutz hinzufügen
• Origin und Referer validieren
• undokumentierte Wartungsendpunkte aus Produktions-Builds entfernen
• Wi-Fi-Anmeldedaten niemals über nicht authentifizierte API-Antworten offenlegen

Rechtlicher und Sicherheitshinweis

Dieses Repository ist für defensive Forschung, Schwachstellenoffenlegung und Koordination bestimmt. Öffentliche Beispiele sind absichtlich auf risikoarme Validierung beschränkt. Hochrisikofunktionalität wird nur in dem Umfang dokumentiert, der für Abhilfe und CVE-Triage erforderlich ist.