Protecting microservices against Log4shell and beyond
Introduction
In December it was Log4shell that captured everyone’s attention. Earlier in the year it was the SolarWinds Supply Chain attack. In addition, every public facing API or Service and even internal is now under constant surveillance and DDOS attacks by attackers looking for vulnerable points of attack some of which are not even known.
In this kind of a scenario, it makes even more strategic sense to ensure that the smallest unit of workload in your deployment, the micro-service, be deployed in such a way that it should be prevented from infecting other systems in the deployment.
Following is an infographic of the various recommended steps to disable it manually and prevent the attack from spreading.
But this is just applying band-aid on an already strained enterprise system and a precursor for future such other vulnerabilities that can explode and affect the entire network.
Polyglot services, frameworks, Supply chain (BOM) issues
As the world moves head-on towards cloud, highly distributed micro-services, and polyglot software with the supply chain Bill of Materials (BOM) consisting of an almost infinite number of Open-source software packages and dependencies, it becomes almost impossible to track which micro-service uses which dependency and to track vulnerabilities and weaknesses in each one of them, and taking into account which versions have which vulnerabilities and weakness.
Micro service sprawl/Inventory problems with out of date CMDBs and processes
Micro services in an enterprise and cloud are now very highly distributed geographically and spread across hundreds if not thousands of servers. Keeping an inventory of services across geographies, Data centers, clusters, servers, hosts, clusters can be a really daunting task and these problems quickly escalate during crises.
Subcontracting shops in charge of “Managed” services
To be able to focus on the critical business problems and to expand and contract their workforce on demand, large scale Enterprises delegate a lot of critical services to Contracting services who in turn hire Subcontractors from across the world to manage critical services.
Keeping track of who deploys what, where, when and how is another task that becomes an Operational nightmare very fast during a crisis.
Perils of relying on just Inventory and Updating, Patching, Rollouts
Without a perfectly updated inventory and software update/delivery system, it would be very difficult and unreliable to patch and update every version of every library in every micro service. There are also maintenance windows, processes, downtime, and business processes getting affected that make the rollout more and more difficult.
Business Processes getting affected
Ultimately, a vast majority your business processes which are effectively now codified in software systems get affected, thus possibly affecting the bottom line. This can have the implication to escalate a vulnerability into an all out crisis.
“Crisis” Management, in reality, services are “always” under attack
All of the above issues and processes come to the forefront during a crisis like the Log4shell attack and SolarWinds Supply Chain attacks, but in reality, there are automated attacks running 24/7 and 365 days a year.
Protecting the microservice: the smallest unit of the distributed computing workload
In effect, given the immense complexity of microservice sprawl management, we need to buy time to execute on our processes effectively while still running our critical business processes and not scrambling.
This requires a little bit more thought on how we package and run a microservice.
In this brave new world of immensely distributed microservices across the cloud, multiple geographically located datacenters, clusters, edge clusters, we need to revisit the smallest independent unit of computing in microservices:
“The Application Container”
We need a new type of container that can effectively prevent or at the least mitigate these types of exploits from “infecting” and spreading across the network.
When these exploits do occur, we need to be able to buy time to execute on our internal management processes to mitigate exploits.
Built from scratch for micro services and functions -Kontain
Kontain was built from the ground up to prepare for just such a future of micro services. It was built to be an extremely lightweight and fast veneer of just the necessary system code to run your application, and shed all unnecessary vestiges of functionality but at the same time provide a VM-level strong isolation of the application.
Kontain offers an almost zero attack surface and thus reduces the overall blast radius, thus helping prevent the vulnerability from spreading and infecting other parts of the network.
Kontain also offers strong VM-level isolation combined with higher performance and lower footprint than regular Linux containers.
Kontain also leverages Docker packaging, Docker registries and can be deployed in Kubernetes just like regular Docker/Linux Containers but with additional advantages.
Each micro service that is exposed via an API or a network accessible endpoint should be considered vulnerable and should thus be wrapped with protection built in, so that such threats from any one of them is “Kontained” but at the same time does not compromise on the performance and efficiency benefits of Containers compared to VMs.
The Log4shell demo revisited
In the last post, we did an initial study in detail of the Log4shell attack on a Spring Boot Application and how it could be “contained” by using Containers built with “Kontain” rather than traditional Docker/Linux Containers but using the same Docker and Kubernetes packaging and deployment tools.
Kontain wraps the Spring Boot micro service as a deployable Container but with ironclad VM-level protection and isolation.
Below we revisit the Log4shell demo and also give a little more detail to highlight how Kontain can help micro services be more secure.
The Log4shell attack Demo without “Kontain”
Below we show a video of the Log4shell attack on a Spring Boot Application wrapped in a normal Docker container containing the vulnerable Log4J library.
The Log4shell attack demo with “Kontain”
Below we show a video of the same Log4shell attack on exactly the same Spring Boot Application but wrapped in a “Kontain” container using the same tooling.
You can see that the malicious JNDI string got logged and the malicious LDAP server was contacted but the attack could not continue because there was no literally no attack surface, hence effectively “kontaining” the exploit and preventing the spread to other components.
More details on the Log4shell attack demo
Below is a diagram illustrating the Log4shell attack:
And below is another diagram illustrating the attack on the same exact Spring Boot Application but being “kontained” due to its almost zero attack surface and thus effectively containing the blast radius of the exploit.
Using the Log4shell demo code
To use the Log4shell demo code you clone the code from:
And then:
$ git clone https://github.com/kontainapp/km-demo.git# switch to the log4j folder
$ cd km-demo/log4j
$ git checkout -b sm/demo_log4jshell$ make demo# and then follow along as shown in the video(s) to set up your 5 terminals to try out demo1 and demo2
Pre-requisite: Please note you will need to have Kontain installed in your recent Linux (Fedora or Ubuntu computer) using the instructions from here:
Or by following the Video tutorial from here:
You can also view to Kontain Monitor at:
Conclusion
In this post, we saw how Kontain can provide a more modern, secure, container for microservices while at the same time working with existing CI/CD, Docker and Kubernetes tools and not requiring any change in application code.
