About Moodle vulnerability of SHA1

About Moodle vulnerability of SHA1

by Tanky Tang -
Number of replies: 11

Hello everyone, 


We are currently using Moodle with 2.7 and our security vendor said the SHA1 will be retired soon, and it seems Moodle is using SHA1/MD5 for encryption 


They have below vulnerability comments:


Vulnerability:  Use of Broken or Risky Cryptographic Algorithm

Impact:  The use of a broken or risky cryptographic algorithm is an unnecessary risk that may result in the disclosure of sensitive information.

Recommendation:  Use SHA-2 instead of SHA-1


Sorry, I am new to this forum and I tried to search around Moodle docs and it seems there is no information about this.  Would someone please provide more information if Moodle is safeguard of SHA1 issue?

What I got is something related is the Moodle's Password salting (https://docs.moodle.org/23/en/Password_salting)


Many thanks,

Tanky


Average of ratings: -
In reply to Tanky Tang

Re: About Moodle vulnerability of SHA1

by Tim Hunt -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers

If you upgrade Moodle, it will no longer use SHA1 for passwords. (Not sure when it changed, but it was quite a long time ago.)

Average of ratings: -
In reply to Tim Hunt

Re: About Moodle vulnerability of SHA1

by Mark Johnson -
Picture of Core developers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers

Further to what Tim said, the documentation on password salting you linked to is for Moodle 2.3, which is out of date (this is also indicated on the page itself).

The latest version, which applies to Moodle 2.5 onwards, is here: https://docs.moodle.org/30/en/Password_salting

Average of ratings: Useful (1)
In reply to Tim Hunt

回應: Re: About Moodle vulnerability of SHA1

by Tanky Tang -

Thanks, Tim, 

I may not aware I quote the wrong version of Docs, but the scanning was done exactly our existing Moodle (v2.7) which means they detect Moodle using SHA1 in our system.  Since we change a lot coding in our Moodle version, so it is impossible to directly upgrade to current version (3.0). 

So I am still not quite sure Moodle 2.7 has any safeguard for SHA1 (either stop using or alternative protection), anyone help? please.

Thanks,

Tanky




Average of ratings: -
In reply to Tanky Tang

Re: About Moodle vulnerability of SHA1

by Davo Smith -
Picture of Core developers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers

I'm not an expert on this, but I suggest you double-check with your vendor about exactly where the SHA1 function is used within Moodle.

It is not, as far as I am aware, used on passwords: the PHP password_hash function is used instead.

It is however, used extensively to provide a unique hash of file content, in order to calculate a storage location for those files. This is not (in any way that I can figure out) a security-sensitive use of SHA1.

I would be interested to be corrected on any of this though ...

Average of ratings: -
In reply to Davo Smith

回應: Re: About Moodle vulnerability of SHA1

by Tanky Tang -

Dear Davo,

Thanks. The vendor is doing Source code scanning, and report there are SHA1/MD5 using in Moodle.

e,g, below PHP pages. (little partial)

/admin/user.php
/admin/userawardpointrule.php
/calendar/export.php
/calendar/export_execute.php
/course/delete.php

We check those files are not being modified by us, so we are not sure how we can deal with it. 

p.s. Our SSL cert has been deployed in SHA256 format.

Thanks,

Tanky


Average of ratings: -
In reply to Tanky Tang

Re: 回應: Re: About Moodle vulnerability of SHA1

by Davo Smith -
Picture of Core developers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers

Well, to take the first example, the md5 hash in /admin/user.php is not used for security purposes, but simply to add an extra layer of protection to prevent accidentally deleting the wrong user (it means the admin user cannot simply change the userid in the URL to delete a different user).

This use of a hash is not designed to prevent a deliberate attack (there are other mechanisms in place to prevent that), but the accidental misuse of a feature, so discussions about how secure or otherwise md5 is in that case are totally irrelevant.

You do not need to change that file, because it has no security implications at all.

If you want someone to go through each and every one of those uses for you, then you are going to need to employ a developer with a good understanding of how Moodle works to check them all. However, I am pretty confident that you will find that none of these 'insecure' hash functions is used in a place whereby they are actually being used as a security measure. The places that matter (password hashing) are already following best practice in terms of secure hashing.


