An email came out today to Moodle admins…I’ve put in bold the areas I found fascinating. The Moodle security issue aside, the bold section raises the question as to whether any organization has a reasonable expectation that exploits will be kept private until they can fix them and announce the problem and solution. Is this really realistic?

One of my expectations–perhaps incorrect, and therefore worthy of being challenged–of free open source software is that software is MORE secure because the code is freely available. And, as a result, all programmers–foe or friend–can study it and identify exploits that they can share back with the community. In fact, when discussing the issue with a “Microsoft shop” technology administrator, it was exactly this reason that made free, open source software so undesirable for a business.

What arguments would you offer in support of Moodle? Are these security exploits just ones that happen and we just deal with it as best we can? Can such exploits really hurt Moodle deployments?

Hi Moodle admins,

You're getting this email because you chose to receive important news
by email when you registered your Moodle site with moodle.org.

I'm writing to tell you about an exploit that was recently published
on the internet (intentionally bypassing our official security policy
of responsible disclosure published at http://moodle.org/security and
so increasing the vulnerability of many Moodle sites).  The exploit
demonstrates how a Moodle teacher could potentially gain administrator
access to their own site.

In Moodle 1.9.6 and earlier, backups saved with the option of "user
data" would contain accounts of all the users enrolled in that course,
to promote data consistency if the backup was restored on another
Moodle system.

This included the md5 one-way hash calculated from the user's password
(eg e4d909c290d0fb1ca068ffaddf22cbd0). These can't be directly
decrypted to reveal the password, so they used to be seen as
reasonably safe to distribute.  However, with the advent in recent
times of large databases of md5 reverse lookups on the internet, many
simpler passwords can now be determined quite quickly by searching for
their md5 hash (reverse mapping).

The demonstrated exploit basically involved a trusted teacher account
enrolling an administrator into their own course, then making a backup
of the course including user data, extracting the md5 hash of the
password from the backup file and then reverse mapping the hash to
discover the password.

Note that the exploit requires that (a) the user is a trusted teacher
on the site, and (b) that the admin is using a fairly weak password.

Moodle development policy has always generally been "we trust
teachers".  However, we know that YOU may not trust them all and will
want to lock down your sites as much as possible.


NEW RELEASES ARE COMING SOON

The core dev team is working hard on Moodle 1.9.7 and Moodle 1.8.11
right now.  Among other things, there are fixes to 11 known issues
that are related to backups and user data.  We will let you know when
these releases are ready, via this mailing list.  It should be within
a week.


WHAT YOU CAN DO RIGHT NOW

Your site may be vulnerable if you have any users with full backup
rights on your site that might have a reason to try and crack your
admin account, if they saw the published exploit.  Here are some
things you can do to improve security on your site right now:

1.  Disable backup functionality for teacher roles.  You can re-enable
backups later with the new Moodle releases, because the permissions
for saving user data will be separate from the permission to create
backups.

HOW:  Admin > Users > Permissions > Define roles:  Edit the teacher
roles and change the capability for moodle/site:backup to "PROHIBIT".


2.  Turn on site-wide password salting (in all versions of Moodle
since 1.6), this adds information to the md5 strings to make them
practically impossible to reverse (next time they log in or change
their password).  Note that this will affect your ability to restore
backups containing user data on foreign Moodle sites - the admin of
the destination site needs to include your salt in their config.php
for user creation to work.

HOW:  Add a line like this to your config.php (for the best security,
there is intentionally no way to set this in the Moodle interface)

$CFG->passwordsaltmain = 'some long random string here with lots of characters';


3.  Turn on Password Policy for your site, this forces people to use
stronger passwords.

HOW:  Admin > Security > Site policies > passwordpolicy


4.  Change passwords for all admins.  Now that you turned Password
Policy on you'll be forced to choose a stronger one.  :)   It also makes
any old backups useless for the purposes of the exploit.

HOW:  Edit your user profile directly, for other admins you can edit
their profile and check this box:  "Force password change".  They'll
be forced to change it when they next log in.


Good luck, thanks for using Moodle and I'll talk to you again soon.


Cheers,
Martin (Moodle Lead Developer)

Subscribe to Around the Corner-MGuhlin.org

Everything posted on Miguel Guhlin’s blogs/wikis are his personal opinion and do not necessarily represent the views of his employer(s) or its clients. Read Full Disclosure