ICYMI CVE-2024-53564 was reported publicly earlier this month by a third-party, but the ability to upload FreePBX modules via the GUI has been expected functionality for many, many years.
Maybe it is time for a change to the module upload process ? Happy to hear your ideas!
That said, this issue was NOT reported directly on the FreePBX security-reporting GitHub repo, although it is being worked on internally at Sangoma, and you should expect that there will be some more formal public follow-up there (and here) soon after the holidays, in accordance with the security policy goalâs âaim to resolve security vulnerability reports within 60 US business days.â
PSA
Please do continue to promptly and responsibly report suspected security matters using the aforementioned repo, as this is the best way to ensure a timely response with minimal risk exposure to your fellow users before public fixes are made available. Per the policy: âPlease do not report security vulnerabilities through any other mechanisms, including public mechansims.â
Itâs okay for someone to catch and analyze problems, but publicly disclosing them before or without telling the project means that the period of time they can be exploited on systems is increased, and the impact can be larger as attackers can become aware of the vulnerability and immediately begin exploiting it with no immediate resolution for users.
From a reporting perspective doing it via GitHub triggers emails, provides private communication between reporter and other parties (such as discussing the fix or collecting more information) and allows coordination on timing of release. It also doesnât âleakâ the existence of a security vulnerability until it is published. Itâs also the definitive list of vulnerabilities going forward - so no matter what security vulnerabilities will be published via that mechanism, and people can subscribe to receive notification of them.
I understand that this type of Bounds/Content Checking is required (and rightly so) but how is this a vulnerability? Only an authorized (logged-in) user could get to the Module Upload portion, or is this saying that you can upload without being logged in?
Perhaps there should be a focus on better security practices and file handling. This is the second time since 2023 that something like this has happened. Where users were free to upload files and put them any place they wanted with no checks. Including allowing a remote host to inject into the system.
Unless the actual underlying security and validation issues are addressed, changing methods just means a different way for it to happen again.
Same one Tom Ray spoke about, of course that might be âhearsayâ but In the past 10-15 years the project has bean compromised many times to my remembrance and to my cost. Who is currently responsible for QC ?
Yes and no. The incident I was referring to was someone who reported at least 3-4 different security bugs back at the start of 2023 and got an initial follow up specifically about IonCube because they had de-obfuscated code to deal with the vulnerabilities. All other attempts to communicate with Sangoma fell flat which is why they ended up doing a presentation at Def Con 31 about the security issues they found and tried to report.
I believe there was a thread about it after Def Con 31 and some concern over how Sangoma was more concerned about the reported de-obfuscated code versus the seriousness of the vulnerabilities.
Iâve been looking over the code and I think this is more about the upload itself in the browser not having checks for the files being attached to the upload. Because reporting the form itself doesnât really make sense. Plus there seems to be some validation happening. Still trying to review it.
This is massively blown out of proportion. It is a CVE, yes. The actual issue is that the filename provided in the upload is not sanitized. This means that someone could spoof the name as part of a curl upload, and set it to be ../../../../index.php or similar.
HOWEVER. This does require the attacker to be authenticated. Which kinda makes this a moot point.
Anyone authenticated can use the Config Editor module, via the GUI, to edit config files.
Anyone authenticated can upload their own module, without using any file name tricks, that has an install.php that does whatever the attacker wants.
Anyone authenticated can use any of (at least) three other modules that allow modifying files, or executing scripts - For example, Backup/Restore
So whilst this is, absolutely, a security issue, itâs a very minor one. The fix is simply to basename() the uploaded file name, and if it ends in .php reject it instantly.
This was know about a month ago. James and Tony both tweeted it, and I looked into it at the time to confirm their suspicions.
I still get automatic notifications of any CVEs that contain the word âfreepbxâ, and, well⌠I was going to say âI am surprised itâs taken a month for Sangoma to notice itâ, but after I typed that out, I realised I was not surprised at all, and is kinda been par for the course recently.
Oh, and as both of them are banned from these forums, they couldnât make people aware of the CVE here anyway - if it was slightly serious, I probably would have posted here on behalf of them. However, as Sangoma has decided, in its corporate wisdom, not to allow them to speak here, I wasnât going to risk getting the ban-hammer myself for passing this on.
Well said, thank you. Also, because authenticated users can get tricked by non-authenticated users, we might do the former a good service by providing a more robust fix than basename().
The other 99% of this issue is that the current Module Admin GUI approach crosses the streams between updates from known and unknown repositories too easily IMO. There should be more to the upload process than yet another button-click. This could take the form of more role isolation between CLI and GUI. It could also borrow some ideas from other OS distro package managers eg. aptitude for installing from existing repos vs. dpkg for installing locally downloaded packages outside of normal repos.
Example of CLI/GUI separation:
Using example titles, the role of systems distributor with CLI access (Alice) should be separate from GUI daily administrator who never uses SSH (Bob).
Questions:
Can Bob update and install modules from the repository that Alice previously approved ?
Can Bob get phished then download and install Urgent_PBX_Updates.tgz from repos that Alice did NOT approve ?
You keep saying repos but thatâs not what this is. No repos have to be involved in uploading/installing 3rd party modules. Someone could download a file from any website/blog/whatever and then locally upload that file from their PC via the admin GUI. That module could be signed against Sangomaâs systems or it could be unsigned like some of the Asternic modules.
Even more so, a module can be added over a link from a website. I donât need to actually use the upload function, I can use âInstall from Webâ and just put in a location to pull the .tar.gz from anywhere.
Again it looks like this is more about the upload process than anything else. I can upload any file I want to the system, only after itâs been uploaded is it checked if it is the right format or not. It doesnât remove the file at all. Itâs sitting there in the web server accessible path to be executed. Thatâs a problem.
I just uploaded a bad file to my system (i.e. not a proper format) and it was uploaded no issue but I got:
The following error(s) occurred processing the uploaded file:
* Unknown file format of php for testupload.php, supported formats: tar,tgz,tar.gz,zip,bzip
However I still have:
root@fpbx17:/var/www/html/admin/modules/_cache# ls -l testupload.php
-rw-r--r-- 1 asterisk asterisk 39 Jan 2 17:18 testupload.php
I was able to upload various file formats and all of them are on the system. They can be exploited from that point forward.
EDIT: I can also upload bash files and such. All owned by the asterisk user. If I already have access to the GUI ( and even just the GUI), I could still upload these files and with some magic dialplan in a _custom.conf file I can execute System commands to change the file to be executable and execute the file just by dial plan that allows dialling *700 and boomâŚexecution of malicious code.
Agreed, To clarify, this is the problem. The GUI is too permissive in the Module Admin section. AFAIK no other part of the GUI makes it this easy to exploit with one bad copy-pasta.
-- Executing [*9000@from-internal:1] NoOp("PJSIP/100-00000026", "Bad code time") in new stack
-- Executing [*9000@from-internal:2] System("PJSIP/100-00000026", "chmod 0755 /var/www/html/admin/modules/_cache/testupload") in new stack
-- Executing [*9000@from-internal:3] Hangup("PJSIP/100-00000026", "") in new stack
I now have
root@fpbx17:/var/www/html/admin/modules/_cache# ls -l testupload
-rwxr-xr-x 1 asterisk asterisk 99 Jan 2 17:39 testupload
If I modify the dialplan to add:
exten = *9000,n,System(/var/www/html/admin/modules/_cache/testupload) after the permissions commandâŚand it writes all the output to a fileâŚwhen I dial *9000 I get this:
root@fpbx17:/var/www/html/admin/modules/_cache# cat /home/asterisk/file.txt
This can do bad things
lrwxrwxrwx 1 asterisk asterisk 52 May 2 2024 /etc/asterisk/extensions.conf -> /var/www/html/admin/modules/core/etc/extensions.conf
If you have admin credentials you have the keys to the kingdom essentially
Because of #1 the server you use as your PBX should only be your PBX
With small exceptions such as root hooks through the sysadmin the kingdom is limited to the Apache user which is typically asterisk. Asterisk should also be running as the Apache user which is typically asterisk. Then only things belonging to asterisk can be touched. If your webserver or asterisk is running as root that is an issue and should be resolved.
Putting a file on a system doesnât matter unless it can be executed and even then if there is no way to escalate privilege the execution is limited in scope to whatever the users permissions are.
The key to all of this is authentication. If someone can authenticate they are likely going to quietly steal credentials or add extensions for use in toll fraud.
Fun fact if you are misconfigured they can commit toll fraud without any credentials.
What becomes more worrisome to me in this whole thing is the official security and Linux knowledgebase that doesnât know why this CVE is or isnât important. Also that whether important or not it can be resolved in a few lines of code without changing core function. If you are not going to keep security professionals on staff it is important to have a bounty program and friends in low places so that you get responsible reporting. From folks like Rob, Jason and myself who spend a lot of time in the netsec arena being friendly and not adversarial with the folks that wear hats of various colors goes a long way. It also often means if someone finds something they will often use responsible disclosure and send you the exploit and potentially a fix sometimes months before they release it publicly so you donât get caught with your pants down.
