Vulnerability Scans - False Positives?

Vulnerability Scans - False Positives?

by Steve Mo -
Number of replies: 5

Hello All,

I've been a long-time lurker here and have read tons of great insights from the great community! This seemed like the right place to ask about my current Moodle security situation.

Over the weekend I built a new Moodle server, migrated my current Moodle 3.8 database and Moodle files to it successfully, and then followed it up with an upgrade to 3.11.6. Everything went well and I see no current issues.

However, when I run a paid vulnerability scan on this server, I am getting approximately 18 Medium to High vulnerability alerts all tied to Moodle-specific CVE's which were supposedly fixed by upgrading to the latest version of Moodle. Since I did a clean install of 3.8 on a fully patched up Ubuntu 20.04 server, and then performed an upgrade to 3.11, I figured I would be in the clear. Is it possible that vulnerability scanning tools would be finding old 3.8 components on my Moodle server, or are these false positives?

Here are a few example CVE's:

CVE-2019-10187 : Moodle: Missing Authorization

CVE-2021-43560 : Moodle: Exposure of Resource to Wrong Sphere

CVE-2021-20187: Moodle: Improper Control of Generation of Code

CVE-2021-43559: Moodle: Cross-Site Request Forgery (CSRF)

Anyone have any thoughts as to why these would show up if I am at a relatively new version of Moodle (3.11)? In fact, I had installed Moodle v4.0 earlier today and received the same vulnerability warnings, so I was kinda shocked!

Thanks for your time and thoughts!

-Steve


Average of ratings: -
In reply to Steve Mo

Re: Vulnerability Scans - False Positives?

by AL Rachels -
Picture of Core developers Picture of Particularly helpful Moodlers Picture of Plugin developers Picture of Testers
Hi Steve,
Sorry, I don't know anything about, Vulnerability Scans, but from reading your post I know that everyone is going to want to know, what specific steps you took to do the upgrade from M3.8 to M3.11.6?
Average of ratings: -
In reply to AL Rachels

Re: Vulnerability Scans - False Positives?

by Steve Mo -
Thanks Al!

For the upgrade process, I performed the following:

Background:
The new server is a direct replacement of the old server, with no IP address or URL changes. The reason for building the new server was because the original server was having issues upgrading directly to Moodle 3.11 as some of the PHP components were unable to be updated properly due to a recent upgrade from Ubuntu 16, to 18, to 20.04. I could not pass the Moodle upgrade checks, and decided to build a new server from scratch.
I did not upgrade to Moodle 4.0 as the theme that my users are familiar with has not yet been updated, and does not function with 4.0, so I decided to stay with 3.11.6.

PHASE 1: Rebuild of 3.8 Moodle Server

1. I started with a new install of Ubuntu 20.04.
2. Clean install of all required server and database components (Php 7.4, Apache 2.5, MySQL 8).
3. Data Migration:
a. Performed a MySQL dump from the original server to a temp location on the new server.
b. Copied/rsynced Moodledata directory from the old server to new server.
c. Copied/rsynced /var/www/html/moodle directory from old server to the new server.
d. Restored MySQL database into the new MySQL server.
e. Copied all local plugins (3 total) from old server to new server.
f. Verified the config.php file to the /var/www/html/moodle directory was configured correctly.
g. Assigned proper file access rights to root and Apache where necessary.
4. Setup SSL/TLS security with certificates and tested functionality.
5. Once the old site was verified as accessible and functioning, I began the upgrade to 3.11.6.

PHASE 2: Upgrade to Moodle 3.11.6:

1. Created a temporary copy of entire /var/www/html/moodle directory.
2. Downloaded a copy of 3.11.6 from the official Moodle site.
3. Deleted entire /var/www/html/moodle folder. (I kept a copy of all contents on temp folder)
4. Unzipped/untarred the Moodle install files directly to /var/www/html/moodle
5. Copied config.php from 3.8 build to /var/www/html/moodle.
6. Accessed the admin page of the Moodle site, and was prompted to begin the upgrade.
7. During the upgrade compliance check, some plugins/themes were missing (autoenrol, saml), so I copied those local plugins/themes from 3.8 build into /var/www/html/moodle.
8. I finished the upgrade to 3.11 without issues, and all seemed fine. The site functions well, and courses are accessible. Everything looks to be functioning properly.
9. Enabled Cron.
10. I did not yet update all of the plugins. We have the following waiting to be updated: "AutoEnrol" (enrollment), "SAML2" (authentication), "Enlightlite" (theme), "Moodle Adminer", and "Course Recompletion".

I’m wondering if there are still remnants of 3.8 on the server, eventhough there should not be as, after I copied over the 3.8 configurations to /var/www/html, during the upgrade to 3.11, completely wiped the /var/www/html/moodle directory to unpack the 3.11 version, only retaining the config.php and plugins.

Perhaps there is something in the Moodledata folder that remains at version 3.8 or older?

Any help/ideas would be much appreciated!

Thanks!
-Steve
Average of ratings: -
In reply to Steve Mo

Re: Vulnerability Scans - False Positives?

by Ken Task -
Picture of Particularly helpful Moodlers

Moodle caching begins right away.   In Moodle admin, Purge All caches.   If that doesn't do the trick, one can manually remove from cli *the contents of* moodledata/cache/ moodledata/localcache/ and moodledata/muc/ ... those will be rebuilt almost immediately - cron job triggers some of that I think - but as moodle is used so will other areas update cache.

Also, Moodle now has a security check of it's own.

Under Admin -> Reports -> Security Checks.

'Fun and Games" there! :|

 And a question .. do you have installed a WAF - like mod_security?

False positives *are* trigged by that - know that for a fact!

My 2 cents!

'SoS', Ken

Average of ratings: Useful (1)
In reply to Steve Mo

Re: Vulnerability Scans - False Positives?

by Marcus Green -
Picture of Core developers Picture of Particularly helpful Moodlers Picture of Plugin developers Picture of Testers

It is worthwhile reading the details of reported vulnerabilities, for example one that is showing up on your site is as follows.

CVE-2021-20187

Which is described here

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-20187

"that it was possible for site administrators to execute arbitrary PHP scripts via a PHP include used during Shibboleth authentication."

Many installations don't use or enable shibboleth so this would probably not be relevant.  To exploit this vulnerability you would need to be the site admin. It is recommended that only one (or a very small number of people have admin access). Users with admin access can do just about anything to a Moodle site by default, e.g. delete all users, courses etc. So for most people most of the time if a malicious person have admin access and want's to do damage there is nothing you can do anyway.

But it would be good to find the answer to your question and ensure that all and any fixes have been applied.


Of course you really don't want admins to be running arbitrary PHP scripts anyway, but I am expanding on this specific issue to illustrate that vulnerabilities can vary wildly in their potential impact.


Average of ratings: Useful (1)
In reply to Steve Mo

Re: Vulnerability Scans - False Positives?

by Michael Hawkins -
Picture of Core developers Picture of Moodle HQ Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Testers
Hi Steve,

I published all of the CVEs you mentioned and can confirm fixes were released before the CVEs were published (in line with our Responsible Disclosure Policy). If your site is running Moodle 3.11.6, all of those issues are patched, so I suspect your vulnerability scanner is identifying the wrong Moodle version when it fingerprints your site.

Another thought - since your 3.11.6 site was built on a fresh server, is it possible that the scanner is somehow finding its way to the 3.8 site and identifying issues there, for example through some hard-coded URL or similar that it can crawl (assuming of course that both sites are running live at the same time)?
Average of ratings: Useful (2)