RCE via failed regex check — One dot to rule ’em all!

As you can see in the advisory screenshot, RCE is possible in Web Interface 5.5!

In more granular terms, the validDomainWildcard preg_match filter allows a malicious character through and that
can be used to:
- execute code,
- list directories,
- and overwrite sensitive files

Vulnerable Code

This vulnerability happens in 2 steps/stages.

Step 1 is where the attacker’s commands get added to a config file and Step 2 is where their commands get executed since the config file gets source’d!

The above code contains a regex that is responsible for the first stage of this vulnerability:

$validChars = preg_match(“/^((\*.)?…

As you can see there’s a dot (.) which, loosely speaking, is a special character used to match any one character.

And this vulnerable function is called in 2 places, one of which contains a non-so-appealing sink — a sink which adds the contents of their choice to a config file (pihole_execute) which is highlighted in the image below!

Now as you can see in the above code, the vulnerable function is used to check if the value passed for the $client variable is following the pattern specified in the regex or not. If it does, then it goes to the execution sink that would set the value for a config variable, which at the end of the malicious request would contain a command execution payload.

So a sample request would look something like this:

Payload: *;ls

The payload went through all the checks, I suppose! Don’t see any errors or complains from the server, do we? :)

If you check the config file — “/etc/pihole/setupvars.conf”:

Now you might be things, yes fine, you got this value into the file! It’s good but where is the RCE, you promised?

Unless you manually go and source the file, I don’t see any issue there… So we are safe then? No… we aren’t!

To trigger the sourcing we simply need to run go to the gravity endpoint
“/admin/gravity.php” and click update. And (bam!) shell started to rains!

Hahahaha, okay maybe not the rain, but the command injection output does indeed shows up!

So we get the output of the command as well!

So, recapping the stuff we did till now were helpful in command execution.

Now File overwrite!

If you send a payload of *>FILENAME, then you can effectively overwrite any file in “/var/www/html/admin/scripts/pi-hole/php/” directory, effectively breaking PiHole if some important file gets emptied out!

You can even overwrite the files for other users like root for instance (if PiHole application runs as that user) by setting the domains & clients parameter in the request to the following payload:

domains=*;cd&clients=*>.bashrc

So the payload in the domains parameter would result in changing directory to the root user (assuming PiHole is running as root) and the other half (setting the client) would empty the .bashrc file for that user.

You can get creative now and runs any commands that you wish!

The researcher who reported this issue also posted the script to automate this attack to avoid the manual effort of intercepting and modifying the requests!

You can check more on that here in the Proof of Concept section.

Extra Bits

Another important thing to be noted would be that the regex pattern used by the application was quite complex and thus a malicious user could send arbitrarily large or crafted input that can hang up the PiHole server due to it processing this complex regex which results in a lot of input states (attributed to the complexity of the regex ofcourse!).

So that would be ReDoS attack, nothing flashy, a simple DoS leveraging the complex regex definition which can accept any arbitrary input and can have a lot of resulting states and thus, if you send an invalid and complex pattern, it leads to taking up server processing time and memory!

Feel free to read more on ReDoS here.