My web account hosting moodle has been suspended due to sending out spam - it just happened and I am trying to get details, but this is all I know so far. I am getting my account re-enabled but they don't want me to enable web access until I "resolve the issue" - which is kinda hard since I haven't a clue what the issue is.
"The user account in question may in-fact be victim to one or more compromised 3rd party web applications ( such as, but not limited to Forum and Blogging type software )."
My question here is - could moodle be the culprit, and if so what can I do? I can upgrade to 1.8 (currently using 1.7) and also change to PHP 5 (scheduled to come online in my server soon but I can opt for it now)
I don't have other forums or blogs - Coppermine Photogallery is the only other"community" type PHP script I am using now and I can shut those down for the time being if I have to.
Any advise would be greatly appreciated!
In reply to Maureen O'Halloran
Re: 3rd party spam exploit possible? Help please!
by Mauno Korpelainen -
Check this first: http://moodle.org/mod/forum/discuss.php?d=88509
Did your host give you any more information about what kind of spam you are suspected? Spammers may use user profiles for spam if you let bots/spammers to log in but it would help alot if your host could show you or you could find yourself for example Apache server logs (auth, error, mail and access logs).
The situation is much worse if the reason is something like
http://coppermine-gallery.net/forum/index.php?topic=48106.0
If your site has been hacked and it already has some backdoors installed it may be hard to find all malicious worms - it may be easier to start a new site (and restore courses from backups).
Upgrading all programs regularly to the latest stable versions is recommendable.
In reply to Mauno Korpelainen
Re: 3rd party spam exploit possible? Help please!
by Maureen O'Halloran -
We don't have any courses that don't have enrollment keys and the number of users is small enough that I can look for suspicious looking usernames.
It sounds like Coppermine is more likely - I can get rid of all my galleries that are not recent. (The galleries are used in classes and I can probably elliminate all the ones earlier than this semester).
I will try to find more about getting logs from my host - thanks
It sounds like Coppermine is more likely - I can get rid of all my galleries that are not recent. (The galleries are used in classes and I can probably elliminate all the ones earlier than this semester).
I will try to find more about getting logs from my host - thanks
In reply to Maureen O'Halloran
Re: 3rd party spam exploit possible? Help please!
by Maureen O'Halloran -
I just realized that having enrollment keys doesn't prevent creation of accounts - but I do require email confirmation and don't allow duplicate emails.
Is there anything else that can be done to prevent bots from enrolling?
Is there anything else that can be done to prevent bots from enrolling?
I had this exact same thing happen to me. I found that our hosting account was suspended on Christmas morning, of all the perfect times!
Not being an expert on hacking I still don't understand the how/why, but from what my hosting tech support explained, someone was creating false user accounts on my site, and somehow sending their spam in connection with the Email verification that my site sends out. They wouldn't restore my site until I 'stopped' that, and I wasn't sure how to even do that.
Ends up that I changed authorization from Email to manual, and now people have to email or call me directly and request a user account before they can enroll in a course. This is NOT ideal, but I'm almost ready to upgrade to 1.8.4 and I'm expecting to be able to automate enrollment again when I do. (Currently the site is 1.5.2)
On Christmas day when this first happened, there were almost 350 users created in a short time before the host cut it off. Over the few weeks since then, some of those fake usernames have been hit on regularly, so who/what ever did it is still out there - but I don't understand what they were doing in the first place so I don't know how to make it stop.
So Maureen, you're not the only one to see this. And it's not your photo gallery... If anyone else has more info, I'd appreciate it too!
Dan
Not being an expert on hacking I still don't understand the how/why, but from what my hosting tech support explained, someone was creating false user accounts on my site, and somehow sending their spam in connection with the Email verification that my site sends out. They wouldn't restore my site until I 'stopped' that, and I wasn't sure how to even do that.
Ends up that I changed authorization from Email to manual, and now people have to email or call me directly and request a user account before they can enroll in a course. This is NOT ideal, but I'm almost ready to upgrade to 1.8.4 and I'm expecting to be able to automate enrollment again when I do. (Currently the site is 1.5.2)
On Christmas day when this first happened, there were almost 350 users created in a short time before the host cut it off. Over the few weeks since then, some of those fake usernames have been hit on regularly, so who/what ever did it is still out there - but I don't understand what they were doing in the first place so I don't know how to make it stop.
So Maureen, you're not the only one to see this. And it's not your photo gallery... If anyone else has more info, I'd appreciate it too!
Dan
Dan,
you can't be sure it is not Coppermine - but if you find many links to your site with google searching the name of your site and "user/view.php" then that spam is related to your site user profiles (abused)
http://moodle.org/mod/forum/discuss.php?d=87155
http://moodle.org/mod/forum/discuss.php?d=87345
http://moodle.org/mod/forum/discuss.php?d=88114
http://tracker.moodle.org/browse/MDL-12738
http://tracker.moodle.org/browse/MDL-3173
In reply to Mauno Korpelainen
Re: 3rd party spam exploit possible? Help please!
by Mauno Korpelainen -
...and it is good to read these to links too:
http://docs.moodle.org/en/Security
http://secunia.com/search/?search=moodle (old vulnerabilities - also a good reason for regular upgrading)
In fact most administrators - especially from old moodle 1.5-1.6 sites - do not know how large problem this is. Locking or deleting user profile fields/description fields or preventing self registration may help but the number of spam links pointing to moodle sites has grown about 50% since december and if there have sometimes been abused user profiles in your site the links remain in spammers databases and open guestbooks and forums they use for sending spam link lists (not on your server) for a long time. And as long as some users continue clicking those spam links (that site administrators are not aware) the chain of spam continues - spam creates new spam and money for spammers.
Mauno, I've followed every relevant link that I could find from your messages this morning (and learned quite a bit) but I still have some questions...
Dan
- My site doesn't include any Forum, Blog, or anyplace for users to post info that would be useful for SPAMers to advertise. What exactly is the point of creating the fake usernames? I was told that the verification Email that Moodle sent out was used somehow to send the SPAM - but how is that?
- Is the problem existing in all Moodle installations, or can it be prevented by upgrading to the latest version?
- It would seem simple to eliminate BOT's from creating users by using a CAPTCHA for signups, and I saw that referenced in at least one of the forum threads, but I didn't see anything about an existing patch/hack. Has anyone come up with this and made it available yet?
Dan
I've dealt with this on a couple of sites in the past week. This isn't your normal spam that is done automatically...there is a lot of human intervention here. From what I can gather:
1. The spammer finds a moodle site that allows account creation and email verification...lots of those out there
2. They manually create their account and verify it
3. They they seem to immediately go to the account profile and change the email address used to create the account...pretty smart actually, since Moodle does no require that a change of email be verified at the "NEW" address entered which allows someone to use a single email account to create an unlimited number of these spam accounts. Some people believe the spammers are using accouts like "mailanitor" to create these, but they can create a moodle account, change the email in the profile, and then use that same email address to create another account, allowing them to use any single email account to create as many moodle accounts as they want.
4. They enter their spam (long list of Pharmacy/Viagra links) in the profile description field. This gives them an automatic webpage that they can now use in their other spam emails.
My experience has been with two different 1.6 installs, but it seems to me the same exploits can happen in any version. So, what can you do?
1. Don't allow email account creation on your site (Not an option for many).
2. Set your site so that users must be logged in to see profiles. (You would think this would limit the value of using a profile for spam, but evidently the spammers aren't smart enough to check that since both sites I found this type spam on required users to be logged in to view profiles).
3. Remove users ability to use the "Description" field in the profile on the site. (This is what I did on both sites. By doing what I describe below, you will delete any information in the description field for all existing users on your site and prevent any new users from entering any useful information in that field).
To disable the ability to enter information in the profile "description" field in Moodle 1.6 -- Not sure about later releases -- I did the following.
1. Opened my database using phpmyadmin
2. Selected the mdl_user table
3. Opened the "description" field to edit the default values
4. Changed field type to CHAR
5. Set Length/Values to "1"
6. Set Default value to "1"
Saved.
Since this field is a required field, now when an account is created it will be automatically populated with the number 1. For all information currently entered in this field for existing accounts, only the first letter will show. If anyone updates an account, they can type as much as they want, but only the first letter will be saved.
Of course, you lose this field for your users, but it doesn't do the spammers any good either.
Disclaimer: This seems to work on the two sites where I applied it, but use at your own risk. Also, there may be easier and/or better ways to deal with this, but since the description field is not critical on the sites I dealt with, this seems to be an effective solution.
Steve
Good answer, Steve!
http://tracker.moodle.org/browse/MDL-7407 - still human spammers can pass captcha. In moodle 1.8-1.9 you have a little more possibilities to control traffic and registration so upgrading may be worth trying.
The point is that moodle sites (user profiles) are just free web space for saving links to nasty pages - user profile that is open to google is like a free web page that can contain any links to illegel sites. Such open sites that nobody has used for a long time or really big sites with many users are ideal to hide some extra users. Most likely bots create different link lists and submit them to guestbooks and forums - searching with "user/view.php" gives you both moodle site user profiles and those link lists pointing to moodle sites. I suspect (like Steve) that human spammers select the content to user profiles - those unused bot profiles may be just test profiles that tell spammers how different sites react.
This whole spam business is something really rotten - nobody wants to buy any products or services from those links but every time somebody presses a spam link he/she possibly creates a new spam wave - or gets trojans etc. The main purpose is not to send ads but to steal identities, usernames and passwords, next steal servers, mail servers or even name servers to be able to create new fake email addresses, servers and so on. And spammers try to open any possible route they can think...
But I just noticed something - the reason why most attacked sites are old sites (using moodle 1.6 or moodle 1.5) might be exactly that setting forceloginforprofiles
In moodle 1.6 Administration -> Configuration -> Variables
and under Permissions
SET forceloginforprofiles: Yes
Enable this setting to force people to login as a real (non-guest) account before being allowed to see the user profile pages. By default this is disabled ("false") so that prospective students can read about the teachers of each course, but this also means that web search engines can see them.
In moodle 1.7-1.8-1.9
Administration -> Security -> Site policies
SET forceloginforprofiles: Yes
Enable this setting to force people to login as a real (non-guest) account before being allowed to see the user profile pages. By default this is enabled ("true")
For most cases this seems to be enough to keep anonymous visitors away from user profiles (as Martin already said in tracker). If somebody could just tell it to those thousands of moodle sites using moodle 1.5 or 1.6 
It does not delete old links and user profiles inside moodle (administrators should check profiles manually) but at least it restricts straight access to user profile pages from spam links.
This is making a little more sense all the time... Mauno and Steve - I really appreciate your information and explanations!
My site really needs to be set up for Email authentication. It's sounding like that may be safe, as long as I make sure that forceloginforprofiles is set to yes. (My production site had this set to 'no' at the time of the attack.) Someone may still make phony users, but it will at least be a waste of their time.
Does this sound correct?
Thanks,
Dan
My site really needs to be set up for Email authentication. It's sounding like that may be safe, as long as I make sure that forceloginforprofiles is set to yes. (My production site had this set to 'no' at the time of the attack.) Someone may still make phony users, but it will at least be a waste of their time.
Does this sound correct?
Thanks,
Dan
Yes and it is also possible to lock field Description at least in moodle 1.6-1.9 (I don't have moodle 1.5 to check but it might be possible there as well) from
Administration -> Users -> Authentication options
It does almost the same as Steve's suggestion (the field can't be edited) but it is easier to change the setting from administration menu if you need to change description for some users and lock it again.
In reply to Mauno Korpelainen
Re: 3rd party spam exploit possible? Help please!
by Ben Christopher -
Hi there,
i have 2 sites on my host server and i realised that someone has hacked into my non moodle site. i have deleted the "online" directory where they had kept their link and i have been advised to do the following:
Chmod all folders to at least 755 (check with the moodle devs if that is ok)
Chmod all files to atleast 644 (again, check this with the devs).
as far as i can see, most files/directories have these settings anyway.
in addition, i was advised to:
Remove / rename install.php
Is this recommended?
also in admin/users/manual accounts and email based selfregistration - i have set "description" to locked - as advised above.
is it worth also disabling Email-based self-registration (Administration
/ ► Users / ► Authentication / ► Manage authentication)any help, as usual. greatly appreciated
ben
The statement from your host may give a clue. 'Forum, Blogging' unless your users have their email addresses hidden and disabled then it would be possible for email messages to be sent out from moodle when a post is made to a forum or blog or gradebook.
Just a thought, some ISPs, hosts etc. may consider it to be relaying.
Ian
Thanks all - in my case it did turn out to be the Coppermine photogallery - but this information about moodle is very helpful.
I read the host's statement about "Forum, Blogging" to mean that any application that allows users to create accounts and make posts has a potential for vulnerability.
I read the host's statement about "Forum, Blogging" to mean that any application that allows users to create accounts and make posts has a potential for vulnerability.
I'm working in 1.7 and I was curious is there a way to completely disable user emails, just in case a spammer decides to post something in forums?
Regards