Node inspector/CEF debug abuse
Leer & oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Leer & oefen GCP Hacking:
HackTricks Training GCP Red Team Expert (GRTE)
Basiese Inligting
Uit die dokumentasie: Wanneer dit met die --inspect
skakel begin word, luister 'n Node.js proses vir 'n debug kliënt. Deur standaard sal dit luister op gasheer en poort 127.0.0.1:9229
. Elke proses word ook aan 'n unieke UUID toegeken.
Inspector kliënte moet die gasheeradres, poort en UUID ken en spesifiseer om te verbind. 'n Volledige URL sal iets soos ws://127.0.0.1:9229/0f2c936f-b1cd-4ac9-aab3-f63b0f33d55e
lyk.
Aangesien die debugger volle toegang tot die Node.js uitvoeringsomgewing het, mag 'n kwaadwillige akteur wat in staat is om met hierdie poort te verbind, in staat wees om arbitrêre kode namens die Node.js proses uit te voer (potensiële privilige-eskalasie).
Daar is verskeie maniere om 'n inspector te begin:
Wanneer jy 'n ondersoekte proses begin, sal iets soos hierdie verskyn:
Processes gebaseer op CEF (Chromium Embedded Framework) moet die param gebruik: --remote-debugging-port=9222
om die debugger oop te maak (die SSRF beskermings bly baie soortgelyk). Hulle in plaas daarvan om 'n NodeJS debug sessie te verleen, sal met die blaaier kommunikeer deur die Chrome DevTools Protocol, dit is 'n koppelvlak om die blaaiers te beheer, maar daar is nie 'n direkte RCE nie.
Wanneer jy 'n gedebugde blaaiers begin, sal iets soos hierdie verskyn:
Browsers, WebSockets en dieselfde oorsprong beleid
Webwerwe wat in 'n web-blaaier oopgemaak word, kan WebSocket en HTTP versoeke maak onder die blaaiers se sekuriteitsmodel. 'n Aanvanklike HTTP-verbinding is nodig om 'n unieke debugger sessie id te verkry. Die dieselfde oorsprong beleid verhinder webwerwe om hierdie HTTP-verbinding te maak. Vir addisionele sekuriteit teen DNS rebinding aanvalle, verifieer Node.js dat die 'Host' headers vir die verbinding of 'n IP adres of localhost
of localhost6
presies spesifiseer.
Hierdie sekuriteitsmaatreëls verhinder die benutting van die inspekteur om kode te loop deur net 'n HTTP versoek te stuur (wat gedoen kon word deur 'n SSRF kwesbaarheid te benut).
Begin inspekteur in lopende prosesse
Jy kan die sein SIGUSR1 na 'n lopende nodejs-proses stuur om dit te begin die inspekteur in die standaardpoort. Let egter daarop dat jy genoeg voorregte moet hê, so dit mag jou voorregte toegang tot inligting binne die proses gee, maar nie 'n direkte voorregverhoging nie.
Dit is nuttig in houers omdat om die proses af te sluit en 'n nuwe een te begin met --inspect
nie 'n opsie is nie omdat die houer saam met die proses gekill sal word.
Verbind met inspekteur/debugger
Om met 'n Chromium-gebaseerde blaaier te verbind, kan die chrome://inspect
of edge://inspect
URL's vir Chrome of Edge, onderskeidelik, toeganklik gemaak word. Deur op die Konfigureer-knoppie te klik, moet verseker word dat die teikenhost en poort korrek gelys is. Die beeld toon 'n Afgeleide Kode Uitvoering (RCE) voorbeeld:
![](https://book.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2F843477771-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FC6PyZhjUxJWWaN3uLo1y%252Fuploads%252Fgit-blob-a508ab7ae0c49543e0de84d5e01d61516b59f7b7%252Fimage%2520%28674%29.png%3Falt%3Dmedia&width=768&dpr=4&quality=100&sign=55cf7853&sv=1)
Met die opdraglyn kan jy met 'n debugger/inspekteur verbind met:
Die hulpmiddel https://github.com/taviso/cefdebug laat jou toe om inspekteurs wat plaaslik loop te vind en kode daarin te injekteer.
Let daarop dat NodeJS RCE exploits nie sal werk as dit aan 'n blaaskans gekoppel is via Chrome DevTools Protocol (jy moet die API nagaan om interessante dinge te vind om daarmee te doen).
RCE in NodeJS Debugger/Inspector
As jy hier gekom het om te kyk hoe om RCE uit 'n XSS in Electron te kry, kyk asseblief na hierdie bladsy.
Sommige algemene maniere om RCE te verkry wanneer jy kan verbinde met 'n Node inspector is om iets soos (lyk of dit nie sal werk in 'n verbinding met Chrome DevTools protocol):
Chrome DevTools Protocol Payloads
You can check the API here: https://chromedevtools.github.io/devtools-protocol/ In this section I will just list interesting things I find people have used to exploit this protocol.
Parameter Injection via Deep Links
In the CVE-2021-38112 Rhino-sekuriteit het ontdek dat 'n toepassing gebaseer op CEF 'n persoonlike URI in die stelsel geregistreer het (workspaces://) wat die volle URI ontvang het en toe die CEF-gebaseerde toepassing met 'n konfigurasie wat gedeeltelik van daardie URI saamgestel is, begin het.
Dit is ontdek dat die URI parameters URL-dekodeer is en gebruik is om die CEF-basis toepassing te begin, wat 'n gebruiker toelaat om die vlag --gpu-launcher
in die opdraglyn in te spuit en arbitrêre dinge uit te voer.
So, a payload like:
Will execute a calc.exe.
Oorskrywe Lêers
Verander die gids waar afgelaaide lêers gestoor gaan word en laai 'n lêer af om oor te skryf op dikwels gebruikte bronkode van die toepassing met jou kwaadwillige kode.
Webdriver RCE en eksfiltrasie
Volgens hierdie pos: https://medium.com/@knownsec404team/counter-webdriver-from-bot-to-rce-b5bfb309d148 is dit moontlik om RCE te verkry en interne bladsye van theriver te eksfiltreer.
Post-Exploitatie
In 'n werklike omgewing en na die kompromittering van 'n gebruiker se rekenaar wat 'n Chrome/Chromium-gebaseerde blaaiert gebruik, kan jy 'n Chrome-proses met die ontfouting geaktiveer en die ontfoutingspoort begin sodat jy toegang kan verkry. Op hierdie manier sal jy in staat wees om alles wat die slagoffer met Chrome doen te inspekteer en sensitiewe inligting te steel.
Die stil manier is om elke Chrome-proses te beëindig en dan iets soos te bel
Verwysings
Leer & oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Leer & oefen GCP Hacking:
HackTricks Training GCP Red Team Expert (GRTE)
Last updated