Kritischer Exploit in MediaTek-Wi‑Fi-Chipsätzen: Zero-Click-Schwachstelle

Schwere Schwachstelle in MediaTek-Wi‑Fi-Chipsätzen: Zero-Click-Schwachstelle (CVE-2024-20017) bedroht Router und Smartphones

Überblick

• Das Threat-Research-Team von SonicWall Capture Labs hat die Schwachstelle CVE-2024-20017 erkannt, ihre Auswirkungen bewertet und Maßnahmen zur Eindämmung entwickelt
• CVE-2024-20017 ist eine kritische Zero-Click-Schwachstelle mit einem CVSS-3.0-Score von 9.8 und betrifft die MediaTek-Wi‑Fi-Chipsätze MT7622/MT7915 sowie RTxxxx-SoftAP-Treiber-Bundles
• Betroffen sind MediaTek SDK Version 7.4.0.1 und frühere Versionen sowie OpenWrt 19.07 und 21.02, die in Produkten verschiedener Hersteller wie Ubiquiti, Xiaomi und Netgear verwendet werden
• Die Schwachstelle ermöglicht Remote Code Execution ohne Benutzerinteraktion, und MediaTek hat Patches zur Eindämmung bereitgestellt
• Die Schwachstelle wurde im März offengelegt und gepatcht, doch durch ein kürzlich veröffentlichtes PoC ist die Wahrscheinlichkeit einer Ausnutzung gestiegen

Technischer Überblick

• Die Schwachstelle befindet sich in wappd, einem Netzwerk-Daemon im MediaTek-MT7622/MT7915-SDK und in RTxxxx-SoftAP-Treiber-Bundles
• wappd ist für die Konfiguration und Verwaltung von Wireless-Interfaces und Access Points zuständig und steht insbesondere mit der Hotspot-2.0-Technologie in Zusammenhang
• Die Architektur von wappd besteht aus dem Netzwerkdienst selbst, einem Satz lokaler Dienste, die mit den Wireless-Interfaces des Geräts interagieren, sowie einem Kommunikationskanal zwischen den Komponenten über Unix-Domain-Sockets
• Die Schwachstelle entsteht durch einen Buffer Overflow, weil ein direkt aus paketgesteuerten Daten übernommener Längenwert für eine Speicherkopie verwendet wird

Auslösen der Schwachstelle

• Die Schwachstelle tritt in der Funktion IAPP_RcvHandlerSSB auf, wobei ein vom Angreifer kontrollierter Längenwert an das Makro IAPP_MEM_MOVE übergeben wird
• Abgesehen von der Prüfung, dass die maximale Paketlänge 1600 Byte nicht überschreitet, gibt es keine Boundary Checks
• Der Angreifer muss ein Paket senden, bei dem die erwartete Struktur dem Angriffs-Payload vorangestellt ist
• Die Länge der Struktur RT_IAPP_HEADER muss klein sein, und das Feld RT_IAPP_HEADER.Command muss 50 sein

Ausnutzung

• Öffentlich verfügbarer Exploit-Code erreicht Remote Code Execution mithilfe einer ROP-Chain und einer Technik zum Überschreiben der Global Offset Table
• Dabei wird ein Aufruf von system() genutzt, um einen Befehl auszuführen, der eine Reverse Shell an den Angreifer sendet
• Die Reverse Shell wird mit Bash- und Netcat-Tools eingerichtet

SonicWall-Schutz

• Damit SonicWall-Kunden sich vor einer Ausnutzung dieser Schwachstelle schützen können, wurden die folgenden Signaturen bereitgestellt
  • IPS: 20322 MediaTek MT7915 wlan Service OOB Write 1
  • IPS: 20323 MediaTek MT7915 wlan Service OOB Write 2

Empfehlungen zur Eindämmung

• Da Exploit-Code veröffentlicht wurde, wird Nutzern dringend empfohlen, auf die neueste Firmware-Version für die betroffenen Chipsätze zu aktualisieren

