Kubernetes Network Policy or Blocking External Traffic will Slightly Reduce log4j Attack, not…

Kubernetes Network Policy or Blocking External Traffic will Slightly Reduce log4shell Attack, not Avoid it

If you have been sleeping under a rock, and are unaware of the latest application vulnerability in the Apache product log4j, you should read up on it.

Anywho, I started seeing people posting about using Kubernetes network policies to mitigate the log4shell attack. I can’t stress how much that will NOT mitigate (avoid) the attack. It was also a bit confusing coming from some big container companies and more confusing because they didn’t specify the mitigation type. Let me explain how Kubernetes network policies will not mitigate (avoid) this vulnerability. Furthermore, blocking external egress from your applications is not only unrealistic for many but also doesn’t mitigate (avoid) the issue… only slightly reduces it.

Types of Mitigation

We first need to understand what mitigation is. There are four things you can do to mitigate risk. You can Accept, Avoid, Transfer, or Reduce. After reading this article, you will hopefully see how it doesn’t Avoid (remove the risk), and it only provides some reduction in risk. You can make an attack more difficult, but don’t underestimate the creativity of attackers.

Network Policies

Kubernetes network policies work at the network layer to control IP, port, and protocol traffic. For the protocol, it only really supports TCP, UDP, and SCTP. If you’re looking to control protocols other than those, well, you’re out of luck with network policies. If you think that’s all you need to control network traffic (with modern attacks), then I think you should review your protocols as that doesn’t include HTTP(S). This also requires that the Container Network Interface you’re using in Kubernetes support network policies.

For example, let's say your application uses log4j to log login requests. Well, that’s going to come in over HTTPS– hopefully. If an attacker were to place the attack string in the username field, because you should hopefully not be logging the password field, then you’ve just been exploited. While you can block all HTTP traffic, as it uses TCP for sending/receiving requests, you can’t see the HTTP protocol traffic with Kubernetes network policies.

What You Can Do With Network Policies

With network policies, you can control the egress of network traffic. I know you can control the incoming network traffic, but without the ability to control based on the payload, it is useless in this case. Attackers are sending their attack string to a vulnerable application and having that application reach out to an external source to download a Java Class and execute it. The Kubernetes network policy could be helpful in this case as it would stop the external communication to grab the attacker’s Java Class. Just block egress traffic by specifying the IP, protocol, and port you want– it’s an allow list.

Now, with all of that said, how realistic is this? Not very. Why? Well, let’s say you have a public web server that communicates with the Public Internet. How are you going to control the egress for your front-end web application that uses log4j? Are you going to really start telling your front-end web application who to communicate with? No, because that would be impossible to control, you can’t maintain a list of trusted IPs. Now, a REAL security tool (not Kubernetes network policies) would allow you to control the network state. For example; allow all incoming network traffic, egress traffic only to specific IPs, and established. What that would do is allow external visitors to come into the application, the application to reach out to IPs you specify for internal communications and respond to all external established requests. What it would also do is not allow new connections to be opened leaving the application that you didn’t specify– the attacker’s Java Class. But, the Kubernetes network policy doesn’t let you control the network state, it’s a pretty dumb firewall (stateless).

The Real Danger

So, you stopped external communications grabbing the attacker’s Java Class, does that mean you’ve mitigated (avoid) the vulnerability? No, why? Well, you obviously didn’t read up on the attack ;-). You see, the vulnerability is an RCE (Remote Code Execution). As I said before, a lot of the attacks are being done with an external Java Class. However, what if the attacker used a local Java Class? Well, now you’re back in the same boat, somewhat.

While the local option is a bit more complicated to pull off, as you’d need to know what Java Classes were available, a more realistic option would be to find an intranet attack method. Most people refuse to control outgoing requests. As someone who worked in cybersecurity for years, I can attest. Developers and operations folk will fight you if you’re trying to control what internal traffic applications can use. They want ingress control or external egress control, not internal egress control. So if an attacker can add their Java Class to an internal system, then they will be much better off.

Let’s make this even more realistic for those that just block external traffic. What if you have an attacker with a small foothold into your organization or a low-level malicious employee. If you have only stopped external traffic, how has this reduced the attack for them? An attacker with a slight foothold into the network could easily spin up netcat on a system (listening on a non-privileged port), send traffic to a vulnerable application, and start extracting variables (sensitive information) or simply send their attack code that way. Again, how have you reduced the attack?

Real Avoidance or Reduction

So, what can you do? The real answer is to patch the vulnerability, sorry, but that’s the real fix. No amount of band-aids will stop your amputated arm from bleeding, just slightly. What if you can’t? Well, then that’s where application firewalls come into play. Trust me, I’ve been there. A DOS vulnerability existed in a vendor SAN, sending too many packets to the SAN (management port) would cause it to crash and reboot. So, we had to place the port on a separate security level in our ASA firewall until the vendor patched the vulnerability. Yes, it was only accessible over our IT management VLAN. However, it was discovered because of a broadcast storm (yeah bad network engineer mistake), so it obviously needed more protection. You will need to use a security solution that can inspect the traffic coming to the application to determine if it’s an attack or not before sending it to the application.