[BreachExchange] Millions of potential users of popular online educational platforms theatened

[Destry Winant]

https://www.securityinfowatch.com/cybersecurity/information-security/breach-detection/article/21217808/millions-of-potential-uscyers-of-popular-online-educational-platforms-theatened

What’s Going On?

At the beginning of October 2020, the Wizcase cyber research team, led
by Ata Hakcil, discovered a security vulnerability in the open-source
learning platform Moodle. Anyone who had an account on a given
school’s Moodle (with TeX filter enabled) could then take over
students’ accounts, professors, and even the accounts managed by the
platform administrators.

Moodle is an open-source educational platform used by 179,000 sites
and has 242 million users. It allows universities to distribute
content to students and teachers. It allows teachers to easily
communicate with students, organize and post links, documents,
assignments, quizzes, and grades.

Vulnerability discovered: October 9, 2020
Vulnerable versions: versions between Moodle 2.8 (November 2014) –
Moodle 3.10 (November 2020)
Fixed versions: 3.10.1, 3.9.4, 3.8.7 and 3.5.16
Vendor notified: October 11, 2020
Response received: October 12, 2020
Patch issued: December 2, 2020
Patched version released: January 25, 2021

Who Was Exposed and For How Long

According to Moodle’s website, the platform has more than 242 million
registered users in 251 countries. They are students, professors,
school admins, and more. If you are using Moodle, we really suggest
you take the “Mitigations” section to heart.

To understand the core of this issue, we’ve also tested it on previous
versions, and we were able to trace this vulnerability back to a small
code change in version 2.8.0, which was released on the 10th of
November, 2014. This means that the vulnerability our team discovered
had existed for 6 years before being discovered and patched.

Any university/school that had the TeX filter enabled was at risk. TeX
filter is usually needed for sharing mathematical formulas, so any
university with a scientific or economics department, or any field
that requires mathematical formulas probably have the TeX filter
enabled.Tex filter can be enabled by the site administrator only and
is enabled for all the users of the given site.(Moodle offers an
alternative method for rendering mathematical formulas using Mathjax,
but it does not support some of the functionalities offered by TeX,
and is commented on to be less backward compatible.)

How the Vulnerability Worked and What are the Consequences

Technical Explanation:

As a Moodle user, you can communicate with other people who have
access to the platform. This communication is happening through
private chats/discussion boards that you are opening with the people
of your choosing.

These “message boxes” allow you to type any content you would like to
send to the recipient.

Moodle checks every single input in these for characters like, “ and
encodes them properly with HTML entity encoding, while the backend
rejects inputs without proper encoding. However, a small oversight
with the math equations and TeX notation has allowed characters to
slip by without encoding.

When TeX formulas are sent to the backend, the same rules apply: they
are encoded using HTML entity encoding, and any input without proper
encoding is rejected. But here is the catch: TeX interpreter will
process this input and will decode the HTML entities in this process,
allowing anyone to bypass the sanitization process.

When viewing what was posted by a user in the server response,
contents of the processed result is placed in a script tag with the
type MathJax/TeX to be rendered on the client’s browser. With these
inputs HTML entity decoded, there is no longer a server-side measure
preventing anyone from closing this MathJax/TeX script tag, and
opening a new script tag to inject our javascript code to the page.

Non-Technical explanation:

When you try to communicate with students, professors, or admin, the
box where you input text to be sent had a vulnerability (when TeX
filter was enabled) that allowed you to insert content that would be
read as code by Moodle, which would then implement it. It means that
you could then implement code that would request a change in grades
(or else), and the moment someone viewed the message you sent, it
would have been applied without anyone being notified.

It is sometimes easy to misjudge what can and can’t be done when an
attacker can do anything in your stead on a website, so we’ve created
some demonstrations.

We’ve installed Moodle and enabled TeX filter on our own servers to
demonstrate this vulnerability without causing any harm to others. For
these demonstrations, we are going to have 4 different accounts.

- Lousy Student: Our attacker model, a student account with limited permissions;
- Hardworking Student: Our victim model 1, a classmate of Lousy
Student, also has limited permissions;
- Annoying Teacher: Our victim model 2, teacher who is assigned to the
course who has complete permissions over that one specific course;
- Admin: Our last victim model (3), the website administrator. Every
Moodle website has at least one administrator account, as it is
created during the setup. This account has complete access to
everyone’s profile, full moderation on every course, full access to
site administration tools, and limited access to the rest of the
server.

We will define “viewer” as the person receiving the message from the
attacker and opening it.

In our report, we decided that the “hacker” account would be a student
account, but it could be any other account type (teacher or manager).

Student account takeover

For our first demonstration, we are going to show what an attacker can
do with another student’s account.

On the video, you can see our attacker model, “Lousy Student” post a
small snippet designed to trigger the vulnerability, which is
misinterpreted by Moodle and instructs the viewer’s browser to visit
another (malicious) website and to run the code it sees on it.

