Dear all,
I was told that our Moodle site is very slow, so I took a look at the home page source code, and found a lots of malicious javascript code had been added to the index page.
I tried to figure out where the code is located, but I couldn't find out where I can modify the java script that was loaded in the home.
Can any of you give me some ideas?
Many thanks
First, I suggest you take steps to isolate your server from the web, because the door that the hacker used to access your server is probably still open.
Next, we need to determine which files have been hacked.
Regarding the index.php file that you shared, it seems fine to me.
The indentation of every line of code indicates that that you are using Moodle <= 2.8.
The presence of the call to "redirect_if_major_upgrade_required()" indicates you are using Moodle >= 2.0.
However, notice that index.php includes config.php. That file, config,php, includes a great number of other files, including all the theme files and Moodle library files. Probably it is one of those secondary files that has been hacked.
The next three files I would check on your Moodle site are as follows:
Where "YOURTHEME" is the theme that you are using on your Moodle site.
If that search does not reveal anything suspicious, I would try to determine which Moodle files have been recently modified. Depending on what kind of access you have to your server, you may be able to login via SSH and use the Unix "find" command to find recently modified files.
For example, the following Unix command finds all the files modified in the last 30 days:
find /PATH/TO/MOODLE -type f -mtime -30 -ls
Finally, you should take steps to prevent the hacker coming back. Probably this requires removing write access from everything in the folder containing Moodle scripts.
Thank you very much. Gordon.
I can't find anything suspicious in the config files.
Can you have a look for me?
I found many Moodle files had been modified, sigh...
Dear Louis,
As Ken notes below the index.php was NOT OK.
Line 1 contained the inserted PHP code.
Sorry, my bad not to have seen that
Example, note access and modify dates.
09:09:23 user1234@moodle-local-dev ~
$ stat testdates.txt
File: ‘testdates.txt’
Size: 217 Blocks: 8 IO Block: 4096 regular file
Device: 801h/2049d Inode: 260749 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 1000/ user1234) Gid: ( 1000/ user1234)
Access: 2016-11-15 09:08:59.757857287 +1030
Modify: 2016-09-09 13:36:00.368147884 +0930
Change: 2016-11-15 09:09:14.801375287 +1030
Birth: -
09:10:58 user1234@moodle-local-dev ~
$ touch testdates.txt
09:11:11 user1234@moodle-local-dev ~
$ stat testdates.txt
File: ‘testdates.txt’
Size: 217 Blocks: 8 IO Block: 4096 regular file
Device: 801h/2049d Inode: 260749 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 1000/ user1234) Gid: ( 1000/ user1234)
Access: 2016-11-15 09:11:11.835863287 +1030
Modify: 2016-11-15 09:11:11.835863287 +1030
Change: 2016-11-15 09:11:11.835863287 +1030
Birth: -
09:12:24 user1234@moodle-local-dev ~
$ touch -a -m -t 201509091336.00 testdates.txt
09:12:30 user1234@moodle-local-dev ~
$ stat testdates.txt
File: ‘testdates.txt’
Size: 217 Blocks: 8 IO Block: 4096 regular file
Device: 801h/2049d Inode: 260749 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 1000/ user1234) Gid: ( 1000/ user1234)
Access: 2015-09-09 13:36:00.000000000 +0930
Modify: 2015-09-09 13:36:00.000000000 +0930
Change: 2016-11-15 09:12:30.687269287 +1030
Birth: -
If one file has been hacked then there is only one sensible thing to do... replace *all* the Moodle code with a fresh download from moodle.com. Why wouldn't you?
This time, make sure you secure it properly.
It happens to the best of us but don't do half a job cleaning it up.
I take this a step further; OP has a responsibility to the users of the site to advise the site was compromised and malware was installed that may be used to spread other malware (watering hole attack) to users. There is a chance that that malware does more than simply collect user data - if it notices a specific admin user login, there is a very high chance it will attempt to infect the admin workstation with further malware or even attempt to steal admin session details.
Further to this the users also need to be advised so they can update/change their passwords, not only on the hacked site but also other sites where they may have used that password (many people reuse passwords).
My paranoid hat also leads me to never trust that server again whatsoever as who knows what binaries have been backdoored. I would start from scratch again to ensure that the server itself is safe.
So I looked at your index file and I see malicious javascript in it. Most probably the javascript has been added to a content area either on your front page or a course summary. I had an issue with this once to find that it was added to a course summary which was making it appear on the front page. You should be able to narrow it down from the source code.
Hmmmm ... have inspected index.php ...
You can do same with any text editor.
Typically, index.php file has line number 1 that declares the file to be a php script. Contains only "<?php". Your index.php file, however, has way out to the right of line 1, something that begins with:
"@file_get_contents(" http : // web.51.la:82"
Have actually inserted spaces in above clipped URL so it won't be clickable here.
In investigating web.51.la ..... appears to be in the IP block: 42.236.74.x
Whois for that IP block shows:
inetnum: 42.224.0.0 - 42.239.255.255
netname: UNICOM-HA
descr: China Unicom Henan province network
descr: China Unicom
descr: No.21,JiN-Rong Street,
descr: Beijing 100033
country: CN
A google search:
https://www.google.com/search?q=web.51.la&ie=utf-8&oe=utf-8
One link you'll find there:
http://security.stackexchange.com/questions/66729/what-does-this-javascript-file-do-is-this-a-virus
and in the discussion/page above is this:
"Basically it's tracking you, including the page you're viewing, how many times you've viewed the site, how many pages you've viewed, what your browser resolution is, etc.
This could be malicious depending on the circumstances, although most websites run tracking of some form such as Google Analytics. It doesn't pose a threat to the integrity of your machine as someone viewing the site, but it might be a threat to your privacy."
I'd consider that to be un-desireable and would do as Howard suggested.
'spirit of sharing', Ken
I've deleted the first line in the index.php, the loading speed is back to normal.
I donwloaded a fresh Moodle installation package and the site compressed zip file, and compared these files in two folders, then deleted/replaced a couple of suspicious files.
However, I still can't find the inserted the javascript, would you happen to know where the javascripts are located?
I've attached the home page here.
In the head section, a few of js were inserted between //<![CDATA[ ....code....//]]>.
A couple of js were inserted between the symbols in footer section too.
Many thanks!
Think taking the approach of replacing 'suspicious' files is the harder route to go. in a moodle 3.1 code directory, as an example, there are 34716 files. No one here in these forums has actually suggested taking that approach. That's because there is too much unknown.
Is the site customized? ... ie, core files changed? Does the site have addon/plugins? IF not, it's a 'stock' site and the only file one needs to keep is the config.php file - which is pretty easy to fix IF it were changed (most likely whatever it is hasn't changed config.php file ... too obvious).
'spirit of sharing', Ken
