Bericht des Geräts Netis WF2409E

1. Geräteübersicht

1.1 Tabelle der Hauptmerkmale

1.2 Tabelle der Funktionsprüfung

1.3 Hauptkomponenten des Systems

2. Untersuchung der Kontakte

2.1 Verbindung zum Gerät über serielle Schnittstelle

3. Boot-Log, Bootloader-Befehle und Betriebssystem

3.1 Analyse des Boot-Logs

Prozessor-Spezifikationen

Flash-Speicher-Spezifikationen

Bootloader-Informationen

Standard-Netzwerkeinstellungen

Systemsoftware-Informationen

Dienststatus

Es ist wichtig zu beachten, dass dieses Gerät wahrscheinlich kein U-Boot verwendet. Wichtige Anzeichen:

1. Das Log beginnt direkt mit den RealTek-Bootinformationen: ---RealTek(RTL8196E)at 2014.09.29-19:16+0800 v1.0 [16bit](https://github.com/victorique-123/cve-2023-38829-netis-wf2409e_report/blob/master/380MHz)
2. Es fehlen typische Anzeichen eines U-Boot-Starts:

• Keine Informationen über die U-Boot-Version
• Keine Informationen über die Initialisierung von U-Boot-Umgebungsvariablen
• Keine U-Boot-Eingabeaufforderung

3. RTL8196E ist ein preisgünstiger Router-Chip von RealTek; viele Geräte auf dieser Basis verwenden den eigenen RealTek-Bootloader anstelle von U-Boot.
4. Angesichts der geringen Flash-Speicherkapazität (4 MB) ist die Verwendung eines schlanken Bootloaders sinnvoller. Tatsächlich konnte kein Weg gefunden werden, in U-Boot zu gelangen.

3.2 Analyse des Bootloaders

Um in den Bootloader zu gelangen, muss während des Bootvorgangs die Esc-Taste gedrückt gehalten werden:

Vollständiger Befehlssatz des RealTek-Bootloaders

Beispiel für Speicherlesen:

Bootloader-Befehle :

<RealTek> FLR 80000000 0 100 #Lesen aus Flash DB 80000000 100 #Anzeigen des Speicherinhalts

3.3 Analyse der Shell-Umgebung

Grundlegende Shell-Befehle

Detaillierte Struktur der Systemverzeichnisse (/bin — wichtige Werkzeuge)

Wichtige Informationen des /proc-Verzeichnisses

Prozessliste:

3.4 Beschreibung der wichtigsten Hardwarekomponenten

4. Analyse der Mount-Point-Informationen

4.1 Abrufen der Mount-Informationen der Partitionen

4.2 Im System wurden drei Haupt-Mount-Punkte identifiziert:

• /dev/mtdblock1 als Root-Verzeichnis / gemountet
• none als Prozessdateisystem /proc gemountet
• tmpfs als temporäres Dateisystem /var gemountet

Detaillierte Analyse

4.2.1. Root-Dateisystem

Das Root-Dateisystem ist wie folgt konfiguriert:

• Gerät: /dev/mtdblock1
• Dateisystemtyp: squashfs
• Mount-Optionen: Nur-Lesen (ro)
• Zweck: Speicherung von Systemdateien und Programmen

Dies deutet auf die Verwendung von MTD-Flash-Speicher als Medium hin, wobei die Systemdateien durch Nur-Lesen und squashfs-Kompression geschützt und volumenoptimiert sind.

4.2.2 Prozessdateisystem

Das Prozessdateisystem ist wie folgt konfiguriert:

• Gerät: none (virtuelles Dateisystem)
• Dateisystemtyp: proc
• Mount-Optionen: Lese-Schreiben (rw)
• Zweck: Bereitstellung einer Schnittstelle für den Zugriff auf System- und Prozessinformationen

4.2.3 Temporäres Dateisystem

Das temporäre Dateisystem ist wie folgt konfiguriert:

• Gerät: tmpfs (Dateisystem im Arbeitsspeicher)
• Mount-Punkt: /var
• Größenbeschränkung: 230 KB
• Mount-Optionen: Lese-Schreiben (rw)
• Zweck: Speicherung temporärer Dateien und Daten während des Betriebs

4.2.4 Es wurde festgestellt, dass die meisten Befehle im System fehlen

5. Struktur und Format der Firmware

5.1 Abrufen der Firmware "netis.bin"

5.2 Durchführung einer Entropieanalyse:

binwalk -E --save netis.bin

5.3 Header-Analyse:

binwalk netis.bin

5.4 Zum Entpacken werden die Argumente –reM verwendet.

Und erhält:

5.5 Tabelle der Analyseergebnisse

Offset	Partitions-Header
0x12F0
0x32818

6. Dateisystem nach dem Entpacken der Firmware

6.1 Dateisystem nach dem Entpacken:

6.2 Einige wichtige Dokumente

6.2.1 etc/passwd:

Mit dem Hash-Entschlüsselungsdienst https://hashes.com/en/decrypt/hash wurde das Root-Passwort erfolgreich als realtek wiederhergestellt.

6.2.2 web/welcome.htm:

Dies ist die Standard-Webinterface-Seite

7. Marker, Fingerabdruck für FOFA, Statistiken

Gerätesuche in FOFA über Merkmale in web/welcome.htm:

Suchbefehle: body="./images/logo_netis.png" && body="display:block; height:60px; float:left;"

Für den Zugriff auf das Administrationspanel des Geräts kann eine Authentifizierung mit Benutzername und Passwort erforderlich sein

Nach erfolgreicher Authentifizierung kann das Administrationspanel betreten werden

8. Identifikationsskript

Zuerst wurden mit dem Befehl ~/squashfs-root/web$ find die verfügbaren Verzeichnisse gefunden und mit Burpsuit wurde deren Zugänglichkeit überprüft:| | Payload | Code | | Lenth | | ------ | ------------------------------- | ------- | ----- | --------- | | 1 | /cgi-bin | 200 | | 167 | | 2 | /cgi-bin/cgitest.cgi | - | ERROR | - | | 3 | /script | 200 | | 168 | | 4 | /script/init.js | 200 | | 1282 | | 5 | /script/logic.js | 200 | | 65677 | | 6 | /script/menu.js | 200 | | 4976 | | 7 | /script/netcore.js | 200 | | 151935 | | 8 | /script/action.js | 200 | | 182624 | | 9 | /script/debug.js | 200 | | 28570 | | ==10== | ==/version.txt== | ==200== | | ==206== | | ==11== | ==/update.htm== | ==200== | | ==1230== | | 12 | /config | 200 | | 168 | | 13 | /config/language_es.js | 200 | | 79333 | | 14 | /config/language_it.js | 200 | | 76802 | | 15 | /config/language_id.js | 200 | | 74795 | | 16 | /config/language_du.js | 200 | | 78782 | | 17 | /config/language_ma.js | 200 | | 73594 | | 18 | /config/language_po.js | 200 | | 76458 | | 19 | /config/language_tu.js | 200 | | 77747 | | 20 | /config/language_fr.js | 200 | | 78165 | | 21 | /config/language_ro.js | 200 | | 73621 | | 22 | /config/language_cz.js | 200 | | 75968 | | 23 | /config/language_ua.js | 200 | | 98335 | | 24 | /config/language_us.js | 200 | | 84173 | | 25 | /config/config.js | 200 | | 75899 | | 26 | /config/language_ru.js | 200 | | 108998 | | 27 | /config/language_de.js | 200 | | 78674 | | 28 | /config/language_pt.js | 200 | | 77954 | | 29 | /config/language_cn.js | 200 | | 62001 | | 30 | /config/language_tc.js | 200 | | 74268 | | 31 | /system_log.txt | 404 | | 330 | | ==32== | ==/index.htm== | ==200== | | ==4336== | | 33 | /css | 200 | | 167 | | 34 | /css/style.css | 200 | | 5441 | | 35 | /css/netcore.css | 200 | | 11536 | | 36 | /css/welcome.css | 200 | | 6270 | | 37 | /Config.tgz | 404 | | 326 | | 38 | /images | 200 | | 168 | | 39 | /images/first.png | 200 | | 838 | | 40 | /images/icon_no.gif | 200 | | 240 | | 41 | /images/top_right_bg.gif | 200 | | 222 | | 42 | /images/logo_netis.png | 200 | | 7297 | | 43 | /images/icon_jian.gif | 200 | | 239 | | 44 | /images/show_pwd.png | 200 | | 1433 | | 45 | /images/icon_no1.gif | 200 | | 498 | | 46 | /images/nextt.png | 200 | | 1026 | | 47 | /images/lastt.png | 200 | | 845 | | 48 | /images/icon_intro_internet.gif | 200 | | 6994 | | 49 | /images/help_b1.gif | 200 | | 540 | | 50 | /images/high.gif | 200 | | 10846 | | 51 | /images/yandex_en.png | 200 | | 3519 | | 52 | /images/help_b1.jpg | 200 | | 620 | | 53 | /images/back.gif | 200 | | 379 | | 54 | /images/icon_intro_wireless.jpg | 200 | | 3838 | | 55 | /images/icon_jian1.gif | 200 | | 490 | | 56 | /images/left_021.jpg | 200 | | 558 | | 57 | /images/edit.gif | 200 | | 365 | | 58 | /images/pre.png | 200 | | 1029 | | 59 | /images/btn_mobile_setup.jpg | 200 | | 3053 | | 60 | /images/icon_now.gif | 200 | | 242 | | 61 | /images/top_right_bg.jpg | 200 | | 223 | | 62 | /images/bg_intro_bottom.png | 200 | | 3562 | | 63 | /images/favicon.ico | 200 | | 4458 | | 64 | /images/btn_quick_setup.jpg | 200 | | 4353 | | 65 | /images/bg_intro_top.png | 200 | | 3605 | | 66 | /images/mt-link.gif | 200 | | 5823 | | 67 | /images/link.gif | 200 | | 1045 | | 68 | /images/del.gif | 200 | | 313 | | ==69== | ==/images/Makefile== | ==200== | | ==593== | | 70 | /images/icon_jia1.gif | 200 | | 490 | | 71 | /images/blue.jpg | 200 | | 2584 | | 72 | /images/normal.gif | 200 | | 10818 | | 73 | /images/yandex.png | 200 | | 2159 | | 74 | /images/bg_leftmenu.gif | 200 | | 686 | | 75 | /images/icon_jia.gif | 200 | | 252 | | 76 | /images/icon_now1.gif | 200 | | 487 | | ==77== | ==/welcome.htm== | ==200== | | ==30155== | | ==78== | ==/index.html== | ==200== | | ==326== | | 79 | /help | 200 | | 166 | | ==80== | ==/backup.htm== | ==200== | | ==1304== |

Mögliche Fundorte für Informationen:

Nach der Überprüfung können wir in der Datei ==/version.txt== die folgenden Informationen finden:

• Firmware-Version (firmware version)
• Build-Datum (build date)
• Informationen über den Boa-Server (aus dem Server-Feld des HTTP-Antwortheaders abgerufen)

Die Extraktion dieser Informationen wurde mit einem Python-Skript realisiert:

9. Liste der Schwachstellen mit CVSS

9.1 Liste der Schwachstellen

Derzeit wurden die folgenden Schwachstellen in diesem Gerät entdeckt, von denen die Schwachstelle CVE-2023-38829 eine Befehlseinschleusungsschwachstelle ist, die im Netzwerktestmodul des Routers NETIS SYSTEMS Router WF2409E in den Funktionen ping und traceroute existiert. Über die Weboberfläche können bösartige Befehle in die Parameter dieser Funktionen eingeschleust werden, was zur Ausführung von Befehlen führt.

9.2 Überprüfung der Schwachstelle

Um das Vorhandensein dieser Schwachstelle zu überprüfen, meldete ich mich im Router-Admin-Panel an und testete die Schwachstelle in den Funktionen ping und traceroute. Hier habe ich den Befehl cd && ls && cd etc/ && cat passwd eingeschleust, der den Inhalt der Passwortdatei ausgab.

Unten wird die Ausgabe des Router-Admin-Panels bei der Befehlseinschleusung gezeigt, was das Vorhandensein der Schwachstelle bestätigt.

9.3 Bewertung der Schwachstelle nach CVSS

Analyse der erkannten Befehlseinschleusungsschwachstellen nach CVSS 3.1:

1. Bewertung der Basismetrik:

   • Angriffsvektor (AV): Netzwerk (N), da eine Remote-Ausnutzung möglich ist
   • Angriffskomplexität (AC): Niedrig (L), da nur ein HTTP-Request erforderlich ist
   • Benötigte Privilegien (PR): Niedrig (L), es sind grundlegende Benutzerrechte erforderlich (Authentifizierung im Admin-Interface des Geräts)
   • Benutzerinteraktion (UI): Keine (N), keine Benutzeraktion erforderlich
   • Auswirkungsbereich (S): Geändert (C), kann andere mit dem Router verbundene Geräte beeinflussen

2. Auswirkungsmetrik:

   • Vertraulichkeitsauswirkung (C): Hoch (H), vollständiger Systemzugriff möglich
   • Integritätsauswirkung (I): Hoch (H), Änderung beliebiger Systemdateien möglich
   • Verfügbarkeitsauswirkung (A): Hoch (H), Beeinträchtigung des Gerätebetriebs möglich

3. Zeitmetrik:
   • Exploit-Reife (E): Funktionaler Exploit vorhanden (F)
   • Remediation-Level (RL): Offizieller Fix (O)
   • Report Confidence (RC): Bestätigt (C)

Bewertung: 9.2/10 Punkte, was in die Kategorie "kritisch" fällt. CVSS-Vector: AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H/E:F/RL:O/RC:C

Diese hohe Bewertung der Schwachstelle ist auf folgende Gründe zurückzuführen:

• Möglichkeit der Remote-Ausnutzung ohne besondere Bedingungen
• Möglichkeit, Root-Rechte ohne Authentifizierung zu erlangen
• Vollständige Auswirkung auf die Systemsicherheit
• Einfachheit der Ausnutzung der Schwachstelle

10. Analyse der Schwachstelle (BO oder CI)

Lassen Sie uns zunächst die Dateien finden, in denen Schwachstellen sein könnten: find . -name "*.cgi" ./web/cgi-bin/cgitest.cgi ./bin/cgitest.cgi

Ich nehme an, dass Schwachstellen in CGI-Programmen auftreten können. Daher werde ich zunächst versuchen, die Datei ./web/cgi-bin/cgitest.cgi mit IDA Pro zu analysieren.

Zuerst müssen die Aufrufstellen ähnlicher Funktionen gefunden werden. Durch die Suche konnte die Zeichenkette "killall ping" gefunden werden. Bei der Analyse der Aufrufstelle ist zu sehen, dass das Programm nach der Initialisierung der Funktionen ping und traceroute /bin/network_test.sh aufruft.

Und die Stelle, an der die Schwachstelle liegt, ist genau im Netzwerktestmodul. Gut, wir müssen /bin/network_test.sh analysieren.

Analyse von network_test.sh

Zunächst muss eine Suche durchgeführt werden.

Wir finden die Funktion network_test_sh: ......

Bei der detaillierten Analyse der Funktion können die Module zur Befehlsausführung und Ergebnispeicherung entdeckt werden.

In ihnen: Ausführung des Ping-Befehls: ping -c %d -s %d %s -W %d > %s &

• Ping-Parameter:
  • -c: Anzahl der Pings
  • -s: Paketgröße (minus 8 Bytes)
  • -W: Timeout
  • Ziel-IP-Adresse aus der Konfiguration

Ausführung des Traceroute-Befehls: traceroute -I -m %d %s > %s &

• Traceroute-Parameter:
  • -I: Verwendung des ICMP-Protokolls
  • -m: maximale Anzahl der Hops
  • Ziel-IP-Adresse aus der Konfiguration

Detaillierte Analyse der Schwachstelle```

Ситуация с командой ping

loc_4205B8: lw v0, 0x108+var_D4(sp) #прямая загрузка параметров lw a3, 0x108+var_D8(sp) la t9, sprintf #прямой вызов sprintf #отсутствует проверка параметров перед sprintf

Установка аналогична установке на macOS, но с использованием WSL (Windows Subsystem for Linux). После установки WSL и дистрибутива Linux (например, Ubuntu) выполните команды, указанные для Linux.```
# Ситуация с командой traceroute
loc_420574:
la $t9, sprintf #также прямой вызов sprintf
lw $a2, 0x108+var_D0($sp) #также отсутствует проверка параметров

ERSTE SCHRITTE =================```

После построения команды происходит прямое выполнение

la $t9, run_by_system jalr $t9 ; run_by_system #прямой вызов system для выполнения команды move $a0, $s1 #отсутствуют проверки безопасности

![](https://assets.kitploit.com/production/public/readmes/21494/1e9088ba6dfbbf334108926751cc5cf1245a23972df7ce3d48d323b46c27c015.png)

Im Code fehlt eine ausreichende Überprüfung der Eingabeparameter, was ein potenzielles Risiko einer Befehlsinjektion darstellt. Ein Angreifer kann den übergebenen IP-Parameter manipulieren, um Shell-Befehle auszuführen, zum Beispiel:```
# Нормальный ввод 192.168.0.1

# Примеры вредоносного ввода
192.168.0.1; rm -rf / #удаление файлов
192.168.0.1 & id & #выполнение произвольных команд

11. Exploit-Skript

11.1. Übersicht des Skripts

Dieses Skript nutzt eine Command Injection-Schwachstelle in der Weboberfläche des Geräts aus, um durch das Erstellen spezieller HTTP-Anfragen entfernte Befehle auszuführen. Das Skript führt den Exploit mit zwei HTTP-POST-Anfragen durch: Die erste Anfrage injiziert den Befehl, die zweite erhält das Ausführungsergebnis.

Das erste Paket (netcore_set.cgi) dient zum: Injizieren und Ausführen des Befehls

Das zweite Paket (netcore_get.cgi) dient zum: Abrufen des Ausführungsergebnisses

11.2 Erste Phase: Befehlsinjektion

1. Erstellen des POST-Anforderungskörpers mit den folgenden Schlüsselparametern:``` { "mode_name": "netcore_set", "tools_type": "2", "tools_ip_url": f"| {command}", # точка инъекции команды "tools_cmd": "1", "net_tools_set": "1" }

2. URL-Kodierung aller Parameter
3. Senden einer POST-Anfrage an netcore_set.cgi

### 11.3 Zweite Phase: Ergebnisse erhalten

1. Erstellung der zweiten POST-Anfrage:```
	{ "mode_name": "netcore_get",    
	  "noneed": "noneed" }

2. Senden einer Anfrage an netcore_get.cgi
3. Parsen des Feldes tools_results in der Antwort, um das Ergebnis der Befehlsausführung zu erhalten

11.4 Testen der Skripte

Zum Testen des Skripts habe ich eine Datei ceshi auf dem Host erstellt und versucht, sie über das Skript auf das Gerät hochzuladen

Erfolgreich!

Tatsächlich ermöglicht diese Schwachstelle die vollständige Kontrolle über das Gerät, da das Gerät standardmäßig Root-Zugriff verwendet.