Electron Desktop Apps
Last updated
Last updated
Leer & oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Leer & oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Electron kombineer 'n plaaslike backend (met NodeJS) en 'n frontend (Chromium), alhoewel dit sommige van die sekuriteitsmeganismes van moderne blaaiers mis.
Gewoonlik kan jy die electron app kode binne 'n .asar
toepassing vind, om die kode te verkry moet jy dit onttrek:
In die bronkode van 'n Electron-app, binne packet.json
, kan jy die main.js
-lêer vind waar sekuriteitskonfigurasies ingestel is.
Electron het 2 prosestipes:
Hoofproses (het volledige toegang tot NodeJS)
Renderer-proses (moet beperkte toegang tot NodeJS hê om veiligheidsredes)
'n renderer-proses sal 'n blaaiervenster wees wat 'n lêer laai:
Die instellings van die renderer process kan gekonfigureer word in die main process binne die main.js-lêer. Sommige van die konfigurasies sal voorkom dat die Electron-toepassing RCE kry of ander kwesbaarhede as die instellings korrek geconfigureer is.
Die electron-toepassing kan toegang tot die toestel verkry via Node-apis alhoewel dit geconfigureer kan word om dit te voorkom:
nodeIntegration
- is af
per standaard. As aan, laat dit toe om toegang te verkry tot node-funksies vanaf die renderer process.
contextIsolation
- is aan
per standaard. As af, is hoof- en renderer proses nie geïsoleer nie.
preload
- leeg per standaard.
sandbox
- is af per standaard. Dit sal die aksies wat NodeJS kan uitvoer beperk.
Node Integrasie in Werkers
nodeIntegrationInSubframes
- is af
per standaard.
As nodeIntegration
geaktiveer is, sal dit die gebruik van Node.js APIs in webblaaie wat in iframes binne 'n Electron-toepassing gelaai word, toelaat.
As nodeIntegration
gedeaktiveer is, sal preloads in die iframe gelaai word.
Voorbeeld van konfigurasie:
Sommige RCE payloads van hier:
Wysig die start-main konfigurasie en voeg die gebruik van 'n proxy soos by:
As jy 'n Electron App plaaslik kan uitvoer, is dit moontlik dat jy dit kan laat uitvoer willekeurige javascript kode. Kyk hoe in:
As die nodeIntegration op aan gestel is, kan 'n webblad se JavaScript maklik Node.js kenmerke gebruik net deur die require()
aan te roep. Byvoorbeeld, die manier om die calc toepassing op Windows uit te voer is:
Die skrip wat in hierdie instelling aangedui word, word voor ander skripte in die renderer gelaai, so dit het onbeperkte toegang tot Node APIs:
Daarom kan die skrip node-features na bladsye uitvoer:
As contextIsolation
aan is, sal dit nie werk nie
Die contextIsolation stel die geskeide kontekste tussen die webbladskripte en die JavaScript Electron se interne kode in, sodat die JavaScript-uitvoering van elke kode nie mekaar beïnvloed nie. Dit is 'n noodsaaklike kenmerk om die moontlikheid van RCE te elimineer.
As die kontekste nie geskei is nie, kan 'n aanvaller:
Arbitraire JavaScript in renderer uitvoer (XSS of navigasie na eksterne webwerwe)
Oorskryf die ingeboude metode wat in preload of Electron interne kode gebruik word na eie funksie
Trigger die gebruik van oorgeskrewe funksie
RCE?
Daar is 2 plekke waar ingeboude metodes oorgeskryf kan word: In preload kode of in Electron interne kode:
As daar beperkings toegepas word wanneer jy op 'n skakel klik, mag jy in staat wees om dit te omseil deur 'n middelklik te doen in plaas van 'n gewone linkerklik
Vir meer inligting oor hierdie voorbeelde, kyk na https://shabarkin.medium.com/1-click-rce-in-electron-applications-79b52e1fe8b8 en https://benjamin-altpeter.de/shell-openexternal-dangers/
Wanneer 'n Electron-desktoptoepassing ontplooi word, is dit van kardinale belang om die korrekte instellings vir nodeIntegration
en contextIsolation
te verseker. Dit is gevestig dat kliënt-kant afstandkode-uitvoering (RCE) wat op preload-skripte of Electron se inheemse kode van die hoofproses teiken, effektief voorkom word met hierdie instellings in plek.
Wanneer 'n gebruiker met skakels interaksie het of nuwe vensters oopmaak, word spesifieke gebeurtenisluisteraars geaktiveer, wat van kardinale belang is vir die toepassing se sekuriteit en funksionaliteit:
Hierdie luisteraars word oorheers deur die lessenaartoepassing om sy eie besigheidslogika te implementeer. Die toepassing evalueer of 'n genavigeerde skakel intern of in 'n eksterne webblaaier geopen moet word. Hierdie besluit word tipies geneem deur 'n funksie, openInternally
. As hierdie funksie false
teruggee, dui dit aan dat die skakel ekstern geopen moet word, met die gebruik van die shell.openExternal
funksie.
Hier is 'n vereenvoudigde pseudokode:
Electron JS sekuriteitsbeste praktyke raai teen die aanvaarding van onbetroubare inhoud met die openExternal
funksie, aangesien dit kan lei tot RCE deur verskeie protokolle. Bedryfstelsels ondersteun verskillende protokolle wat RCE kan ontketen. Vir gedetailleerde voorbeelde en verdere verduideliking oor hierdie onderwerp, kan 'n mens na hierdie hulpbron verwys, wat Windows-protokolvoorbeelde insluit wat in staat is om hierdie kwesbaarheid te benut.
Voorbeelde van Windows-protokolontploffings sluit in:
Deaktiveer contextIsolation
stel die gebruik van <webview>
merke in, soortgelyk aan <iframe>
, vir die lees en eksterne oordrag van plaaslike lêers. 'n Voorbeeld wat gegee word demonstreer hoe om hierdie kwesbaarheid te benut om die inhoud van interne lêers te lees:
Verder word 'n ander metode vir die lees van 'n interne lêer gedeel, wat 'n kritieke plaaslike lêer lees kwesbaarheid in 'n Electron desktop-app uitlig. Dit behels die inspuiting van 'n skrip om die toepassing te benut en data te eksterne oordrag:
As die chromium wat deur die toepassing gebruik word oud is en daar bekende kwesbaarhede daarop is, mag dit moontlik wees om dit te benut en RCE te verkry deur 'n XSS. Jy kan 'n voorbeeld in hierdie skrywe sien: https://blog.electrovolt.io/posts/discord-rce/
As jy 'n XSS gevind het maar jy kan nie RCE aktiveer of interne lêers steel nie, kan jy probeer om dit te gebruik om akkrediteer te steel via phishing.
Eerstens moet jy weet wat gebeur wanneer jy probeer om 'n nuwe URL te open, deur die JS-kode in die front-end na te gaan:
Die oproep na openInternally
sal besluit of die skakel in die desktop venster geopen sal word, aangesien dit 'n skakel is wat aan die platform behoort, of of dit in die blaaier as 'n 3de party hulpbron geopen sal word.
In die geval dat die regex wat deur die funksie gebruik word kwulnerabel is vir omseilings (byvoorbeeld deur nie die punte van subdomeine te ontsnap nie) kan 'n aanvaller die XSS misbruik om n nuwe venster te open wat in die aanvallers infrastruktuur geleë sal wees wat om akrediteerbare inligting van die gebruiker vra:
Electronegativity is 'n hulpmiddel om miskonfigurasies en sekuriteitsanti-patrone in Electron-gebaseerde toepassings te identifiseer.
Electrolint is 'n oopbron VS Code-inprop vir Electron-toepassings wat Electronegativity gebruik.
nodejsscan om kwesbare derdeparty-biblioteke te kontroleer
Electro.ng: Jy moet dit koop
In https://www.youtube.com/watch?v=xILfQGkLXQo&t=22s kan jy 'n laboratorium vind om kwesbare Electron-toepassings te benut.
Sommige opdragte wat jou sal help met die laboratorium:
Meer navorsing en skrywe oor Electron-sekuriteit in https://github.com/doyensec/awesome-electronjs-hacking
Leer & oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Leer & oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)