🔴 Unauthenticated remote code execution in FreePBX UCP via socket.io namespace auth bypass and AMI action injection

Blog Security
, ,
1

Summary

Unauthenticated users who are able to access the UCP Node server of FreePBX are able to execute arbitrary commands through the Asterisk Manager Interface.

Provider Urgency is set to Red. Please take action immediately.

Common Vulnerabilities and Exposures (CVE)

Requested

GitHub Security Advisory (GHSA)

GHSA-37j8-fhxx-9vhp

Provider Urgency (choice of: Not Defined, Clear, Green, Amber, or Red)

R - Red

Link to Published GHSA with More Details

Highlights

:red_circle:

3

This is a bit misleading

History

This problem manifested because of the socket.io v4 library used in all versions of FreePBX 17.

Because the issue is that the FreePBX devs forgot to account for the changes in the new version of socket.io that now uses namespaces. So the authentication seems to be just on the main socket connection (since in previous versions that was the only way) but now that namepsaces are used and treat each namespace as its own channel and each channel needs to be authenticated.

Basically, the house used to have a front door that is secured but after the remodel the house now has multiple doors that can be used to enter and the dev team forgot secure those extra doors.

This isn’t an issue with socket.io, it’s an issue with how Sangoma implemented socket.io.

4

Thank you for the feedback @BlazeStudios

There’s two parts here: socket.io and AMI.

  1. The first is one of those rare(r) situations where upstream (socket.io) made changes that reduced security in some downstream consumers (ucp). YT just yeeted a PR to address this in the official socket.io documentation.
  2. The unauthenticated part would’ve not made much difference if the underlying AMI part to allow multiple commands through weren’t also at issue.

That said, both of these problems go back years, well before 17, because the solutions to them were available long ago. But the point of intersection of these two lines is the security issue at hand.

Fortunately, this issue was reported responsibly and resolved swiftly by Sangoma engineers in accordance with our established security policy for the FreePBX project.