Although considered a bit less severe than the previous Log4shell vulnerability discovered in late 2021, if successful exploitation does occur, the result is the same. According to Spring, this vulnerability may exist if your environment is hosting a Java application with the following setup:
- Java Development Kit (JDK) 9 or greater
- Apache Tomcat as the Servlet container
- Packaged as a WAR
- spring-webmvc or spring-webflux dependency
The Threat to macOS
The majority of standard Mac users are not going to have any of the above-listed technologies installed, let alone running as public-facing services. Regardless, macOS systems are just as vulnerable to this bug as any other operating system if you happen to be using macOS as a server. This is because the issue lies within the Spring Framework and has nothing to do with the operating system on which it’s running.
From an Endpoint Perspective
The following steps are generally what occurs from the time a Tomcat server is started to the time an attacker takes over.
- Java loads the Tomcat server. From a system process perspective, Java is the Tomcat server. The server will execute any commands that the applications running on Tomcat call.
- The Tomcat server is compromised by the exploit.
- Some damage can be done at this point, however, many attackers will upload a web shell and take control of the server via a web shell.
If a web shell runs a command on a victim Tomcat system, the following low-level activity occurs.
If you want to know more about what’s happening here and why there are so many processes with the same PID, feel free to read about threat hunting on low-level process activity. Otherwise, just know that by the time all of these forks and execs occur, the system is left with the following parent-child relationship.
Ultimately what we need to note here is that any new processes created by the attacker will spawn as a direct child under that Java instance. The bad news is that legitimate calls by Tomcat applications will occur in the exact same manner. This is what makes detecting this activity so complicated. Identifying individual processes that started as good and turned rogue is no trivial task. Trying to identify standout processes is often done by looking at all child processes of the Java process and attempting to identify the anomalies using a security information and event management (SIEM) solution, such as Splunk.
The SuspiciousJavaActivity Detection
macOS systems running Jamf Protect have the option to run an analytic titled SuspiciousJavaActivity. This detection looks for some of the more common attacker commands executed under the Java context after a web compromise. Jamf Protect admins should look at the results closely to determine if the activity is expected or not.
Jamf Products and Spring4Shell
Jamf continues to investigate the impact Spring4Shell has on our products. In the short time since this vulnerability was disclosed, we have not been able to identify a clear path to direct exploitation within Jamf products. We released patches to address the vulnerability on Friday, April 1 to ensure the safety of our customers. More information can be found here on Jamf Nation.