An unauthenticated Apache Spark instance is almost too good to be true for exploitation. There was a recent CVE (CVE-2022-33891) against Apache Spark that allowed for remote code execution if a certain configuration was set.
You report to your team lead that you intend to test for this vulnerability by injecting a few URL parameters into the page.
http://dmz.risottocorp.lan:8082/?doAs=`sleep 10`
You execute the tests.
![image](https://assets.super.so/0b5aa6c6-a96a-4739-9e6a-96b6a9f9c9b8/images/b414e7b1-7358-43f4-8eea-9579adf74d6e/sparkcve.gif?w=1317)
It works! You’re ecstatic that you’ve identified a potential initial access vector for your team. You look for an exploit proof of concept and find the following:
The web server will not be able to connect directly to your Kali teamserver because you’re behind your NATted public IP address. To catch a reverse shell, you’ll need something like Ngrok:
In haste, you download the Ngrok client and set up a TCP listener that is open to the internet. You perform the exploitation and inject a TCP reverse shell into the page:
You have a hit! You quickly pivot this code execution into access to the environment and begin working on post-exploitation. Things are looking great for this engagement.
Well, that is, until you get a call from the RisottoCorp trusted agent a few hours later.
Uh oh.