Today I’ll talk about an old-new attack that can affect your production systems: a Zip bomb.
This concept is not new. Following Wikipedia first time Zip Bomb concept was mentioned was in 2001.
TL;DR
The idea of the Zip bomb is very simple. An attacker can create a special version of the Zip file. This special Zip file can’t be really uncompressed and a small zipped file can get even petabytes when the victim tries to uncompress.
As you can imagine, uncompress a file that takes Petabytes of your disk space is not a good business :)
Zip Bomb status
Currently, most zip programs can detect if a Zip file could be a potential Zip bomb, notice the user and prevent the decompression of the bomb:
Ok, this is nice. Then, what’s the problem?
In 2019, security researcher David Fifield was created a new version of Zip Bomb that works nowadays and is very complicate to be detected by programs that manage Zip files.
Zip Bomb and DevSecOps
At this point, you could think about what is the relation between Zip Bomb and DevSecOps. A priori, it sounds more like a hardening problem of the production systems, right? Sorry, but… no.
In the DevSecOps approach, one of the goals is automation and reducing the time to go to production from development. So, this implies that when you create an artefact from source code and progress it to the production stage usually it could (must!) be automatic.
Creating an artefact is not a magical process. Developers must set specific instructions to build it. These instructions will be executed by the C.I. system.
What would happen if a developer includes one step that creates a Zip Bomb and the C.I. system progresses it to production?
Zip files and production systems
Ok. We achieved to progress a Zip file to the production systems. But, why?
A lot of applications use Zip format as a way to package different files and content (For example, Microsoft Word Docx files are Zip files with a different extension).
Many web application servers use this approach too. For example, Apache Tomcat uses .war extension for a Zip packaged Java website.
Following the above example, when Tomcat wants to run a .war file the first step is to uncompress the .war file. At this moment, Tomcat could be vulnerable to Zip Bomb.
Demo — Apache Tomcat against Zip Bomb
For the demo we created a .Zip Bomb file and renamed as .war. This format was automatically deployed by Tomcat when is copied to some specific pre-configured directory.
Preparing scenario
We created a virtual machine using VirtualBox with the Tomcat and opened a console with three monitoring views:
- Disk space console view.
- Memory console view.
- CPU processes usage console view.
As you can see it in the picture:
Deploy Zip Bomb
Once we prepared monitors, we copy the Zip Bomb to the Tomcat directory:
Watching what happens
In the video, time was accelerated. At the top-right corner, you can see the actual time that was elapsed.
Finally, the virtual machine falls down.
Conclusions
We can extract some conclusions:
- Old-fashion attacks can be introduced when you try to automate processes and we want to remove manual checks.
- Fail fast is the goal in DevOps, and we must follow the same rules for DevSecOps. Some attacks traditionally considered that should be solved at hardening time could be complemented with a good security pipeline process.
- We must check building files and commands that create the resulting artifacts. Not only the source application code.
More posts about DevSecOps series
Previous post: DevSecOps series No 2 — Automatic checking Dockerfiles for security
Next post: DevSecOps series No 4 — Protecting environment variables in the most well-known C.I. systems
