During code reviews we often see developers using weak RNGs like math.random() to generate cryptographic secrets. We think it is commonly known that weak random number generators (RNG) must not be used for any kind of secret and recommend using secure alternatives. I explicitly did not state a specific language yet, because basically every language offers both weak and strong RNGs.
So I asked myself: What if I use a weak RNG to generate a secret? Is it possible to recover the secret from some derived value, like a hash?
It is possible to spoof the URLs that Plume will open to arbitrary locations because of how Plume parses URLs. The preview of an URL in a tweet will show the complete (at least the host name and the first few chars of the URL) but shortened URL. However, if the URL contains a semicolon (;) the URL that will be opened is the part after the semicolon. Continue reading “Plume Twitter Client URL Spoofing”
Generally speaking, I’m more of a Cat type of guy, but I have to say I really love BloodHound. And if you do too, you are in for a treat…
Last week, the ERNW Insight Active Directory Security Summit took place in Heidelberg. (More Info)
For this occasion, @Enno_Insinuator asked me if I would like to deliver a BloodHound Workshop, and of course I accepted the challenge…
Lately, I’ve experienced some weird Pidgin crashes when I was copy&pasting into chat windows. The strange part was: I didn’t even know what triggered the crash because I actually didn’t know what was in my clipboard at this exact point. This is a quick write-up of how I investigated the issue and some interesting properties I found out about clipboards.
This is a write-up about how to use Frida to dump documents from a process after they have been loaded and decrypted. It’s a generic and very effective approach demonstrated on a piece of software from North Korea.
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”