Apache Spark

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.

github.com

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.

ngrok.com

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.

Continue…