Events

Hack.lu 2018: Fuzzing Workshop by René Freingruber

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:

  1. Generate input files or download them.
  2. Instrument the source code (if possible)
  3. Remove input files with same functionality
  4. Reduce file size of input files.
  5. 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é.

Cheers, Simon


Slides and demos can be found here.

Continue reading
Events

TR17 Training: Fuzzing with American Fuzzy Lop, Address Sanitizer and LibFuzzer

This is a guest blog written by Hanno Böck who will be running the Fuzzing with American Fuzzy Lop, Address Sanitizer and LibFuzzer at TROOPERS17.

Fuzzing is a very old technique to find bugs and vulnerabilities in software. However it has seen a new push in recent years due to vastly improved tools. The compilers gcc and clang have received Sanitizer tools that allow finding a lot of bugs like use after free errors and out of bounds reads that are otherwise very hard to find.

Continue reading “TR17 Training: Fuzzing with American Fuzzy Lop, Address Sanitizer and LibFuzzer”

Continue reading
Events

Hackito Ergo Sum 2014

Greetings from Heidelberg to Paris,

and thanks for a great time at HES14! A nice venue (a museum), sweet talks and stacks of spirit carried us through the three day con. It all set off with a keynote byTROOPERs veteran Edmond ‘bigezy’ Rogers, who stuck to a quite simple principle: “People do stupid things” and I guess every single one of you has quite a few examples for that on offer. Next to every speaker referenced that statement at some point during her/his talk. Furthermore we presented an updated version of our talk LTE vs. Darwin, covering our research of security in LTE networks and potential upcoming problems.

For those who missed HES2014, we prepared a short summary of some of the talks that inspired us.

Continue reading “Hackito Ergo Sum 2014”

Continue reading
Events

LTE@ShmooCon, a Summary

Hey guys,
as some of you may have noticed, just recently at ShmooCon we gave our talk “LTE vs. Darwin” (Slides here). There we presented some results of our research in 4G telco network security. Some of those originate from our research contribution to ASMONIA, but we expanded the scope and also took a look at the air interface. Both the air interface and the backend links & protocols must be secured appropriately; otherwise communication may be eavesdropped or sensitive information may be compromised. In the following we want to provide an overview of LTE main components and potential attack vectors.
Continue reading “LTE@ShmooCon, a Summary”

Continue reading
Breaking

Fuzzing VMDK files

As announced at last week’s #HITB2012AMS, I’ll describe the fuzzing steps which were performed during our initial research. The very first step was the definition of the interfaces we wanted to test. We decided to go with the plain text VMDK file, as this is the main virtual disk description file and in most deployment scenarios user controlled, and the data part of a special kind of VMDK files, the Host Sparse Extends.

The used fuzzing toolkit is dizzy which just got an update last week (which brings you guys closer to trunk state 😉 ).

The main VMDK file goes straight forward, fuzzing wise. Here is a short sample file:

# Disk DescriptorFile
version=1
encoding="UTF-8"
CID=fffffffe
parentCID=ffffffff
isNativeSnapshot="no"
createType="vmfs"
# Extent description
RW 40960 VMFS "ts_2vmdk-flat.vmdk"
# The Disk Data Base
#DDB
ddb.virtualHWVersion = "8"
ddb.longContentID = "c818e173248456a9f5d83051fffffffe"
ddb.uuid = "60 00 C2 94 23 7b c1 41-51 76 b2 79 23 b5 3c 93"
ddb.geometry.cylinders = "20"
ddb.geometry.heads = "64"
ddb.geometry.sectors = "32"
ddb.adapterType = "buslogic"

 

As one can easily see the file is plain text and is based upon a name=value syntax. So a fuzzing script for this file would look something link this:

name = "vmdkfile"
objects = [
    field("descr_comment", None, "# Disk DescriptorFile\n", none),

    field("version_str", None, "version=", none),
    field("version", None, "1", std),
    field("version_br", None, "\n", none),

    field("encoding_str", None, "encoding=", none),
    field("encoding", None, '"UTF-8"', std),
    field("encoding_br", None, "\n", none),
    [...]
    ]
functions = []

 

The first field, descr_comment, and the second field, version_str,  are plain static, as defined by the last parameter, so they wont get mutated. The first actual fuzzed string is the version field, which got a default value of the string 1 and will be mutated with all strings in your fuzz library.

As the attentive reader might have noticed, this is just the first attempt, as there is one but special inconsistency in the example file above: The quoting. Some values are Quoted, some are not. A good fuzzing script would try to play with exactly this inconsistency. Is it possible to set version to a string? Could one set the encoding to an integer value?

The second file we tried to fuzz was the Host Sparse Extend, a data file which is not plain data as the Flat Extends, but got a binary file header. This header is parsed by the ESX host and, as included in the data file, might be user defined. The definition from VMware is the following:

typedef struct COWDisk_Header {
    uint32 magicNumber;
    uint32 version;
    uint32 flags;
    uint32 numSectors;
    uint32 grainSize;
    uint32 gdOffset;
    uint32 numGDEntries;
    uint32 freeSector;
    union {
        struct {
            uint32 cylinders;
            uint32 heads;
            uint32 sectors;
        } root;
        struct {
            char parentFileName[COWDISK_MAX_PARENT_FILELEN];
            uint32 parentGeneration;
        } child;
    } u;
    uint32 generation;
    char name[COWDISK_MAX_NAME_LEN];
    char description[COWDISK_MAX_DESC_LEN];
    uint32 savedGeneration;
    char reserved[8];
    uint32 uncleanShutdown;
    char padding[396];
} COWDisk_Header;

 

