TabbyPass - Sangoma NSC/NSG Authentication Bypass.
This is part of a series of posts on the Sangoma exploits I released at BSides Basingstoke 2024.
This vulnerability affects the Sangoma Netborder Session Controller (NSC) and Sangoma Netborder SS7 to VoIP Gateway. These are both telecoms/VoIP products for SS7 and VoIP networks, which purport to provide security features.
"TabbyPass", or "Tab Bypass" is a trivial, remotely exploitable authentication bypass exploit using argument injection.
It enables a remote, unauthenticated user to access the web interface of the device as an administrative user. This can be further leveraged to exploit post-authentication command injection issues to gain code execution on the device, among other fun and exciting possibilities - outlined in future blog posts.
So, lets outline how the bug was found and how to exploit it.
Firstly, let us examine where the username and password input get handled.
Username and password are taken from POST parameters "reserved_username" and "reserved_password".
This then leads to a "small sleep" to absolutely murder device performance and introduce a trivial DoS vector by hanging the web server thread briefly. I guess the developers never thought about this when implementing possibly the worst form of "anti brute force" rate limiting protection known.
Authentication is handled in a very interesting way - the username and password are passed to a command line utility, and its "exit code" determines if the login is valid or not.
It is also worth noting that - before passing the password to the command line, it encrypts the password with an AES function that uses the username to derive a key. More on this in another blog post.
The ShellExec used is a custom one with a few input validation/escaping features - basically calling escapeshellargs() on inputs.
So to check the login credentials, a command line such as the following is executed:
/usr/local/sng/bin/sng-user-mgmt –action=login –user=USERNAME –encrypted-password=ENCRYPTED_PASSWORDIf this returns an exit code of 0, more stuff happens, and you are in. If not, you are told the login failed.
This is where things get kind of interesting - in 2018 and 2019, Appsecco found code injection and auth bypass issues here, linked below. I came across those advisories when doing a search for prior art.
https://packetstormsecurity.com/files/145815/Sangoma-NetBorder-Vega-Session-Controller-Remote-Command-Execution.html
https://packetstormsecurity.com/files/154914/Sangoma-SBC-2.3.23-119-GA-Unauthenticated-User-Creation.html
https://packetstormsecurity.com/files/154915/Sangoma-SBC-2.3.23-119-GA-Authentication-Bypass.html
While the Appsecco findings have been mitigated - I came across a different vector while working on this, unaware of their previous work :)
Spaces seem to no longer be allowed, which is mildly annoying. However - as far as the subshell executing the command is concerned, tabs are equivalent to spaces.
So in this instance, tabs beat spaces - we can sneak in a tab character just fine and bypass the input sanitising, letting us perform argument injection.
As for what argument to inject: their example used -h to invoke help, but I found this no longer worked.
Instead, I found injecting -a info, which tells the sng-user-mgmt script to pull user information for a user, worked fine. This action also will return an exit code of 0.
The final "payload" to inject into the username field is as follows: root<tab>-a<tab>info. You can easily exploit this using an intercepting proxy, or from a trivial Python script.
A Python snippet to exploit this on the NSC device is shown below:
The only difference for the NSG product is the redirect location after login.
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.
The next two posts will demonstrate post-authentication remote code execution issues in the NSC and NSG products, that can be chained with this vulnerability to gain unauthenticated remote code execution as the "webconfig" user.