If a conference feels like a great vacation, then the organizers are doing it absolutely right! Hack.lu took place for the 14th time in Luxembourg. From the 16th – 18th October, the Alvisse Parc Hotel hosted the Hack.lu conference. Those three days were full of talks, workshops and “discussions about computer security, privacy, information technology and its cultural/technical implication on society“. Some members of the ERNW crew had the chance to attend Hack.lu this year and we all enjoyed it a lot!
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!
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.
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é.
Matthias and I had the pleasure to give a talk at the H2HC2018 in São Paulo, Brazil about attacking VMware NSX. The talk is an introduction to VMware NSX for security researchers, and it discusses possible attack vectors including the management, controlling, and data exchange planes. We demonstrated how to prepare a fuzzing and debugging setup for the ESXi kernel and the kernel modules. It should be noted that Olli was also supporting the research. Continue reading “H2HC2018 – Attacking VMware NSX”
First day at hack.lu. Three of us kicked the conference off with the ARM IoT Firmware Emulation workshop by Saumil. The goal of this workshop was not so much to write exploits or to pwn boxes but to learn how to build a beneficial research environment by emulating the hardware of a Linux based IoT device to run its firmware in order to run analysis and tests.
At this years ARES conference, Jonas Plum (Siemens) and me (Andreas Dewald, ERNW Research GmbH) published a paper about the forensic analysis of APFS, file system internals and presented different methodologies for file recovery. We also publicly released a tool implementing our presented approaches, called afro (APFS file recovery).
We recently identified security issues in the UNIFY OpenScape Desk Phone CP600 HFA software. We disclosed the vulnerabilities to Unify, as a fix is now provided we want to give a brief overview of the vulnerability affecting the web interface.
Inspiriert durch die erfolgreichen Round-Table-Diskussionen der Troopers-Konferenz freuen wir uns, Ihnen heute mit dem Incident Analysis and Digital Forensics Summit 2018, eine weitere Veranstaltung in einer Reihe zu Trend-Themen im Bereich der IT-Sicherheit vorzustellen.
For those who never heard of Sitefinity before, it is an ASP.NET-based Web Content Management System (WCMS), which is used to deploy and manage applications as other CMS‘s do. A bitter quick glance at Sitefinity and its advantages can be found in this overview.
Delving into the core of this blog post, recently I had the opportunity to look at Sitefinity WCMS in which I found two reflectedCross Site Scripting (XSS) (CVE-2018-17053 and CVE-2018-17056), a stored XSS (CVE-2018-17054) and an arbitrary file upload (CVE-2018-17055) vulnerabilities.
Recently, I had some time to play around with HEVD , an extremly vulnerable Windows driver available for 32-bit and 64-bit systems.
Since exploits for all vulnerabilities of the 32-bit variant are publically available, I was wondering why this is not the case for the 64-bit version, especially for the pool corruption and UAF vulnerabilities.