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.
You execute the tests.
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:
GitHub - HuskyHacks/cve-2022-33891: Apache Spark Shell Command Injection Vulnerability
Apache Spark Shell Command Injection Vulnerability A Python POC for exploiting the Apache Spark Shell Command Injection vulnerability. I saw some other POCs out there but they looked mega sus. This one is clean and simple. I did not discover this exploit/vulnerability.
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:
ngrok - Online in One Line
ngrok's edge is your competitive edge. Scale your services with global network acceleration and k8s-style load balancing. Instantly add zero trust SSO, WAF, mTLS, failover + more to any app with no code.
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.