Sangoma NTG Post-Authentication Remote Code Execution.
This is part of a series of posts on the Sangoma exploits I released at BSides Basingstoke 2024.
This vulnerability impacts the Sangoma NTG (NetBorder Transcoding Gateway) product, which is quite old. It is another telecoms/VoIP product.
The vulnerability in question is quite simple: shell command injection. It requires authentication to exploit, unfortunately, and the TabbyPass trick doesn't work on these older models as their authentication mechanism differs slightly.
In short: the "network status" page in the admin panel has a feature where you can ask JNetTop to give you updates on network traffic, and this whole feature is full of shell command injections.
Like so...
Basically - the interface and interval parameters end up being used to construct a command that goes to JNetTop.
There is a small catch though - there is some input sanitising happening here, we cannot use angle brackets to do pipes!
Luckily, from some previous work, I had a neat trick up my sleeve.
First, we create our reverse shell payload. Then we encode it as hexadecimal and wrap it in some shit that tells 'dc' to decode it. Then pipe to dc and finally to bash.
Which results in something like this as a reusable function for the future!
def dc_encoder(reverse_shell):
hexadecimals = binascii.hexlify(reverse_shell.encode('ascii'))
hexadecimals = hexadecimals.upper()
wrapper = f"echo '16i {hexadecimals.decode('ascii')} P' | dc | sh"
print(wrapper)
return wrapper
There is a second catch: if JNetTop is running when we inject the command, nothing happens. Luckily, we can just chuck the command injection in a loop and usually it works after a couple of tries, landing us a shell.
And yes - there is of course one of the previously discussed local privesc bugs to gain root.
Exploit can be found here: https://github.com/fullspectrumdev/sangoma-ntg-rce
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.
Next time, I'll discuss a post-authentication VideoMCU vulnerability.