CVE-2023-34960 | Fix and communication

[meuhland]

Being a heavy user of Chamilo with a portal that includes a lot of modification the disclosure of this CVE issue is a bit problematic.

The proof of concept by the researcher has been published over a week ago, the issue could have been mitigated before attack have been spotted in the wild.

For those of you running portal in a similar situation the fix seems to be related to this commit
7ecc0c9

I do agree that making this might not be in the best interest of the Chamilo project but the PoC and the attacks are out there and giving people running customized portals a way to at the very least be safe should be a priority.

[gianito]

Is there any news about this? Does version v1.11.20 correct this? If so, I agree with @meuhland, and would have appreciated some communication.

[ywarnier]

Yes, 1.11.20 fixes it.
How could we have communicated this in a way that suits you better?

[NicoDucou]

Just to complete on this task, the issue had been reported on the security page of Chamilo here : https://support.chamilo.org/projects/chamilo-18/wiki/Security_issues#Issue-112-2023-04-20-Critical-impact-High-risk-Remote-Code-Execution

[ywarnier]

Also, we are trying to identify patterns for those affected. If you have information to provide that does not compromise your server's security further, I think here would be a great way to share how to find if you've been hacked.

So far, what we've found is you can identify if someone tried to hack you by finding any mention of "additional_webservices.php" in your access logs. Some use an available python script, so the request will also mention the term "python".
Usually, if there's only been one request to additional_webservices.php for any given IP, it's likely some script kiddy just tested your site but didn't go any further.

The next step (if it's vulnerable and they really try to get more stuff) you will find files uploaded in your Chamilo code. Scripts ending with ".sh" or ".php" that have names not associated with Chamilo's code.

To upload such scripts and execute them, the web server needs write access to the given folders. If you have a good security design in your folders, you might have rules that prevent (at the Apache level) execution of PHP code from directories that are writeable by the web server. If you don't, your server might be used as a web server for something else (file sharing software, online gaming server, anything goes).

To identify recent files with .php or .sh extensions, you can use this on the Linux command line (if you have that) from the root folder of Chamilo:
find . -type f -name ".php" -ctime -7
This will show all new php files in the last seven days.

[ywarnier]

Also, a quick fix (not requiring upgrade) is to remove the main/webservices/additional_webservices.php file altogether. It is only used for remote LibreOffice implementations (very rare cases).

[meuhland]

@ywarnier Exactly that would have been perfect communication-wise. Portals that have modifications and need to test each release as per a strict set of guidelines cannot really afford to just apply right away every updates. I do understand the let's wait until the fix is up before writing it in bold letters all over the internet. But BeezNest and other partners have mailing lists and customer emails. The fact that Ludiscape only sent an offer for free tech support for this issue on friday evening, to their mailing list members after the fact that attackers in the wild already have exploit code up and running. Simply confirms to me that maybe once the PoC have been released (over a week ago) the stance of keeping the simple workaround or wider communication might be an issue. Guessing the GDPR-land portals compromised are going to have a lovely day and will feel the impact more.

@NicoDucou Yeah it's posted there but who honestly visits that page regularly, maybe some admin will check CVEs and well this has a # (that I grabbed from the researcher's github that include the proof of concept checking if your portal is vulnerable or not)

[ywarnier]

Hi, just so you know, version 1.11.22 is currently in the packaging process and includes additional security fixes.
We urge you to update as soon as possible to this latest version.
https://github.com/chamilo/chamilo-lms/releases/tag/v1.11.22
We will still be doing a few tests this 3rd of August before promoting the new release to the wider public.

[ywarnier]

Just a note because this is not the point of this issue, but serves as reference for some to think this has not been fixed in Chamilo:

• a patch was released and documented in the CVE on the day of publication of the CVE
• versions 1.11.22, 1.11.24 and 1.11.26 (the latest stable to this day) of Chamilo have included this fix and are thus not affected by this vulnerability anymore. Versions 1.11.22 and 1.11.24 still had other important issues, yes, but they were fixed in 1.11.26.

This issue here was a discussion about the process of notification of the patch and how to improve it. Not about the fact the CVE was not fixed. A fix was provided to the security professional who reported the issue and registered a CVE in the first place.

Kudos to any hosting company's security team for considering that, because this issue was not closed, this patch to a critical security issue was never "released" nor published in a stable version of Chamilo, even though we published 3 specific stable "security-focused" releases after publishing the first patch in May of 2023 (about a week after the issue was reported - we actually slipped a few days because we wanted confirmation from the reporter that he saw no remaining vulnerability).

We understand that our communication process has to be improved, but locking a platform in February 2024 because of a critical vulnerability fixed in May 2023 and released in a new version in early August 2023 wouldn't be my way of dealing with this.