Slayer Labs

Cyber Range Platform

rConfig 3.9.6 - Magic Hash Auth Bypass to RCE

This post will cover two vulnerabilities in rConfig 3.9.6 when chained together could potentially lead to unauthenticated code execution. The first vulnerability involves type juggling using magic hashes to bypass authentication, and the second involves command injection via its cron job functionality.

rConfig is an opensource web-based network configuration management utility, with a free and paid version. These vulnerabilities cover the free version which at the time of writing hasn’t been update for more than 1 year.


rConfig isn’t heavily used in the wild, and seems to be a smaller/niche web app. This post is more to review a real world example of a type juggling vulnerability and how it can be used to bypass authentication..and more. This likely won’t be exploitable in an engagement due to rConfigs low userbase.

Magic Hash 🧙 Auth Bypass

When logging into rConfig, the authentication process will take the user supplied password, MD5 hash it, then compare it to that users MD5 hashed password in the DB. If the hash supplied by the user equals the hash stored in the DB, the user will be successfully authenticated.

Loose Comparisons Primer

PHP (and other programming languages) utilize loose comparisons to make life easier for developers by basically relaxing comparison rules. The two operands don’t necessarily have to be exactly the same to evaluate to true. A loose comparison example that would evaluate to true would be: "00" == int(0)

Loose comparisons do more funky things that are well documented in this OWASP presentation pdf - quoting the relevant part for our example “If PHP decides that both operands look like numbers, even if they are actually strings, it will convert them both and perform a numeric comparison:”

TRUE: "0e12345" == "0e54321"

PHP see’s these two strings and thinks they are in scientific notation, so zero to the power of anything numeric equals zero. In the rare chance a users password results in an md5 hash beginning with 0e + 30 digits we can supply another password which hashes out to be 0e + 30 digits to trigger a true comparison.

Rare Magick

In general, the possibility to exploit this vulnerability would be very rare as it would depend on a massive userbase. In all likelihood any live instance of rConfig wouldn’t have a user with a hashed password that would fit within our criteria. Although in a purposely vulnerable lab environment one might find such a user 🥸

In the image below, rConfig’s MySQL instance shows ‘alice’ with a password that results in a magic hash - note 00e is also 0. The other string(aabC9RqS)/hash combo is what we’ll use to exploit this vulnerability.

md5 stored magic hashes

Code Analysis

Taking a quick glance at the authentication code, the initial function takes the supplied username and md5 hashes the supplied password and passes to confirmedUserPass function.

$results = $database->confirmedUserPass($subuser, md5($subpass));

Then confirmUserPass function takes the md5 password hash and loosely compares (==) it to the password hash of the user from the DB.

function confirmUserPass($username, $password) {

// ...sql stuff...

if ($password == $dbarray['password']) {
	return 0; //Success! Username and Password confirmed

Logging in with the username ‘alice’ providing our magic hash password (aabC9RqS), we get a successful login.

rconfig login bypass

Compared to Strict

To quick showcase how a strict comparison would evaluate, we can edit the source code by adding an additional equals sign, aka “===” instead of “==”. Note this may be used as a quick and dirty fix, but it’s advised to use built-in, updated PHP functions for more reliability (password_verify, hash_equals, password_hash, etc)

magic hash temp fix

RCE via Cron

One functionality of rConfig allows a user to run scheduled tasks on target network devices. The web page for this functionality has a convenient web gui which allows users to set a type of task to execute, any customizations and when it should run (in cron format).

rconfig cron gui

Once saved, a new cronjob will be created. Below is the cron result of a normal task that was set to run a built-in report script.

0 0 1 1 * php /home/rconfig/lib/compareReportScript.php 843022

This feature can be abused to escape out of the preconfigure cron command and instead plant our own commands for cron to execute. Since the last value in cronjob is weekday, we’ll append our payload after that. In our case a webshell.

* /usr/bin/echo 'WEB SHELL CODE HERE' > /home/rconfig/www/shell.php #

Once saved, it should be executed immediately resulting in a simple webshell.

command injection with burp


I also create a PoC in python to make life easier. It has an authenticated mode and an unauthenticated mode. It’ll create the cron and cleanup the task in the gui as to avoid detection while also avoiding the cron from continually executing, leaving only your webshell.

python poc


« Back