M5Stack-Geräte wie der Cardputer ADV werden über M5Burner verwaltet: Das offizielle Desktop-Tool erlaubt es, Firmware zu durchsuchen, herunterzuladen und direkt auf die Hardware zu flashen. Doch wer M5Burner im Netz betreibt, geht ein erhebliches Risiko ein – das hat unser Leser und Sicherheitsforscher „malloc“ in einer detaillierten Analyse aufgedeckt.

Viele Schwachstellen

Der User malloc hat den Electron-basierten Closed-Source-Client (frühere Versionen waren noch Open Source) dekompiliert und dabei eine ganze Reihe von Problemen gefunden:

• Remote Code Execution beim Start: M5Burner lädt beim Start eine Seite über unverschlüsseltes HTTP in ein Electron-Fenster, das mit vollem Node.js-Zugriff läuft: Ein Angreifer im selben Netz kann so beliebigen Code einschleusen, ohne dass der Nutzer etwas anklicken muss.
• Unsicherer Auto-Updater: Updates werden per HTTP ohne Signaturprüfung oder Checksummen heruntergeladen und direkt ins App-Verzeichnis entpackt. Ein klassischer Angriffspunkt für On-Path-Angreifer.
• Command Injection via WLAN-SSID: Die WLAN-SSID des aktuell verbundenen Netzes wird ungefiltert in Shell-Befehle eingebaut (auf Linux, Windows und macOS), ein präparierter SSID-Name reicht für Codeausführung.
• Klartext-HTTP für authentifizierte API-Calls: Account-Token und Firmware-Management-Anfragen gehen unverschlüsselt über Port 80. So genügt passives Mitlesen im selben WLAN zum Token-Diebstahl.
• WLAN-Passwort per IPC abrufbar: Jeder im Fenster ausgeführte Code kann das Passwort des aktuellen WLANs per IPC-Nachricht abfragen und das ohne Nutzerdialog.
• Hardkodierte Zugangsdaten: Im App-Bundle steckt ein statisches HTTP-Basic-Auth-Credential, das in jeder Installation identisch ist.

Wer M5Burner aktuell nutzt, sollte das Tool zumindest nicht in öffentlichen oder nicht vertrauenswürdigen WLANs starten. Für Login, Firmware-Verwaltung und Flashen steht m5uploader als quelloffene Alternative (s.u.) bereit.

Eigentlich unnötig unsicher

Die meisten betroffenen M5Stack-Server unterstützen laut Tests von malloc HTTPS bereits problemlos. Die App nutzt es schlicht nicht konsequent. So wurde jeder genutzte Host geprüft. Mit einer Ausnahme (einem Media-Token-Endpunkt auf Port 5003 ohne TLS-Support) wäre ein simples Umstellen der URLs auf https:// bereits ein großer Schritt für die Sicherheit gewesen. Electron bietet zudem sichere Standardeinstellungen (nodeIntegration: false, contextIsolation: true), die M5Burner aktiv deaktiviert.

Versuch der Responsible Disclosure

Bevor malloc seine Analyse veröffentlichte, versuchte er zunächst, M5Stack privat zu kontaktieren. Er suchte nach einer security.txt, einem SECURITY.md im GitHub-Repository des Unternehmens sowie nach einem dedizierten Sicherheitskontakt auf der Website und fand nichts. Da kein privater Meldeweg existierte, entschied er sich, die Schwachstellen direkt öffentlich zu machen. Der Blogpost ist damit gleichzeitig die Erstmeldung an den Hersteller. malloc schreibt dazu selbst, er hätte eine private Meldung bevorzugt, ihm fehlte schlicht die Adresse dafür. Die beschriebene RCE-Lücke ist damit zum Zeitpunkt der Veröffentlichung gegen die aktuelle, ausgelieferte Version von M5Burner aktiv ausnutzbar.

Open-Source-Ersatz

Weil malloc M5Burner nach der Analyse nicht mehr gegen sein eigenes Konto laufen lassen wollte, hat er kurzerhand einen eigenen Client entwickelt und auf GitHub veröffentlicht: m5uploader (github.com/cryptspeak/m5uploader).

Das Python-Tool setzt konsequent auf HTTPS mit Zertifikatsprüfung, verzichtet auf einen eingebetteten Browser und speichert den Session-Token im OS-Keychain. Ein Auto-Updater fehlt bewusst – stattdessen gibt es nur einen Hinweis auf neue Versionen. Firmware-Flashing via esptool ist inzwischen ebenfalls integriert.

(caw)