Fuzzing

This page gives an overview over the BasicFuzzer.py fuzzing script and some basic usage examples.

Table of Contents

• Basic Fuzzer
  • Parameters
  • Implementation
• Examples
  • NAS Fuzzing
  • NAS PDU Session establishment message Fuzzing
  • RRC Measurement Report Fuzzing
• TODOs

Basic Fuzzer

The basic fuzzer is a Fuzzing Utility that can be used to fuzz messages on different layers. The fuzzing principal is here to just send all possible messages in ascending order. That means we send 00 then 01..., if we reach ff we add a byte and start over, 0000 then 0001.... This can go for ever if you don't quit the program with CRTL+C. What is to be mentioned is, that the program will stop if the UE does not respond. This is done so you have the chance to restart gNB, AMF and/or UE if a crash happened and then continue fuzzing with the last message you used.

But take care because if some component in the pipeline crashes, the messages that are currently processed will be lost. This means that if you really want to make sure EVERY message is tested you might need to start over from some messages before the crash or use a really slow fuzzing.

Parameters

• 1: Protocol layer and settings
  • Takes the layer of the messages e.g. "nas_no_sec" for NAS without security protection. For more information on the different options see second layer documentation.
• 2: Preset Bytes
  • This takes the bytes which shall be preset in the fuzzing. For example you could preset the 5G MM header and the security type "7e00". For more information on how to preset things look here.
• 3: Timing
  • This parameter takes the time in ms on how fast the messages shall be sent to the UE.
  • If you enter -1 the script will wait after every message for a user input to continue.

Example call:

python3 Fuzzing/BasicFuzzer.py "nas_no_sec" "7e00" 100

So for example if we want to fuzz test all possible NAS 5G mobility management messages, without security protection, we just enter the preset bytes 7e00 as shown in the example call.

Implementation

The implementation is quite easy to follow and best described by looking at the comments in the code.

The basic principal used is that we have a loop which takes all currently available messages and appends every possible next byte to every of those messages. After that the header for the rest socket message is generated and the messages are sent to the UE. When all messages are sent the generation starts again, preparing the next round of message sending.

Examples

NAS Fuzzing

To fuzz on the NAS layer we start our ue with the message socket enabled and then execute the basic fuzzer:

Example call:

python3 Fuzzing/BasicFuzzer.py "nas_no_sec" "7e00" 100

This example fuzzes all 5G Session Management Messages (7e) that are not security protected (00).

NAS PDU Session establishment message Fuzzing

Here we again just use the basic fuzzer. With the basic fuzzer we can in principal fuzz test every NAS message, we just need to preset the according bytes.

As an small example we will fuzz test the NAS PDU Session Establishment message. Therefore we use the non security protected NAS message sending and preset the bytes(PDU Session establishment message generation). We execute the following:

python3 Fuzzing/BasicFuzzer.py "nas_no_sec" "7e00670100072e0a01c1ffff" 100

RRC Measurement Report Fuzzing

Here we again just use the basic fuzzer. But in this case we have the problem, that RRC message headers are not byte aligned because of the asn1 PER encoding. so we sometimes need to preset more that we would probably want.

For example we try to fuzz the RRC Measurement Report message. This message is build up as shown in the following:

• 0 -> UL DCCH Message
• 0000 -> Measurement report

The next 3 bits already contain Measurement report information, so we normally would like to fuzz them. For now, until the basic fuzzer is enhanced, we need to preset them. Therefore to test all Measurement reports we have to do the following:

python3 Fuzzing/BasicFuzzer.py "rrcsrb1" "0x" 100

for every x in [1..7].

TODOs

• Put the message generation into another thread so the next message length is available if the old one is finished. At the moment you have to wait e.g. after you tested all 2 byte messages for the 3 byte messages to be generated.
• Allow fuzzing on bit level so we don't have to do what we did in the last section.