When someone opens this discussion board, it confuses Moodle into
running parts of it as javascript code on the viewer’s browser,
allowing the attacker to do any action on the website as if they were
on the side of the viewer, without anything ever being noticeable by
the viewer.

With this demonstration, our goal was to “steal” the submitted
homework from “Hardworking Student”.

Teacher account takeover

For our next demonstration, we’re going to show a more critical aspect
of vulnerability.

This time, instead of going after “Hardworking Student”s homework, our
attacker is tackling the problem right at the source – by compromising
the teacher’s account to change their grades.

This demonstration starts similarly to the first one — the attacker
posts a long piece of text which is being misinterpreted by Moodle and
runs as javascript code on the viewer’s browser.

The only difference is that we are using a completely different
javascript code, which is crafted to change grades. As before, the
victim/viewer does not suspect anything wrong, but as you can see, the
grade has been updated successfully.

Admin account takeover

In this last demonstration, we are going to expose the biggest threat
raised by the vulnerability. This time the Administrator’s account is
going to be compromised, with the attacker gaining full control of
anything on the website as well as partial control on the server the
website is running on.

This attack starts like the previous ones, but this time a much
smaller input is being sent to the website. When the administrator
visits the forum post, they do not suspect anything wrong is
happening. However, they’ve visited the malicious website in the
background, where they unwillingly downloaded and ran the script they
found on this website. That gave the hacker control over the server
and allowed them to view the credentials Moodle uses to connect to the
database, which contains all the data the website stores.

Consequences and risks

The main threat engendered by this vulnerability is “account takeover”.

For example, if an admin account is compromised (a harmful message
opened in the chatbox), an attacker would be able to access the
username and hashed passwords of all the server users and modify their
password to something else. As the admin can read database
configuration, and the database contains the hashed passwords of all
the users, they could either crack those or just change it to
something else directly. The attacker could also grant himself admin
rights (as admins have this option) and then lock out the other
admins.

Even without compromising the admin account, they could just steal the
cookies of other users viewing the vulnerable pages, which would allow
them to log in as these users (but they would lose access after that
person logs out).

This would allow any attackers to do anything another user can do on
Moodle without the victim ever knowing it.

For each kind of account, the impact of the account takeover varies
significantly. Please find below a non-exhaustive list of what could
be done by a bad actor:

Account Takeover – For Other Students

Viewing other students’ direct messages, profile descriptions, chat
messages, or discussion posts could give them access to the account.
Be skeptical when visiting links sending to your school’s Moodle
(whether they are students’ profiles, forum links, or anything else),
even if the URL looks safe.

This would let attackers to:

Steal homework or any other submitted assignments;
Steal any uploaded files;
Modify uploaded files;
Read direct messages;
Edit profile settings;
Send any kind of post on the forum or direct messages in your stead.

Account Takeover – For Faculty Members

Always be skeptical when opening pages where there is content other
users have permission to edit or add – such as forum posts, direct
messages, other people’s profiles. If there are any similar
vulnerabilities, viewing these kinds of contents may cause you to
accidentally change grades or can allow attackers to use your account
as a medium when attacking other faculty members or administrators.

This would let attackers to:
Steal uploaded files that may contain answer sheets or unreleased exams;
Send any kind of posts on forums or direct messages in one’s stead;
Modify the course and the course content in one’s stead;
Modify grades for exams and homework;
Enroll or un-enroll students to class;
Download/delete other student’s homework so they can steal it and
reupload it as their own.

Account Takeover – For Administrators

Do not interact with other members from an account with administrator
permissions. If you need to read forums or messages, it would be
better to create another account that doesn’t have the same permission
and keep the admin accounts unused to perform these actions.

This would let attackers to:

Change Moodle’s settings like the domain name or other settings;
Change accounts rights (like which accounts are administrator);
Change which accounts are teachers for which courses;
Modify any users account settings;
Modify any users password;
Set up any plugin to the website (which could give full database
access to the attacker);

Mitigations

We strongly suggest updating your Moodle installation to the latest
version if possible and not rely on mitigations in the long term.

What Can I Do to Protect My Data?

If you are a staff member for an institution that is using Moodle and
you haven’t updated to the most recent version or haven’t applied the
mitigations yet, you should be careful when using Moodle. We suggest
avoiding parts of the website where all users are able to input text,
like direct messages, discussions, chats, or user profiles. Keep in
mind that if you were exposed and your account compromised, you might
not notice anything wrong with your account.

Who is Wizcase?

WizCase is one of the biggest international online security websites,
with content translated into 30 different languages. We provide tools,
tricks, and best practices for online safety and security. This
includes detailed VPN reviews and tutorials.

Our online web security team of White Hack hackers have uncovered some
of the biggest data breaches, including unsecured webcams and dating
site scandals.

Not only do we release our reports to the public, but we disclose them
to the company as well, allowing them to secure their servers and
creating a more secure environment for everyone.