By Billy Downing, Sterling Cloud Architect
Make sure to read Part 1 of this blog.
NSX-T Distributed Security Detecting Log4j Attacks
As we discussed previously, there are tremendous benefits to not only defining network policy in software and shifting complexity to centralized controllers for a single point of management, but also to implementing a distributed data-plane security model in our infrastructure via the network. To prove that point, we can walk through the detection of a log4j attack, which occurs between two virtual machines coexisting on the same subnet. This is a difficult task to accomplish for most traditional security appliances, as their point of inspecting typically lives at the layer 3 boundary, which protects traffic flows from subnet to subnet but does nothing to prevent attacks occurring within each subnet itself.
In this scenario, as pictured in Figure 1, we have two virtual machines on the same subnet.
The attacker is 10.50.0.101 and the victim 10.50.0.103.
The victim will be running a container with a vulnerable web application, as provided by this log4j-test-suite* found on GitHub, exposing the http service through tcp port 8080, as shown in Figure 2.
Now that we have an exploit available on our network, we can use that same log4j-testing-suite* to execute an attack. Shown in Figure 3, the attacker machine is running malicious software used to generate the string needed to exploit the log4 vulnerability on our victim machine.
Our next step is to access the victim web application and send out string through the login prompts to execute our attack, as shown in Figure 4, and shown as a normal curl command in Figure 5.
Figure 5
What we’re attempting to do, with the malicious string of text, is force the vulnerable application to redirect access back to our attacker. Meanwhile, as shown in Figure 6, our attacker machine is listening on any connection to port 9001 from our victim. Once executed, the vulnerable code allows our attacker machine to establish a root connection in the container running the web application. Again, in Figure 6, we see a connection come in from the vulnerable machine, 10.50.0.103, and allow us to run a few commands such as whoami (root), pwd to see where we sit in the directory, and to check out the IP address of the container itself.
To summarize, we have successfully exploited the log4j vulnerability to gain root access of a victim machine where both virtual machines were running on the same subnet, same logical segment, and potentially, the same host. Typically, in this scenario, traffic does not even leave the esxi host, and without some sort of traffic injection, would never be seen by any centralized security appliance. However, since we’re using NSX-T and, as such, a distributed security data plane to enforce policy, we have visibility all the way down — directly to the virtual machine vmnic itself. As shown in Figure 7, we can see that NSX-T was able to pick up the exploit and log it for tracking. In this case, I have the policy set to only create an alert for critical exploit signatures, rather than to alert and prevent.
Looking deeper into our insights, we can expand the exploit detection and inspect each traffic flow that triggered it. In Figure 8, we can see the entire history for the context of the intrusion-detection event. Looking through, we see this is a detection on the distributed policy engine impacting virtual machines that NSX-T knows the names of (attacker/victim). We also see the specific rule in our policy that matches the source and destination traffic we wanted to inspect, and the profile containing the signature that matches our exploit.
Finally, now that we know this attack is occurring, we can take manual or automated steps to mitigate any potential loss of data or to prevent future exploits from taking place.
We can’t protect something if we don’t have insight into it. By using NSX-T, with its distributed data plane inspecting traffic closest to the workload, we’re afforded that critical insight.
Overall, demonstrating how NSX-T can be used to detect and subsequently prevent attacks based on malicious signatures in a distributed manner spotlights how important it is that security is directly embedded in our environment’s core services, and how NSX-T can add essential layers to our overall security posture.
Sterling focuses on a security-first approach to ensure the appropriate posture is considered as early as possible in the design process for any architecture. We can provide demonstrations, workshops, or assessments based on your intended outcome incorporated with whatever constraints or requirements you may be facing.
*Source for log4j testing suite: https://github.com/kozmer/log4j-shell-poc