Relevante Links

• MediaTek-Sicherheitshinweis
• CoffinSec-Blog
• Informationen von Security Online
• GitHub-Repository

Zusammenfassung von GN⁺

• Dieser Artikel behandelt eine kritische Zero-Click-Schwachstelle in MediaTek-Wi‑Fi-Chipsätzen, die Remote Code Execution ohne Benutzerinteraktion ermöglicht
• Das Forschungsteam von SonicWall hat die Schwachstelle erkannt und Gegenmaßnahmen entwickelt und empfiehlt Nutzern ein Upgrade auf die neueste Firmware
• Die Schwachstelle betrifft Router und Smartphones verschiedener Hersteller, und durch ein kürzlich veröffentlichtes PoC ist die Wahrscheinlichkeit einer Ausnutzung gestiegen
• Ein Produkt mit ähnlichen Funktionen sind die Wi‑Fi-Chipsätze von Qualcomm; wichtig ist, regelmäßig nach Sicherheitsupdates zu suchen

[GN⁺]

Hacker-News-Kommentare

• Es gibt die Bitte, den Link des OP von einer Anzeige auf die Originalquelle zu ändern

  • Originalquelle: CoffinSec-Blog

• Es wird angemerkt, dass der Treiber-Quellcode im Vendor-SDK von MediaTek im Vergleich zu mt76 ein einziges Chaos ist

  • Einige Nutzer verwenden Aftermarket-Firmware, die den Vendor-Treiber einsetzt
  • In der WiSoC-Abteilung von MediaTek gibt es Ingenieure, die aktiv mit der FOSS-Community kommunizieren
  • Sie pflegen einen OpenWrt-Fork, der mt76 verwendet
  • Relevanter Link: MediaTek OpenWrt Feeds

• Es gibt die Meinung, dass der Titel irreführend sein könnte

  • Jemand hat einen Router mit mt76-Wi-Fi und befürchtete zunächst einen Firmware- oder Silizium-Bug, war dann aber erleichtert zu erfahren, dass es sich um ein Problem im Vendor-SDK handelt
  • Es ist schwer nachzuvollziehen, warum man das Vendor-SDK verwendet, obwohl mt76 im Mainline-Kernel und in hostapd gut unterstützt wird

• Fragen zur Namenskonvention von MediaTek

  • Es wird vermutet, dass Geräte mit dem Wi-Fi-Chip mt6631 nicht betroffen sind, sicher ist man sich aber nicht

• Es heißt, OpenWrt 19.07 und 21.02 seien betroffen, aber die offiziellen Builds verwenden nur den mt76-Treiber

• In einem Laptop mit AMD-CPU steckt eine MediaTek-RZ616-Wi-Fi-Karte, die gerade durch eine Intel-Wi-Fi-Karte ersetzt wird

  • Nach dem Austausch stapeln sich nun die RZ616-Karten, was zum Problem wird

• Jemand hat ein Smartphone mit einem MediaTek-Chipsatz und erinnert sich, dass der Hersteller wegen Qualitätsproblemen bei MediaTek-Produkten auf andere Produkte umgestiegen ist

  • Wie das Wi-Fi im Smartphone funktioniert, ist unklar
  • Wi-Fi wird kaum genutzt, aber man möchte wissen, ob das Smartphone betroffen ist

• Betroffen sind MediaTek-SDK-Versionen bis 7.4.0.1 sowie OpenWrt 19.07 und 21.02

  • Die Schwachstelle steckt in wappd, dem Netzwerk-Daemon, der in den MediaTek-MT7622/MT7915-SDKs und den RTxxxx-SoftAP-Treiber-Bundles enthalten ist
  • OpenWrt scheint wappd nicht zu verwenden

• Es wird angemerkt, dass unverständlich ist, warum C-Klasse-Vendoren ihre Firmware nicht als Open Source veröffentlichen