Containerization dominates the market nowadays. Fancy buzzwords like continuous integration/deployment/delivery, microservices, containers, DevOps are floating around, but what do they mean? What benefits do they offer compared to the old dogmas? You’re gonna find out in our training!
We are going to start with the basics of Docker, Containers and DevOps, but soon you’ll end up with your own applications running inside containers with the images residing in your own registry. Of course, following the microservices approach, and the second day hasn’t even started.After the fundamental topics of containerization are understood, you’re going to create and operate your own Kubernetes cluster. A lot of fun and challenging exercises lie ahead, to give you hands-on experience with all the technologies.
We at ERNW have not only security written on our banner, it is a mindset we share. Therefore, be prepared to get knee deep into security in regards of the discussed technologies. We will tackle the security aspects from the bottom-up, what Containerization tools can offer and how all these can be enforced and enhanced with Kubernetes to secure your clusters. From there on you are ready for the final challenge. You will jump into the role of an attacker who did compromise a Container in the cluster and escalate your privileges to Cluster Admin.
Attendees who absolved the training will have a solid understanding of container technology, especially with Docker and Kubernetes and of course the security challenges those technologies bring to the table.
So, if you’re up to a challenging training and want to get not only your feet wet with Docker and Kubernetes, you can reserve your spot for the training right here.
I was at the hack.lu conference in Luxembourg this year and attended the fuzzing workshop, held by René Freingruber from SEC Consult. I have been curious about this topic for some years now, but besides doing some manual fuzzing and web-fuzzing, I never looked into the whole topic that much.
The workshop lasted for around four hours. Before the workshop started each student got two VMs (Linux/Windows) where everything necessary was already set up. The VMs included 23 exercises, with step-by-step explanations, source code and exploits. René started out with an introduction to fuzzing, listing popular fuzzers and showing an example on how to fuzz with afl.
Thereafter he explained the whole process of file format fuzzing, in a clear and easily adoptable manner. Examples were shown for Linux and Windows. The differences and difficulties as for fuzzing on Windows were explained. It was also shown how to find exploitable vulnerabilities from the previously acquired crashes.
After a short break René introduced DynamRIO and PIN. Both tools are used for dynamic instrumentation. Two demos of the tools were shown, followed by a real-world example where he fuzzed mimikatz, the all beloved password recovery tool. To avoid running mimikatz on the compromised host, one can just dump the process memory of lsass.exe and load it into mimikatz to get credentials. Any idea where this is heading? Exactly, file format fuzzing!
Mimikatz EIP control
eip=41414141, looks like IP control to me ;D. A detailed writeup can be found over here.
The rest of the workshop René explained and discussed the areas which influence the fuzzing results. These can be divided into mutators, detection rate, input filesize and fuzzer speed. Instead of going into much detail myself I will just refer to his slides, which cover the topic way better than if I try to break it down in a few sentences.
René showed a lot of practical examples, although unfortunately there was not enough time to finish all of them while attending the workshop. Quite some time was spent on how to speed up the whole fuzzing process. Still I think it would be nice if more time could be spent on the practical examples.
The first exercise to introduce fuzzing and afl had the following source code. This code was then compiled with afl-gcc to add the instrumentation code with the following command: afl-gcc -o main_afl main.c
Additionally, input file(s) are needed, which in this case were created with the following command: python -c ‘print “\x00″*100’ > inputs/input
Then the fuzzer can be started with the following command: afl-fuzz -i inputs -o output — ./main_afl @@
The -i flag specifies a directory where the input files are located and the -o flag specifies a directory where the crash files should be stored. Now afl will run and fuzz the binary. For fuzzing a “real” (instrumented) binary, one would go through the following process:
Generate input files or download them.
Instrument the source code (if possible)
Remove input files with same functionality
Reduce file size of input files.
Start fuzzing
Removing the input files which trigger the same functionality is done before reducing their file size. One might guess, that this should be done the other way around, but reducing the file size can take a long time and should therefore be executed on the reduced file set.
To summarize the overall workshop:
I got a good understanding of the topic, what tools to use and how the process of fuzzing works.
The workshop could easily have been a three days workshop.
The students got awesome resources to start out their fuzzing journey, the slides are very good as are the VMs/demos.
So, I finally started to fuzz some binaries and have great fun doing so! Thanks very much for the workshop, René.
