Zero-Day Research: PicoC Version 3.2.2 Null Pointer Dereference (CVE-2022-34556) Speedrun

PicoC is a miniature code interpreter developed for C scripting. According to their documentation, PicoC was first written as the scripting language for a UAV’s on-board flight system. In this zero-day post we are going to speedrun the discovery of a null pointer dereference (CWE-476) denial of service (DoS) vulnerability in the PicoC interpreter. I discovered the vulnerability using AFL++ and notified the development team immediately. The DoS vulnerability affects PicoC up to version 3.2.2.

Prerequisites

  • C Programming and Compilation 
  • Pointer Dereferencing
  • Basic Understanding of AFL++
  • Denial of Service Vulnerabilities

Disclosure and Disclaimer

The null pointer dereference vulnerability was responsibly disclosed to the PicoC development team. This post was intended for developers who are interested in keeping their applications secure and is for EDUCATIONAL PURPOSES ONLY. I do not condone illegal activity and cannot be held responsible for the misuse of this information.

Speedrun

Let’s get started…

Browse to the PicoC Source Code Directory

Point the Compiler Variable in the Makefile Towards ‘afl-clang-fast

Run the ‘Make’ Command to Build Our Executable

Creating Input/Output Directories and Input Files

Moving Our Input File to the Input Directory and Starting AFL-Fuzz

Scanning the Output For Crashes

Listing the ‘output/default/crashes’ Directory

After opening the crash files we find an interesting crash input:

**4%;

Replicating the Crash With GDB and Verifying the Null Pointer Dereference

Speedrun Complete

HackTheBox: Looking Glass Web Challenge

Today we will be walking through the ‘Looking Glass’ web challenge from HackTheBox. This specific challenge is quite simple but provides great insight into common web security flaws that you might find in custom-built applications. HackTheBox is an online platform that hosts various penetration testing challenges ranging anywhere from binary exploitation, web security, Windows Active Directory, Internet of Things, and much more.

Browsing the Website

Once we deploy the challenge we are presented with a basic web page that allows the user to run a ping or traceroute command against an IP.

Static Analysis

We can do some basic static analysis by viewing the page source.

There doesn’t seem to be anything interesting going on. We can move on to dynamic analysis from here.

Dynamic Analysis

Let’s do some dynamic analysis by clicking the ‘Test’ button on the web page and intercept the request with burp.

This challenge screams OS command injection. The page simply sends the parameters from the form to the server and (likely) runs the ping or traceroute binary on the file system with the parameters from the POST request. There is probably some PHP code in the background that resembles the following:

$ip=$_POST['ip_address'];
system("traceroute $ip");

This would result in the following Linux command being run:

traceroute 178.62.0.100

If you are not familiar with OS command injection I would highly suggest reading the official OWASP article about it. For this challenge, we can add a semicolon behind the IP in the ‘ip_address’ POST parameter and run extra commands to find the flag. Let’s start with a simple ‘ls’ command (don’t forget to URL encode the parameter).

//Payload
test=ping&ip_address=178.62.0.100;ls&submit=Test
//URL Encoded payload
test=ping&ip_address=178.62.0.100%3B+ls&submit=Test

It worked! We can see the file index.php listed in the results box. Let’s list the contents of the root directory and see what files exist on the file system.

It looks like the flag is in the root directory. We can view the contents of that file and and complete our challenge.