Home > Moodle > A Critical Moodle LMS Security Vulnerability — All Versions

A Critical Moodle LMS Security Vulnerability — All Versions

November 12th, 2009

EDIT: Start of edit posted on 25 Nov 09…
Moodle releases urgent upgrade notice on Nov 25th, two weeks after this post. To upgrade your Moodle 1.9 or 1.8 branch installs, see the following information.
http://docs.moodle.org/en/Moodle_1.9.7_release_notes
http://docs.moodle.org/en/Moodle_1.8.11_release_notes

If you are among the tens of thousands of people using the 1.7 or 1.6 branches (which, as of today, are still being offered for download on moodle.org), it seems support for those branches has been discontinued and there is no fix for your sites. Upgrading is your only option.
End of edit on 25 Nov 09
——————————————————————–

The embeded video below is a short, to the point, demonstration of a very serious Moodle security/privacy vulnerability that impacts all versions of Moodle. This video is intended to simply demonstrate the exploit. For further detail on the potential extent of this exploit, read the post below this video and see the extended video linked at the bottom of this post. In my informed opinion, aside from the obvious Moodle site security and potential user identity theft issues, this exploit has significant implications on FERPA compliance for all US public education institutions using the Moodle LMS.

If you are a Moodle user at any level, but particularly if you are using Moodle in an educational institution in the US, after watching this video, you may want to have discussions with your network security, FERPA, and/or legal experts on your campus to determine how this may impact your institution and what action you may need to take.

If you are a Moodle administrator, teacher, student, or even if you have ever simply created an account on a Moodle Learning Management System (LMS) site, you need to read this post and watch the videos. It’s no secret that Moodle has suffered from some pretty serious security and user privacy issues over the past few years, but nothing before, that I am aware of comes close to the severity of the Moodle security/privacy vulnerability I discovered a few days ago. In the videos below I will demonstrate the problem and show you how you can verify the problem on your own Moodle site using nothing more than a normal teacher account. I’ll also show you how to patch the vulnerability and will discuss some important implications that you may need to consider after patching your site.

I stumbled across this problem after seeing the following exchange in the developer’s forum on moodle.org.

hash1

I spent 10 years in the 1980’s as a teletype/crypto maintenance technician and although I haven’t kept up with the field, that reply by a core Moodle developer caught my attention. Particularly the last two sentence that read:

“Something that has been encrypted can be decrypted. Something that has been hashed cannot be.”

