Hello Lázaro José,
Please take a look at the following documentation pages:
There's a very old (2008, 2009) thread, you might want to check it too:
Check as well your own machine - I panicked once and thought my site was infected, however I found that it was actually my machine, using keywords on screen and turning them into links.
Good morning Peter Bowen,
I think that is a problem in the database table, because the problem is seen by many students in various types of equipment, I am looking for it but I can not find, you know of any plugin that does this cleaning?
Good morning Guillermo Madero,
I appreciate your cooperation, I am reviewing these links, but I think that is a problem in the database table, because the problem is seen by many students in various types of equipment, I'm looking for it but I can not find, you know some plugin to do this cleaning? else, is infection may have been caused by some user file released or let some disabled function on security?
Hello Lázaro José,
You haven't provided any info about your server setup.
Basically, I would start by getting particular text strings or URL from the ads (e.g. "CouponDropDown", as shown in the image you placed) and then I'd search the database for that info.
If cleaning the database proved difficult and if I followed a good backup policy, I would just restore the previous backup file.
I would also check the logs, both the Moodle activity log and the web server error log, for any clues about how the problem came to be.
To avoid doing random guesses (unless I had a log with the hash of the original Moodle files), I would do the upgrade process (without actually doing an upgrade, just restoring the original code):
And I would definitely carefully read the Moodle security documentation pages
and follow the advice given there.
I just had an adware problem in my moodle similar to yours.
I finally found that some code had been added to my database. In some fields there were references to scripts. Most of them in the summary of the courses, in the categories of courses and in some groups.
To find where were them I searched the database from the phpmyadmin. It lets you search for a chain (%script%) in all the tables in every field. That's what I did and then I cleaned it up.
I hope this helps.
Good morning Raquel Sacristán P,
I think that is a problem in the database table, because the problem is seen by many students in various types of equipment, I am looking for it but I can not find, you know of any plugin that does this cleaning? else, is infection may have been caused by some user file released or let some disabled function on security?
Sorry but I don't know of any plugin that can do the cleaning. I had to do it myself.
You are right, the problem is in the database. And in my case I found it in around 5 tables. I found it in the summary field of the table courses, in the description field in the course_categories table, in the formattedtext field in the cache_text table, etc.
I find texts like this
Do you have access to the phpmyadmin? You can do a general search of the chain "%script%" in any field in all the tables. That's how I found the undesired links. Then I had to create sql queries to change all the infected fields.
You can also do a particular search in the tables I told you of the chain "%script%" in the fields I told you before.
I hope you can solve the problem.
Grateful for the help, I found the way the database and managed to get the infected path, I decided escluindo scripts as the image below:
We got the same kind og invasion on one of our Moodles, in one course specifically.
It had many embeded videos (iframes) from different sources.
I tried getting rid of a few <script src=... lines I found in the source code, but didn't succeed.
Is it normal that teacher role has trustcontent permission set to allow? Therefore all teachers can insert malicious code.
In the security overview, I get a warning (/report/security/index.php) sur RISQ_RSS.
Why would a teacher want to insert malicious code?
The teacher may not know they've inserted malicious code. The teacher may be forced to insert the malicious code. The teacher's account may be compromised. The teacher may not be as trustworthy as is assumed. The teacher may be trying to teach their students a valuable lesson.
There are many reasons.
Yes, technically, there may be many reasons, but given the OP's question: "Is it normal that teacher role has trustcontent permission set to allow?" I answered with a rethorical question. My bad. I should have simply said, "Yes, it is normal"
So now we know that teachers can insert script in the HTML editor (we still have TinyMCE on Moodle 2.6).
The permission is called "trustcontent" and it is allowed for the editing teacher role.
I created a new role in which I prohibit "trustecontent" and I assigned it to a particular teacher.
When I run the security overview, his name still appears in the liste of trusted users.
How can I prevent a user form being "trusted"?
Any idea anybody?
I'm back today with this question, that I should phrase as follow: how to prevent teachers from performing cross scripting in Moodle? Not that teachers would do that, but let's say that one of them, who has a very weak password, gets hijacked by a student. Then this student can hijack the whole site using XSS.