Interesting header fields are all C strings (think about NULL termination) and of course the gdOffset in combination with numSectors and grainSize, as manipulating this values could lead the ESX host to access data outside of the user deployed data file.

So far so good, after writing the fuzzing scripts one needs to create a lot of VMDK files. This was done using dizzy:

./dizzy.py -o file -d /tmp/vmdkfuzzing.vmdk -w 0 vmdkfile.dizz

 

Last but not least we needed to automate the deployment of the generated VMDK files. This was done with a simple shell script on the ESX host, using vim-cmd, a command line tool to administrate virtual machines.

By now the main fuzzing is still running in our lab, so no big results on that front, yet. Feel free to use the provided fuzzing scripts in your own lab. Find the two fuzzing scripts here and here. We will share more results, when the fuzzing is finished.

Have a nice day and start fuzzing 😉

Daniel and Pascal

Continue reading
Breaking

Releasing dizzy version 0.6

Hi @all,
today im releasing a new version of our famous fuzzing framework, dizzy. The version counts 0.6 by now and youll get some brand new features!

see the CHANGELOG:
v0.6:
– ssl support
– server side fuzzing mode
– command output
– new dizz funktions: lambda_length, csum, lambda_csum, lambda2_csum
– recursive mutation mode
– new dizz objects: fill
– new interaction objects: null_dizz
– reconnect option
– additional fuzzing values

find the sources here (90397f9ec11c8ec3db7f14cb4d38dd39e30f9791)

cheers

/daniel

Continue reading
Breaking

Week of releases – dizzy

I’m proud to announce, today a new fuzzing framework will see the light of day. It’s called dizzy and was written because the tools we used for fuzzing in past didn’t match our requirements. Some (unique) features are:

  • Python based
  • Fast!
  • Can send to L2 as well as to upper layers (TCP/UDP/SCTP)
  • Ability to work with odd length packet fields (no need to match byte borders, so even single flags or 7bit long fields can be represented and fuzzed)
  • Very easy protocol definition syntax
  • Ability to do multi packet state-full fuzzing with the ability to use received target data in response.

We already had a lot of success using it, now you will be able to know the true promises.

Find the source here (c715a7ba894b44497b98659242fce52128696a17).

/daniel

Continue reading
Breaking

update for your fuzzing toolkit

As I’m currently developing the ‘next gen’ state-full fuzzing framework @ERNW [called dizzy, to be released soon 😉 ], I will give you an updated set of fuzzing scripts from the ‘old world’.

Some of you will remember the 2008 release of sulley_l2, which was a modified version of the sulley fuzzing framework, enhanced with Layer 2 sending capabilities and a hole bunch of (L2) fuzzing scripts. All the blinking, rebooting, mem-corrupting ciscos gave us some attention. Back from then, we continued to write and use the fuzzing scripts, so the hole collection grew.

Find the latest version of the tool-set here.

If you take a look inside the ‘audits’ folder, you will find all the ERNW made fuzzing scripts. I’ll give you a short description on the most of them:

  • ARP – This are some basic ARP fuzzing scripts, mainly as reference L2 implementation, haven’t found anything interesting with them, yet.
  • BGP – Some scripts for the basic BGP packet types, has nothing to do with Layer2 but will kill some devices 😉
  • CAPWAP – Within our wireless research we also did some wireless mgmt-protocol fuzzing and came up with this scripts. (RFC5415)
  • CDP – Fuzzing scripts for Cisco’s discovery protocol. Most fun is gone here, as bugs were submitted and fixed by the time.
  • DOT1Q – One of the first L2 fuzzing scripts, building a tagged packet.
  • DTP – Fuzzing scripts for Cisco’s dynamic trunking protocol. Thats the one which make Ciscos blink like Christmas-Trees.
  • EXTREME – A hand full of scripts targeting Extreme’s  discovery protocol, those will create purple stack traces 😉
  • GTP – In the 3G / 4G research we did some GPRS tunneling protocol fuzzing, not finished yet.
  • IP – Also more a reference implementation.
  • ISL – As to be complete with the Vlan tagging there is also a script for Cisco’s ISL.
  • LLDP – Those scripts won’t work as expected, if you know why, drop me a mail, you will get dizzy first 😀
  • LWAPP – Also output from the wireless research, by that time this one randomly reboots access points.
  • OSPF – A script for fuzzing OSPF HELO packets, wont get any further, as sulley knows no state.
  • PNRP – Simon’s awesome PNRP fuzzing scripts.
  • PVST – Spanning Tree in a few flavors, if you ever need even more of that packets 😉
  • SNMP – Right, more like an ASN1 fuzzer, but provided some nice results.
  • UDLD – One more L2 protocol with a bunch of strings inside (watch out for the device-id).
  • VRRP – while implementing the VRRP attacks in loki, also did some fuzzing, obviously ;).
  • VTP – An other L2 based, Cisco only protocol, make devices blinking.
  • WLCCP – And the last one is again from our wireless research. Haven’t found anything interesting by fuzzing, but the loki module for this works nice.

So, thats all for now, have fun with the code and stay tuned for more tools on fuzzing to be finished/released soon.

enjoy

/daniel

 

Continue reading