Have you been compromised by the Apache Log4j vulnerability?

The simple truth is you might not even know if you have been compromised by the recently disclosed Log4j vulnerability. Java is at the heart of your everyday life. I’m not talking about coffee, but rather the programming language from circa 1996. You will find it in use from Cloud Providers to Mac and Windows apps, and even your cable box at home (if you haven’t yet cut the cord). Even if you don’t have Java installed, the odds are pretty good it’s bundled with another piece of software on your devices and the infrastructure it connects into. The most common logging package in use across pretty much every Java application is Log4j. Here entails the problem; this means there has been, and will continue to be, an enormous attack vector just about everywhere there is a computing device and the infrastructure to support it.

This is not just specific to cloud computing environments, but rather everywhere there is a device with internet access. The good news is that there are patches readily available. The bad news is that it will take time to update the Log4j package across all the places it exits. What’s worse is an overwhelming majority of legacy software and devices are likely to never receive an update.

How the exploit works

The Log4j vulnerability is what’s called a remote code injection vulnerability. A specially crafted Java Naming and Directory Interface (JNDI) request is sent to a vulnerable server.  Think of JNDI as a series of lookups either to find IP addresses (DNS or RMI) that go with a resource name or authentication (LDAP). As Log4j is a well-known library with a standard format for calling DNS, RMI or LDAP, the sophistication to craft a malicious request is low. The server takes that request, reaches out to an external service for DNS, RMI, LDAP, and then the code is injected for the server to execute. This allows the attacker to run malicious code, exfiltrate data, and exploit additional vulnerabilities that may be present on the target server. For more detailed technical information, please see our vulnerability assessment brief.

Why should you care?

No software is ever 100% ironclad secure. There will always be known and yet to be known vulnerabilities that exist. In both cases, having a proper security strategy with multiple layers, i.e., defense in depth, is key. With Aviatrix, you get another layer of the onion that bad actors need to peel back. Since Aviatrix allows you to own your cloud networking data plane, it is very difficult for bad actors to hide their intentions.

Detection and mitigation with ThreatIQ and ThreatGuard

The great news for Aviatrix customers is they already have detection and remediation capabilities with Aviatrix ThreatIQ and ThreatGuard. ThreatIQ inspects all traffic flows throughout your cloud architecture, whether it’s one cloud with one region or many clouds with many regions. Traffic sources and destinations are continually compared against known malicious IPs on the Internet.

Once ThreatIQ has detected a malicious traffic flow, ThreatGuard can both alert and proactively block traffic to/from a detected malicious IP address. There is no additional work to have protection against active exploitation from the Log4j vulnerability and other zero-day vulnerabilities that the security industry doesn’t even have insight into today.

Creating a report to detect exploitation attempts

Aviatrix CoPilot has visibility into all traffic flow data across your networking. This allows you to filter your network traffic to find the ports used by the Log4j exploit that are connecting externally to your network.

In the following example, we can configure a search for all the vulnerable ports that are communicating with public IP addresses. This can of be modified to a subnet of the ports as well.

The results help you team to then analyze the traffic and determine if the connections are legitimate or require quarantine.  To automate the detection and notification malicious IP activity occurring within your cloud network, you just need to configure ThreatGuard by providing the destination you wish to receive alerts.  The report destinations can be an email or webhook, as show in the screenshot below.

Conclusion

The Internet will remain a scary place. Humans write code and they are not perfect. Ergo the code is not perfect. There are controls and mitigations that can be put in place to effectively detect the symptoms of exploitation. Aviatrix customers can rest easier at night knowing that their cloud infrastructure is actively monitoring for malicious activity, such as the Log4j vulnerability. If you would like to learn more about how Aviatrix can help with networking security in your environment, please contact us!

About the authors