Average of ratings: Useful (2)
In reply to Tanky Tang

Re: 回應: Re: About Moodle vulnerability of SHA1

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

Simply scanning source code for keywords is very little help in assessing the security of a system*, security is a much more complex and subtle business than that. As I mentioned, even given a weak hash that is used on passwords and direct access to the data it is difficult to get passwords out of a system. And by the time you have that access you probably don't need or want the passwords.

*however it is probably very useful for spreading worry and selling consultancy.

Average of ratings: Useful (6)
In reply to Marcus Green

回應: Re: 回應: Re: About Moodle vulnerability of SHA1

by Tanky Tang -

Thanks Marcus,

I understand you point.  As the security scanning is required by our organisation, the report show it is a security hole which doesn't mean Moodle is broken.  We strong believe Moodle has enough protection as the large community and user-base worldwide.  

I just can't find such information so I would ask anyone who know it would help.

I also understand the risk level may not be high, but as a developer, we have to take the report into account in order to provide safe environment as well as System to end user.

Thanks for your reply.  I think if anyone could tell me which version of Moodle stopped using SHA1 is appreciated. 

Average of ratings: -
In reply to Tanky Tang

Re: 回應: Re: 回應: Re: About Moodle vulnerability of SHA1

by Davo Smith -
Picture of Core developers Picture of Particularly helpful Moodlers Picture of Peer reviewers Picture of Plugin developers

There is no Moodle documentation about which uses of SHA1 / md5 in Moodle are security risks for one very simple reason:

  • If there are known security risks in the Moodle code, then they are fixed, before they are announced.
  • If there are unknown security risks in Moodle, then they are not documented, because, obviously, they have to be known in order to be documented.
If you believe you have found a specific security risk in Moodle, then please check it carefully and then report it to http://tracker.moodle.org (but not just a list of all instances of SHA1/md5 in the source code, as that is not helpful to anyone).

If you would like someone to go through each of the reported instances and do a complete security audit on it, then my employers Synergy Learning, or any of the other Moodle Partners listed at http://moodle.com would be, I'm sure, happy to quote a price for doing so.

As already stated, Moodle still uses SHA1 in the source code (in places where it is not a security risk of any kind) - but if you are specifically asking about password hashing, then a quick search in Moodle tracker brought up this ticket: https://tracker.moodle.org/browse/MDL-35332 which suggests that md5 hashing for passwords was removed in Moodle 2.5.


Average of ratings: Useful (2)
In reply to Davo Smith

Re: 回應: Re: 回應: Re: About Moodle vulnerability of SHA1

by James McLean -

Worth linking to the source of the password hashing function: https://github.com/moodle/moodle/blob/master/lib/moodlelib.php#L4425 and you can also use GitHub features to view the changes over time.

I dislike the fact that a 'fasthash' option exists here. I had typed out a breakdown of why I think this - but I've removed it for now in favour of creating a tracker item.

Average of ratings: -
In reply to Tanky Tang

Re: About Moodle vulnerability of SHA1

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

The use of the algorithms is for hashing, not encryption (though the two may seem similar). This means the resultant hash is compared with a password to see if there is a match when the hashing algorithm is run. This means that the actual password is not stored on the system.

If an attacker has access to the user hashes in the database you probably have bigger problems than the strength of the hashing algorithm because they would normally have access to all your data "in the clear". Of course you would still want the best hash algorithm you could have.

Recent versions of Moodle have a system for adding "salts" to hashes which makes them much harder to break as a result. I have spent many hours attempting to break standard unsalted hashes with multi gigabyte rainbow tables and given a non dictionary password I have never managed to break in (and that was either Moodle 2.7 or earlier, so it would have got more difficult since.

Moodle uses hashing for storing file names, but this has nothing to do with security. In relation to Davo's comment the password_hash function accepts a parameter to indicate what algorithm is used and I believe this will depend on the version of PHP being used, you can read about that here

https://docs.moodle.org/30/en/Password_salting

Security is a very complex business. 

Average of ratings: Useful (2)