Vor zwei Jahren hat der bekannte Google Project-Zero Sicherheitsforscher Tavis Ormandy ein kleines Script mit dem Namen cefdebug geschrieben.1 Gedacht für alle Anwendungen, die zur Darstellung von Webseiten die Chrome Engine (CEF)2 oder das Framework Electron3 einsetzen.
Böse formuliert ist Electron das neue Flash4. Eingesetzt von hippen (Web-)Entwicklern, die sich um die Konsequenzen und Tragweite Ihrer Designentscheidungen nicht scheren.
Allein der Bequemlichkeit wegen werden Web-Anwendungen mit viel HTML, CSS und Javascript erstellt, um dann mit dem Overhead eines Browsers und Webservers cross-platform auf den Geräten der Anwender zu landen.
Da war man vor Jahren weiter, als die ersten Anwender sich über hochdrehende Lüfter und einen Batterie-Drain auf mobilen Geräten beschwerten wenn mehrere Instanzen einer Browser-Engine mitsamt des jeweiligen Webservers auf tendenziell eher schwachen Consumer-Geräten hochfuhren. Ein Chat-Programm, eine Notizen-Verwaltung oder ein simpler Quelltext-Editor, der sich im Mittel 10% oder mehr an CPU Leistung und hunderte von MB an RAM zieht ist dahingerotzter Schrott oder wie es der Blogger Drew DeVault bereits im Jahr 2016 formuliert:5
Electron enables lazy developers to write garbage
Zurück zu Tavis Ormandy. Sein Frust mit genau solcher Art von Entwicklern und deren Software mit “vergessenen” Debugging-Schnittstellen führe zur Entwicklung von cefdebug.
Wer zum Selbsttesten unter Windows die EXE-Binary versucht auszuführen, sollte sich nicht wundern, wenn das übliche Antivirus-Schlangenöl diese als gefährlich identifiziert. Prüft eine Software daher immer am besten in einer geschützten Testumgebung, was generell eine gute Faustregel ist. Führt die Ausgabe von cefdebug in der Konsole zu einem “There were x servers that appear to be CEF debuggers” ist der Test positiv.
Es sind es diese offenen Debug-Ports, die als Überraschung auf den Rechnern Ihrer Anwender riesige Sicherheitslöcher aufreißen. Und gefühlt sind diese in jedem dritten Ei von irgendwelchen hippen Start-Ups anzutreffen. Eine Zeile Javascript reicht aus, um im Hintergrund unerkannt beliebige Programme zu starten:
window.appshell.app.openURLInDefaultBrowser("c:/windows/system32/calc.exe")
Die Einbindung erfolgt trivial in HTML meist clickless und ohne Notwendigkeit einer weiteren Interaktion:
<img src=http://127.0.0.1:anyport/json/new?javascript:alert(1)>
In Kombination mit anderen Schwachstellen wie beispielsweise DNS-Rebinding6 kann von einer lokalen Codeausführung auch remote Code von fremden Webservern nachladen werden.
Es handelt sich technisch betrachtet um Cross-Site Angriffe, die normalerweise von CSRF7 Gegenmaßnahmen in regulären Webbrowsern und von richtig konfigurierten Webservern unterbunden werden. Nicht bei Electron/Node.js auf einem lokalen Rechner mit “vergessenen” Debugging-Schaltern.
Die Faulheit und das Unwissen der (Web-)Entwickler führt zum Komfort bei der Distribution von Malware. Der Empfang einer Chat-Nachricht mit einem unscheinbaren Emoticon reicht aus.
Das sind die Gründe, warum ich solche Anwendungen meide. Ich lege es jedem anheim, der Wert auf flüssiges Arbeiten legt und nicht alle paar Jahre zu neuer Hardware greifen will nur weil die alte vermeintlich zu langsam ist.
In diesem Sinne,
das Wochenende ist nicht mehr weit.
Tomas Jakobs