I think most people know the first sentence is correct, but the last sentence is completely off the mark. The user passwords in Moodle are unsalted, MD5 hashes. MD5 has been proven to be breakable for years now–salted or not. A quick Google search on MD5 gives anyone all the information they need to know about the history of MD5 and its vulnerabilities.  If you want to read up on it, you can start here (http://en.wikipedia.org/wiki/MD5) to get a good overview of the history and vulnerabilities and then follow dozens of other links for Brute Force MD5 cracking sites, like this one (http://gdataonline.com/seekhash.php) as well as more sophisticated methods for cracking MD5 hashes using Rainbow Tables and pre-computation methods…the later, I admit, I don’t fully understand.

So, bottom line…knowing that MD5 is no longer considered secure (and hasn’t been for a long time); and knowing that Moodle user passwords are stored in the Moodle database as simple, unsalted MD5 hashes; then seeing the post above from one of the Moodle core developers and “security experts”…I got curious. The videos below show what I found…you need to watch them.

Click for Extended version of Moodle security exploit video

Click for video demonstration on how to patch your site

Get Noticed with a $7.99 .CO!
  1. Jacko
    November 12th, 2009 at 17:37 | #1

    Holy xxxx Batman. Unbelievable! Thankfully, I don’t use that program. Just curious though. Can you do the same thing in WordPress?

  2. November 12th, 2009 at 18:48 | #2

    @Jacko
    No…for two reasons:

    1. WordPress doesn’t allow a user to download the entire user table from the database…and neither does any other secure program that I am aware of.
    2. WordPress moved away from MD5 password hashing long ago.

  3. ken
    November 14th, 2009 at 17:58 | #3

    Interesting. I’ve tried to replicate but can’t seem to find a site that cracks the md5 hash am using. I saw in the video’s you were using a Windows favored version of Moodle and wonder if it’s the same for Moodle on “other flavors” like Ubuntu, Red Hat Enterprise, or CentOS.

    Thanks, in advance,
    Ken

  4. November 14th, 2009 at 18:08 | #4

    @ken: It’s the same regardless of server environment…I just used XAMPP to demo since I wanted to use fake users and courses…just easier to set that up locally. All you need to do is backup a course on your site with user data, download it and you will see the same thing. Try the following cracking site and be sure to watch the extended video here…I go into a lot more detail in that video.

    http://gdataonline.com/seekhash.php

  5. Bill K.
    November 15th, 2009 at 07:17 | #5

    I just wanted to drop you a line and say a big THANK YOU for this information. And an extra THANK YOU for information about how to fix our site and remove all the backups. One of my teachers sent me the link to your YouTube video yesterday and I’m in the office this morning fixing and cleaning up our Moodle site.

    I had to do a lot of selling a couple of years ago to get our school leaders to trust this software enough to let us use it in our school. This is exactly the kind of thing they were afraid of and I assured them this software was safe. We not only have teacher and student accounts on our site, but we also have parent accounts.

    Now, I’m not looking forward to explaining this to those same leaders tomorrow. I can’t find anything on Moodle about this, so I guess I’m on my own to explain it and to explain how and why it happened. I’m not sure how to assure them it won’t happen again, and at this point, I’m not sure I even want to make that assurance. Thank you again for this information. If you have any suggestions about what I can tell our parents, I’m all ears?

  6. November 15th, 2009 at 09:30 | #6

    You’re welcome Bill. Your site should be easy enough to patch, but dealing with the potential that personal data has already been compromised is the hard part. Maybe Moodle HQ will provide some information to help as soon as they finish covering themselves in this discussion in their own, closed, Moodle Business Partner discussion forums:

    http://partners.moodle.com/mod/forum/discuss.php?d=1340

    When one of their core developers and security experts made it clear in the following discussion that user data in Moodle wasn’t as important as their bank account data, I thought maybe it was just sarcasm…guess not.

    http://moodle.org/mod/forum/discuss.php?d=136085

    I think you’re right to be hesitant to assure anyone of anything about Moodle in the future.

  7. November 16th, 2009 at 16:18 | #7

    My Dutch isn’t that great, but I think I detect a healthy debate…

    http://webwereld.nl/article/comments/id/64296

  8. Flippo
    November 17th, 2009 at 03:24 | #8

    In Moodle grades are registered. A student, let’s call him Murad Jamal, want to know his grades. He becomes a member of the Moodle community, asks his question in the Moodle forum, and gets an answer. Thanks to the community, the exploit is made all clear to him. The student follows the exploit step-by-step, learns his grades, changes them, restores the backup. An unlikely scenario? Looks like a very simple one to me.

  9. November 17th, 2009 at 09:10 | #9

    @Flippo
    Yep, I can see that possibility.

    This thing is like a spider web of possibilities. There is no reason for a teacher to expect that complete user accounts are stored in their course backup files. So, a teacher takes a backup on one Moodle site (maybe your school, college, or business site) and restores it on another Moodle site (maybe some obscure “community” site)…they have just transferred those user accounts, (usernames, passwords and all) to the other site…there could be no malicious intent at all–they just don’t know what they are transferring…endless possibilities here…

  10. NotAMoodleHater
    November 17th, 2009 at 09:40 | #10

    This vulnerability does not exist for secure passwords and for any site using a single sign on system, as Moodle does not store passwords if you are using a SSO.

    Also, you could use the $CFG->passwordsaltmain option in Moodle config.php and set that to something insane. There would be no way for i_+|-|1Nk_U_r_\/\/R0nG_/-\60U+_Th15 plus your password to show up in an md5 lookup site, as that password will never be in a database or added by an end user.

    The password “test” is probably in every md5 database on earth, but add the salt in from above (which the end user has know way of knowing) and the simplest passwords become un-lookup-able.

    It is also painfully obvious that you added Moodle2009 to the md5 site in question as a password tied to the md5 hash that came out of your site.

    I’ve seen folks do this time and again in hopes to drum up attention for a vulnerability that does not exist.

    Should people enforce decent passwords? YES! Should they salt their passwords? YES! But neither of these are Moodle problems. Moodle provides a system for requiring good passwords. It also provides a way to salt passwords. It even does not store passwords within itself if you are using a single sign-on system, which negates the “vulnerability” 100%. It also does not allow you to log in using a manual auth method if your account is tied to an SSO auth method.

    People need to be conscious of these things, but they absolutely do not need to shy away from Moodle because of this trumped up BS.

  11. November 17th, 2009 at 10:48 | #11

    @NotAMoodleHater
    Thanks for contributing to the discussion. Clearly you feel this isn’t a Moodle problem and is only “trumped up BS”.

    We simply disagree.

  12. November 17th, 2009 at 11:57 | #12

    It seems Moodle has responded…it only took a week…well, actually a lot more than a week, but more on that later…

    http://www.mguhlin.org/2009/11/update-on-moodle-inappropriate-access.html

  13. NotAMoodleHater
    November 17th, 2009 at 13:56 | #13

    @figaro

    These dictionary lookups have been around forever and the same can be created for any hashing mechanism. Even if Moodle chose to use SHA-512 or something even tougher, you could still use the same dictionary in the MD5 databases and simply SHA-512 those values and store them. This way you would have exactly the same hack.

    The benefit of SHA-512 of MD5/SHA-1 is that there is a FAR lower of a collision. Collisions happen when two text strings hash to the same value. This would mean “test” and “kzjf” both hashed to the same value and therefore both password would work for authentication.

    This collision rate is the big weakness of MD5/SHA-1 (SHA-1 is good enough for SSL, TLS, PGP, and other “secure” techniques) and this is where any real security vulnerability truly lies, not ones caused by people ignoring all of Moodle’s security features.

    The only way to securely allow logins is to not store the passwords (IN ANY FORM) where end users can get to them. SSO is the way to go in this case.

    If you want to be reasonably secure, require a password policy and salt your passwords with something insane. This simple, documented technique will make them near-un-look-upable.

    Individuals and bots are constantly adding new passwords into these md5 lookup tables and when SHA becomes the hash of choice, those passwords will simply be ported over to the SHA-whatever version of the site.

    If these hashes were not stored in the backups (which they are quite easy to remove from the backup code…only 1 line needs to be commented out), then Moodle would lose one of its unique features…namely the ability to restore a course on another system, and have those restored users automatically recreated with their old password hash so they can login to the new system.

    In other LMS’ you have to manually add the user before doing the restore, or you lose the ability to have them log in without some administrative intervention.

    As far as I can tell, ANY password storing mechanism can be hacked in some way. As for WordPress’ PHPass has been hacked here http://www.markblah.com/2008/06/11/wordpress-phpass-hash-bruteforce-php-script/ and any encryption method of storing passwords is far less secure than a properly salted and hashed method.

    BTW, if you have lots of Moodle users, teachers only see “too many users to list” and they have to search for users to add to their courses.

  14. NotAMoodleHater
    November 17th, 2009 at 14:01 | #14

    BTW. This conversation has generated a ton of publicity and gotten lots of folks talking about Moodle and Moodle security. To most people, security is magic. Hopefully this will open some peoples’ eyes.

  15. November 17th, 2009 at 14:33 | #15

    @NotAMoodleHater
    Okay, some reasonable statements, so let me address a few of them…I’ll add my comments in ALL CAPS just so they stand out–I’m not yelling at you 😉

    1. “The only way to securely allow logins is to not store the passwords (IN ANY FORM) where end users can get to them.”

    I AGREE 100%, BUT IT SEEMS SOMEONE FORGOT TO TELL MOODLE…OR…MAYBE SOMEONE DID TELL MOODLE AND THEY JUST IGNORED IT. WOULD YOUR VIEW OF THIS BE ANY DIFFERENT IF YOU KNEW THAT MOODLE DEVS (AND I’M JUST ASSUMING YOU’RE NOT A DEV SINCE YOU AREN’T REVEALING YOUR IDENTITY) KNEW ABOUT THIS PROBLEM FOR MONTHS AND DID NOTHING?

    2. “If you want to be reasonably secure, require a password policy and salt your passwords with something insane. This simple, documented technique will make them near-un-look-upable.”

    I AGREE, BUT THIS WASN’T DOCUMENTED IN MOODLE ANYWHERE.

    IN FACT, LOOK AT THE ALERT FROM MOODLE THAT WAS SENT OUT TO MOODLE ADMINS TODAY. MARTIN ADVISES ADMINS TO, AND I QUOTE, “TURN ON SITE-WIDE PASSWORD SALTING”…AS IF THERE IS SOMETHING TO “TURN ON”. THERE IS NOTHING TO TURN ON…THERE ISN’T EVEN ANYTHING TO ENABLE/UNCOMMENT IN THE CONFIG FILE. THIS IS LIKE TELLING SOMEONE WHO WANTS WHITE-BOARD CAPABILITY TO JUST “TURN IT ON”…IT’S NOT THERE.

    IF HE WERE BEING HONEST, HE WOULD HAVE SAID “ADD THIS CODE TO YOUR CONFIG FILE TO ENABLE SITE-WIDE SALTING…SORRY WE DIDN’T MAKE IT AVAILABLE SOONER…OUR FAULT…SIMPLE MISTAKE…PLEASE FORGIVE US”…INSTEAD OF TRYING TO CREATE THE ILLUSION THAT THERE WAS SOMETHING TO TURN ON, IF ONLY ADMINS HAD JUST DONE THEIR JOB AND TURNED IT ON.

    I’VE BEEN USING, DEVELOPING, HACKING, INSTALLING, MANAGING, AND TRAINING ON MOODLE EVER SINCE MOODLE EXISTED AND I DIDN’T KNOW ABOUT THIS FEATURE UNTIL NOW!

    3. In other LMS’ you have to manually add the user before doing the restore,…

    YEA…NOT MEANING TO BE SARCASTIC, BUT MAYBE THEY’VE GOT IT RIGHT…

    4. “As far as I can tell, ANY password storing mechanism can be hacked in some way. As for WordPress’ PHPass has been hacked here..”

    OKAY…NOW, SINCE YOU HAVE AN ACCOUNT ON MY WORDPRESS SITE HERE, DOWNLOAD MY DATABASE USER TABLE AND HACK THE PASSWORDS…SEE WHY THAT’S AN IRRELEVANT COMPARISON?

    5. “BTW, if you have lots of Moodle users, teachers only see “too many users to list” and they have to search for users to add to their courses.”

    YOU’RE WRONG! AT THE RISK OF REVEALING ANOTHER MAJOR SECURITY ISSUE, ALL YOU HAVE TO DO IS START TYPING VOWELS, ONE AT A TIME, (A, E, I, O, U) AND HIT SEARCH AFTER EACH……GIVE IT A TRY.

    Now, back to normal type. I appreciate you coming here and engaging in this discussion. If these kind of discussions were allowed to happen on moodle.org without people being banned, ostracized, and having their accounts deleted, then maybe, just maybe Moodle HQ could avoid this kind of embarrassment in the future…

  16. November 17th, 2009 at 14:35 | #16

    @NotAMoodleHater
    I know it’s being discussed a lot…and that’s a good thing, in my opinion. It may be painful for Moodle HQ, but, in the end it will end up making Moodle better for all.

    By the way, you seem to know what you are talking about. I have no problem with you posting here anonymously, but I’ll treat you just the same here if you post with your real identity…can’t guarantee how you will be welcomed in moodle-land though…

  17. NotAMoodleHater
    November 17th, 2009 at 16:46 | #17

    I don’t set up Moodle sites without thinking about things like password policies, authentication methods, password salting, hashing methods, storing or not storing passwords. I’ve only been using Moodle for a short time and the idea of not using a salt or setting a password policy never crossed my mind. These things are standard things to think about when securing any system. Moodle is no exception.

    BTW If you look at backup/backuplib.php about line 1299 (or search for user->password), you can remove this ‘vulnerability’ from backups 100% by placing a # it and any other user data you might want removed. Password is not required for a restore. This took me less than 1 minute to find and 2 more to test the change. Maybe letting MoodleHQ know about the discovery and sending them a proposed fix would have been much more appreciated than placing the ‘vulnerability’ in the wild without so much as a how-de-do.

    Most instructors would freak out if you didn’t allow them to enroll users into their courses.

    If there was to be a ‘fix’ added into Moodle for this, it should be a setting in backups for the administrator to choose to store the hashes in the backups or not. They are not needed unless you are moving your backups to a new Moodle instance.

    Moodle is not a hammer. It is not a simple tool. It is a complex learning management solution and implementations need to be planned and thoroughly thought through. As do ALL complex systems.

    As far as the anonymity thing. I like my privacy. I wouldn’t advertise that it’s ok to hack your wordpress site. It’s not exactly known to be the most secure blogging platform out there.

  18. November 17th, 2009 at 18:32 | #18

    @NotAMoodleHater
    Thanks for the info.

  19. Joe
    November 18th, 2009 at 12:24 | #19

    @figaro
    How about more on the Moodle delays sooner? Did you try to work through the appropriate security.moodle.org practices before releasing to the Internet? If you did, thanks. If you didn’t try the appropriate channel, while I agree that you’ve made an important point, frankly, you did it in a jerk way.

  20. November 18th, 2009 at 13:18 | #20

    @Joe
    I’m not sure what you mean about “more on the Moodle delays sooner?”

    This issue has been on the internet for years. It has been discussed in the moodle forums for years…just search moodle.org for MD5. It has been in moodle tracker for months…open on the internet for anyone who wanted to look. All I did was demonstrate a problem that was well known to moodle devs for a very long time.

    My intent was to bring attention to something that I think Moodle users need to know. You can’t fix your site if you don’t know you have a problem. If I’m a jerk for that, so be it. But while you’re calling me a jerk, consider this…

    I warned people about this on Thursday, the only way I could (I don’t have email addresses of moodle users) and told them how to patch their sites at the same time. It took Moodle nearly a week to send out a notice telling people essentially the same thing I told them a week earlier. If moodle is really concerned about you, why didn’t they send out a notice to their registered users immediately?

    I didn’t create this issue last week…I just informed people about it last week. To my knowledge, it has been an issue since moodle has existed…8, 9 years? It’s only been a secret to the average moodle user/admin.

    To believe that moodle did not know about this, you would have to discount the discussions about MD5 in moodle’s own forums for years now, you would have discount the tracker issue filed months ago, you would have to believe moodle devs didn’t know MD5 wasn’t considered secure, and you would have to believe moodle devs don’t know what is included in their own back-up scripts and/or that teachers can download those back-ups.

    I don’t believe any of this…moodle devs are smart people.

    I can’t answer why nothing has been done about it until now, but don’t tell me it wasn’t known.

    Had I not told you, you still wouldn’t know and your data may still be at risk. You can’t, in my opinion, treat open source software as if it’s closed source. If there is a problem, you have got to tell people and you have got to do it quick, precisely because the code is open! I made public something that moodle users needed to know to protect their data and their sites and I showed them how to fix (patch) their site.

    Contrary to what some may believe, I have no interest in harming Moodle, but my main concern was not Moodle’s image…I did it in the interest of helping people secure their sites.

    This is an exact repeat of the profile spam issue. Thousands of Moodle sites were infested with vile profile spam, needlessly, because they weren’t informed of a known problem for months until the issue was made public outside the confines of moodle.org.

    I’m really not sure what Moodle’s established security notification procedure is, but it didn’t work in the profile spam case as was very clearly pointed out in the second UK news release…quote:

    “The software is used by 27 million people worldwide, but only 45,000 are officially registered, so it is difficult for Moodle.com to alert everyone.”

    Source: http://www.tes.co.uk/article.aspx?storycode=6008670

    Let’s also not forget that “officially registered” only means someone, anyone installed moodle and clicked the button to register. To my knowledge, there is no verification of a “registered users” identity, so Moodle has no idea who those “advanced” security notices are really being sent out to…you think there may be a “registered” hacker or two in the bunch? All we do know, is that “notice” from Moodle is getting out to about 0.001666% of the users based on Moodle’s own figures. Putting this out on the internet at least gives everyone a fighting chance to fix their sites.

  21. November 19th, 2009 at 09:13 | #21

    Just an update on some of the action as a result of this publicity. Very late, but a positive step in the right direction.

    Moodle Doc created two days ago explaining password salting and providing the code to add to the config file.

    http://docs.moodle.org/en/Password_salting

    Forum post on moodle.org, today, asking for help in translating the new password salting doc.

    http://moodle.org/mod/forum/discuss.php?d=138268

    On another note, Moodle Tracker Issue MDL-18807 posted to tracker on 7 April 2009 seems to have gone missing. It was available and open to the world from 7 April through about 3 days ago. Anyone know what happened to it?

  22. Joe
    November 19th, 2009 at 10:20 | #22

    What I meant is that, in post 12, you say “It seems Moodle has responded…it only took a week…well, actually a lot more than a week, but more on that later…”, and I was asking for more details sooner.

    Which you provided, and thanks!

    I agree with you, in fact, that Moodle has known for some time that (a) they should upgrade from MD5, and (b) they shouldn’t be caching passwords. And those issues seem to have been ignored for long enough that escalating to the court of public opinion is probably warranted.

    But I’m not aware that the issue of Admin accounts being exported with course user data was known before this, and that’s a new security hole. Now, if that was on the tracker and being ignored for 7 months, then I was underinformed and maybe you did the right thing. But if the tracker reports were only about passwords generally, I think you were wrong not to give the community a chance.

    (7 months is a guess, since MDL-18806 and 18808 are from early April.)

    You say yourself that you aren’t really sure what Moodle’s security notification procedure is – and I think any professional in information or instructional technology has a responsibility to understand established security procedures before violating them. I tend to agree with you that there’s a point where information like this has to get wide distribution – what I’m not clear on (especially since you spend a lot of time talking about what you “believe” other people know) is that you reached that decision in a responsible, professional manner.

  23. November 19th, 2009 at 10:54 | #23

    @Joe
    Thanks Joe. If what you are basing your judgment on is MDL-18806 and MDL-18808, then I can understand your point of view. I had never looked at those two reports before just now…I agree…nothing there related to this issue.

    However, have you seen MDL-18807?

    I have…initially found it through Google with a simple MD5 search. It was available to the world until just a few days ago. It’s all of the sudden, no longer available.

    Just based on past experience, I expected things would start “disappearing”, so I have it screen captured. Again, my intention was/is to help Moodlers become aware of a real problem that has been known and discussed for months so they can protect themselves and fix their sites…it was not/is not to hurt Moodle.

    Ask Moodle if you can see it MDL-18807…a simple request in the moodle.org security forum should do…its been available to the world for 7 months…I see no reason it shouldn’t still be available.

    If they deny it exist, or don’t give you a good reason for why it was public for so long, but shouldn’t be public now, then I’ll publish it. But, my publishing it would only result in “bad old me” punishing Moodle.

    I’ll give them the opportunity to fess-up to knowing about this first. It’s my hope that they will fess-up to what was known and accept responsibility. We’ll see.

  24. Joe
    November 19th, 2009 at 11:53 | #24

    I haven’t seen MDL-18807 – I’m just saying that, logically, the serial number suggests it existed for 7 months before its disappearance last week. Again, if you look at http://moodle.org/security, you’ll see the statement that

    “Bugs classified as a “Serious security issue” will be hidden from the general public until the security team (led by Petr Skoda) is able to resolve it and publish fixes to registered Moodle sites.”

    I’d expect to see MDL-18807 “declassified” as soon as Moodle 1.9.7 comes out. My understanding is that this is a best practice among security professionals. It puts the white hats a couple of steps ahead of the black hats. Sure, as you point out, we don’t know that the official “registered” users are a high percentage of actual installs. But shouldn’t active, registered users get preferential treatment? Isn’t that right? Isn’t that how you encourage the growth of a productive open source community?

    (I think, by the way, that “27 million users” and “45,000 registered sites” is apples and oranges. A silly set of numbers for Moodle to throw out there. We have over 4,000 users on our Moodle, but it’s only 1 registered site. And only 3 of those users could actually take any useful action regarding this threat.)

    Although again, just based on the serial numbers, I’m annoyed that it took 7 months for them to agree that MDL-18807 (whatever it says) is a “serious security issue.”

    I don’t see you doing anything designed to hurt Moodle, and I don’t mean to imply that. I do see that you and I agree on one thing: Moodle has taken too long to deal with issues of password exporting and hashing.

    I also see that we disagree about whether the security community is right or wrong about best practices in general. I believe that, as a professional, you have a responsibility to try to push through appropriate channels before taking major holes like this to the next level – even if other people have already tried it. You haven’t documented anything to say that you personally did that – and you’ve implied that you don’t think it’s a best practice. So, as Vezzini would say, we are at an impasse.

  25. netbuoy
    November 19th, 2009 at 11:58 | #25

    Gee, Joe, what did you think was being discussed when the talk centered on Moodle only being as secure as the least trustworthy teacher? Are you suggesting that the dev responsible for course backup didn’t know what back up all did? That’s the kind of talk that got someone banished from the moodle community-lol! And I don’t think you’ll see any mea culpa in the fora either.

    I suggest you review the arguments of Petr and others to the effect that education is not like banking and moodle Trusts teachers. Faced with a hypothetical choice between believing that devs are incompetent or arrogant what would you do?

    However, you r I think correct that the defect if any is really in backup NOT in password. While salting may improve code technically, it also serves to once again lull users to sleep re appropriate general security measures….. After all, it’s not like we’re talking about money here…

  26. November 19th, 2009 at 12:42 | #26

    @Joe
    “I’d expect to see MDL-18807 “declassified”…”

    How can you “classify” something that has been sitting out in public for 7 months? That’s like me removing this video from YouTube and saying, sorry, it’s now classified.

    Looks like we are at an impasse, but if my “unprofessional” conduct helped you secure your site…you’re very welcome. Read MDL-18807 one of these days when it’s “declassified”.

  27. November 19th, 2009 at 12:48 | #27

    @netbuoy
    Hello Netbouy…I’m not sure “Joe” really wants to dig too much…sounds like his/her mind is made up…

  28. Joe
    November 19th, 2009 at 14:49 | #28

    @figaro

    figaro :
    @Joe
    “I’d expect to see MDL-18807 “declassified”…”
    How can you “classify” something that has been sitting out in public for 7 months? That’s like me removing this video from YouTube and saying, sorry, it’s now classified.
    Looks like we are at an impasse, but if my “unprofessional” conduct helped you secure your site…you’re very welcome. Read MDL-18807 one of these days when it’s “declassified”.

    I disagree. I think it’s like someone with swine flu being quarantined so they stop spreading the germ. Sure, it’s bad that they wandered around for a few days, but it’s better when it stops.

    Maybe it’s all academic – once the exploit is public, there’s little value in adding security so you might as well leave it alone. Or maybe you follow best practices anyway, because there’s value in them.

    And you did help me secure my site, and genuinely, thank you for that.

    And Joe is honestly the name my parents gave me. No need for quotes, “Figaro.” 🙂

  29. Joe
    November 19th, 2009 at 14:59 | #29

    @netbuoy

    Look, I’m in agreement that this issue highlights some serious problems in Moodle’s approach to security. Sure, “education is not like banking”, but it’s still mission-critical for the institutions that do it.

    I also know that people who actually do development, or even, like me, give a damn about how it’s done, understand that there are proper procedures to follow, and that random veiled comments on discussion boards aren’t part of them.

    What I’m suggesting is that the Tracker probably has an immense amount of power in deciding what gets worked on and what doesn’t. There’s a time and place to violate procedure, of course – and as soon as anyone can tell me they themselves tried to follow procedure by writing or voting on or commenting on formal Tracker issues, I’ll stop calling names.

    Until then, it’s not “calling names”, it’s being linguistically precise in describing behavior. 🙂

    @figaro, regarding whether I’m willing to dig – I’m interested in digging out right now, figuring out what is broken, and how much, and how to fix it for my install. And again, I recognize that it’s your impetus that’s made my install more secure than it was Monday morning, and thanks again for that.

    What I’ve dug through so far (in terms of the Moodle discussion history) has mostly been an unhelpful morass of opinion (on both sides), not usable facts. If you think something more will clarify for me, point me to a specific post.

  30. November 19th, 2009 at 18:20 | #30

    @Joe
    If you think something more will clarify for me, point me to a specific post.

    As I’ve said, MDL-18807 is what you are missing. I could publish it, but there is no need…let’s be clear…Moodle HQ has not denied knowing about this. In fact, the “alert” sent out a few days ago, so much as admitted knowing about it by saying:

    Moodle development policy has always generally been “we trust teachers”.

    Well, so do I, but I don’t trust them with my bank account information.

    However, if you want to see the origin of MDL-18807, take a look at this thread:

    http://moodle.org/mod/forum/discuss.php?d=120180

    What else is there to say? If someone really needs to draw a picture of the problem, then maybe my video is the picture.

    I’m baffled as to what you think moodle devs didn’t know? Are you really suggesting that you think they didn’t know course backups included the complete user table for everyone in the backup?

    For what it’s worth…the security reporting procedure IS to report issues to tracker. One more time — MDL-18807 may shed some light on this for you. You comment here…which is appreciated, but you haven’t asked to see that issue yet, have you?

    By the way, you’re welcome and I do believe your name is Joe…apologies for my sarcasm earlier.

  31. November 19th, 2009 at 18:28 | #31

    @Joe
    I disagree. I think it’s like someone with swine flu being quarantined so they stop spreading the germ.

    Let me understand this…my video helped you secure your site. Are you suggesting I now “classify”/remove it…forget about anyone else who may still be in the dark? You got your flu shot…to heck with everyone else?

    Do you really think that belated email moodle sent out has informed everyone who needs to be informed? I talked with a moodle admin (a furious moodle admin) today, who is on the registered users list to receive those notices and he didn’t know anything was sent out…he’s the second one on the mailing list I’ve spoken with who didn’t get the mail. Why? It seems it may have been marked as “low priority” and was caught by his spam filter…lots of filters do that with things marked “low priority”.

  32. Joe
    November 20th, 2009 at 09:31 | #32

    Thanks for the link to the thread about MDL-18807. Based on that thread, I don’t actually believe it addresses the core security hole. _Passwords shouldn’t be in the course backup at all._ Not plain text, not MD5 hashed, not hashed and salted, not AES-256. There’s simply no valid use case I can imagine for having that data in a course backup in any form. Again, here’s a point where we fundamentally agree – Moodle HQ has an approach to security which simply doesn’t meet our criteria. The email Moodle sent out suggests that 1.9.7 will address this core problem, not the symptom (a crackable algorithm) which MDL-18807 seems to highlight. Salting is a band-aid, not a solution.

    Now that the exploit is public, it seems that there’s little benefit in keeping the information secret. I see your point. But yes, as a matter of fact, I think you should remove the video pending the release of 1.9.7. My site is not “secure” – it’s “more secure than it was.” We don’t have the programming expertise to address the core issue; that’s going to have to come through an upgrade.

    This isn’t about what the Moodle developers knew or didn’t know. It’s about what the actual most effective way is to get the news out to the people who need it. It’s about the huge amount of disconnected work that your approach has caused in the community, when I’m hopeful that many of these issues will be handled centrally by the release of a critical security patch/point release.

    Again, it’s possible – even probable – that it was justified to force Moodle’s hand in this case. 7 months is too long for this kind of hole, and maybe Moodle deserved a kick in the pants. But what I’m seeing is not the informed action of a contributing member of the community, but a rash decision by someone who isn’t really informed about the development process. I’ve asked you repeatedly about how _you_ handled it, and you’ve repeatedly pointed me to _other people’s_ posts.

    I don’t think Moodle is responsible for making admins read their email. I know that some communities of admins shared this message with each other, to make sure fewer people missed it. And surely you don’t think your site “informed everyone who needs to be informed”, do you?

  33. November 20th, 2009 at 10:55 | #33

    @Joe
    Thanks for the link to the thread about MDL-18807. Based on that thread, I don’t actually believe it addresses the core security hole. _Passwords shouldn’t be in the course backup at all._ Not plain text, not MD5 hashed, not hashed and salted, not AES-256

    Well then, it sounds like YOU need to be filing some tracker issues and making your case in the forums…have you?

    But yes, as a matter of fact, I think you should remove the video pending the release of 1.9.7.

    Okay…here’s what I’ll agree to do. If Moodle HQ asks me to remove it, then I will. But, I haven’t been asked and don’t expect I will be.

    This isn’t about what the Moodle developers knew or didn’t know.

    Disagree. It has everything to do with what moodle devs knew and didn’t know…and what they did and didn’t do.

    Again, it’s possible – even probable – that it was justified to force Moodle’s hand in this case. 7 months is too long for this kind of hole, and maybe Moodle deserved a kick in the pants.

    There is a point where we are in 100% agreement.

    But what I’m seeing is not the informed action of a contributing member of the community, but a rash decision by someone who isn’t really informed about the development process. I’ve asked you repeatedly about how _you_ handled it, and you’ve repeatedly pointed me to _other people’s_ posts.

    I’m far more informed than you realize. The reason you don’t see me as a “contributing member of the community”, is because I was banned from the community by the lead dev himself for pushing issues just like this. I suppose I could have gone knocking on the door pleading for someone to listen to me, but I don’t feel moved to do that.

    You have repeatedly tried to make this about the messenger instead of the message–been there, experienced that, have the scars to prove it.

    Okay, Joe…we’ve had good exchanges for the past few days. We’ve disagreed, but I haven’t questioned your professionalism, or your commitment/contributions to the community you seem to care so much about. So, time to man-up…what is your identity on moodle.org?

    I would simply like to see how much of an “informed, contributing member of the community” you are.

  34. netbuoy
    November 20th, 2009 at 11:36 | #34

    Joe,
    As with profile spam, this was considered a feature, and it is as it allows me to backup a course including all user data and move the course and have all that user data intact- but there is no such thing as a free lunch. Last I counted there were less than a handful of regular contributors at moodle.org that felt this issue deserved any attention. Martin didn’t respond here but on Miguel’s blog where it followed some name calling as I recall. Moodle evangelistas continue to harp on their claim that Moodle is as easy as falling off a log; but while it may be my LMS of choice, it’s not all that simple to administer….. Remember, its a moodle core dev that said it wasn’t as if money was at stake, not me…….

    Short term? Just kill backup rights of teacher and course creator and use an admin password such as I have described (phrase with substitution) making sure that anyone with admin rights follows suit. Implement a forced password change for users and if your students are
    minors use this opportunity to teach about trusted community and Internet security.

  35. Joe
    November 20th, 2009 at 11:41 | #35

    That’s a fair question, and I’m JoeMurphy on moodle.org. I’ll tell you now that you’ll see a lot more votes than comments – I’m not a developer myself, but I participate in discussions as someone in user services.

    That said, if something in the past has limited your ability to follow the process, I can see why you have to go another way. Sounds like an unpleasant and unproductive situation for all involved – I’m sorry for those scars.

    I do, as a matter of fact, think that messenger and message are both important. You’re modeling a kind of behavior in reporting bugs here, and the context that you’ve personally tried and failed to get them recognized is important. Sorry, there’s that “user services” mindset instead of “developer”. 🙂

    And yes, I am working on replicating issues so we can enter useful tracker reports about the fundamental problems with the course backups. I expect them to be treated as significant security issues and made invisible until patched. 🙂

  36. November 20th, 2009 at 11:51 | #36

    @Joe
    Thanks Joe…good luck with the tracker issues.

    Based on the advice of a good friend and one of the few independent thinkers still willing to post independent thoughts on moodle.org, I think it’s time to close this thread…its about run its course.

    My offer to remove the YouTube video, and make this post unavailable until some point in the future, IF I’m asked to do so by the Moodle Lead Dev., stands.

    Thanks to all for a good discussion…try having these on moodle.org from time-to-time and, although messy and sometimes even ugly, Moodle will benefit!

  1. September 6th, 2010 at 11:43 | #1
  2. November 10th, 2010 at 14:51 | #2
  3. February 6th, 2011 at 09:47 | #3
  4. January 16th, 2012 at 14:13 | #4
Comments are closed.