Node inspector/CEF debug abuse
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking:
HackTricks Training GCP Red Team Expert (GRTE)
Basic Information
From the docs: When started with the --inspect
switch, a Node.js process listens for a debugging client. By default, it will listen at host and port 127.0.0.1:9229
. Each process is also assigned a unique UUID.
Inspector clients must know and specify host address, port, and UUID to connect. A full URL will look something like ws://127.0.0.1:9229/0f2c936f-b1cd-4ac9-aab3-f63b0f33d55e
.
Since the debugger has full access to the Node.js execution environment, a malicious actor able to connect to this port may be able to execute arbitrary code on behalf of the Node.js process (potential privilege escalation).
There are several ways to start an inspector:
When you start an inspected process something like this will appear:
Processes based on CEF (Chromium Embedded Framework) like need to use the param: --remote-debugging-port=9222
to open de debugger (the SSRF protections remain very similar). However, they instead of granting a NodeJS debug session will communicate with the browser using the Chrome DevTools Protocol, this is an interface to control the browser, but there isn't a direct RCE.
When you start a debugged browser something like this will appear:
Browsers, WebSockets and same-origin policy
Websites open in a web-browser can make WebSocket and HTTP requests under the browser security model. An initial HTTP connection is necessary to obtain a unique debugger session id. The same-origin-policy prevents websites from being able to make this HTTP connection. For additional security against DNS rebinding attacks, Node.js verifies that the 'Host' headers for the connection either specify an IP address or localhost
or localhost6
precisely.
This security measures prevents exploiting the inspector to run code by just sending a HTTP request (which could be done exploiting a SSRF vuln).
Starting inspector in running processes
You can send the signal SIGUSR1 to a running nodejs process to make it start the inspector in the default port. However, note that you need to have enough privileges, so this might grant you privileged access to information inside the process but no a direct privilege escalation.
This is useful in containers because shutting down the process and starting a new one with --inspect
is not an option because the container will be killed with the process.
Connect to inspector/debugger
To connect to a Chromium-based browser, the chrome://inspect
or edge://inspect
URLs can be accessed for Chrome or Edge, respectively. By clicking the Configure button, it should be ensured that the target host and port are correctly listed. The image shows a Remote Code Execution (RCE) example:
![](https://book.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2F129538173-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252F-L_2uGJGU7AVNRcqRvEi%252Fuploads%252FHnMEBvsCDERam4PEvgqd%252Fimage.png%3Falt%3Dmedia%26token%3De2633677-cabf-40ee-a307-32171b1296d7&width=768&dpr=4&quality=100&sign=cbe3e0da&sv=1)
Using the command line you can connect to a debugger/inspector with:
The tool https://github.com/taviso/cefdebug, allows to find inspectors running locally and inject code into them.
Note that NodeJS RCE exploits won't work if connected to a browser via Chrome DevTools Protocol (you need to check the API to find interesting things to do with it).
RCE in NodeJS Debugger/Inspector
If you came here looking how to get RCE from a XSS in Electron please check this page.
Some common ways to obtain RCE when you can connect to a Node inspector is using something like (looks that this won't work in a connection to 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 security discovered that an application based on CEF registered a custom URI in the system (workspaces://) that received the full URI and then launched the CEF based application with a configuration that was partially constructing from that URI.
It was discovered that the URI parameters where URL decoded and used to launch the CEF basic application, allowing a user to inject the flag --gpu-launcher
in the command line and execute arbitrary things.
So, a payload like:
Will execute a calc.exe.
Overwrite Files
Change the folder where downloaded files are going to be saved and download a file to overwrite frequently used source code of the application with your malicious code.
Webdriver RCE and exfiltration
According to this post: https://medium.com/@knownsec404team/counter-webdriver-from-bot-to-rce-b5bfb309d148 it's possible to obtain RCE and exfiltrate internal pages from theriver.
Post-Exploitation
In a real environment and after compromising a user PC that uses Chrome/Chromium based browser you could launch a Chrome process with the debugging activated and port-forward the debugging port so you can access it. This way you will be able to inspect everything the victim does with Chrome and steal sensitive information.
The stealth way is to terminate every Chrome process and then call something like
References
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking:
HackTricks Training GCP Red Team Expert (GRTE)
Last updated