[CVE-2017-2641]Moodle remote code execution vulnerability-vulnerability warning-the black bar safety net

0x01 overview

Vulnerability, CVE-2017-2641 allows the attacker in a vulnerable Moodle on the server execute the PHP code. This vulnerability is actually composed of many small holes, as the article said.

Moodle is a very popular learning management system, deployed around the world in many universities, including mit, Stanford, Cambridge and Oxford and other top Research Institute.

Moodle stores a lot of sensitive information, such as grades, tests, and student personal data, making it an important goal, this is my audit it is the main reason.

This vulnerability applies to almost all of the deployment of the Moodle version, such as“affected versions”section below. I recommend all Moodle administrators to apply [security patches](<https://git.moodle.org/gw?p=moodle.git&a=search&h=HEAD&st=commit&s=MDL-58010&gt; a).

0x02 affected version

3.2〜3.2.1

3.1〜3.1.4

3.0〜3.0.8

2.7.0〜2.7.18 and other unsupported version

0x03 technology description

Part 1-Most of the code there is a problem

Moodle is a very large system, which contains thousands of files, hundreds of different components and about 200 million lines of PHP code. Therefore, it is apparent that different developers write different parts of the code, these parts affect each other.

In the following paper, I will demonstrate how to use the vulnerable code, in fact, the main reason is that too many developers did not write the document caused a serious logical vulnerability, almost all have a large number of code libraries of the system are likely to occur logic vulnerabilities.

In the system’s built-in Ajax mechanism, you can see an obvious“the same characteristics and different code”.

Moodle has a dynamic Ajax system that allows different components to use the system’s built-in Ajax interface. Moodle is to use“External Functions ”in. Use the built-in Ajax mechanism of each Assembly are to register their“ External Functions”, specify is called the component, function name and use it the required permissions.

When the Assembly wishes to use the Ajax interface, they can simply call“ service.php ”the documents, provided they register before the external function name. Moodle this manner allows the component developers to use its in-built Ajax interface, so you can for them to save themselves writing a new component of the trouble.

However, when the Moodle core developers start using this interface, the problem arises.

If there is a component needed by the Ajax request to change the user’s preferences, it will call“ setuserpref.php ”the file, specify that you want to change the name of the attribute and the value. This can be done in the following code see:

! [](/Article/UploadPic/2017-3/201732612465703. png)

In the code in the Middle, in the highlighted row, we can see that Moodle is attempting to ensure that the need to change the preferences in the“ ajax_updatable_user_prefs ”in the array definition, the array defines which preferences may be through the Ajax changes. Because Moodle does not want to be like us so the malicious attacker to change any important place.

Although the majority of users even does not pass through the Ajax interface, preferences can also be through other measures change, but the Moodle developers have tried to advance prevention, to prevent future misuse of this mechanism.

Until you have added the external function“ update_user_preferences ”in. This function is added to replace the old“ update_users ”function, which can“potentially [be] used to update any user attribute”, which is obviously a very bad thing;since the old function is only used to update the user’s preferences, and therefore apparently no need to let it change any other content.

Old features with new features the main difference between the old functionality not available through the Ajax interface access, and new features may be because of the so-called hazard function is changed for each user attribute of the function.

Most importantly, they implemented a proper permissions check, so even if the attacker can use the user priority of permission, it is only in your own user who use it.

However, these preferences at a later“ eval ”or“ exec ”call is not important, regardless of which user is using a dangerous function, as long as it is utilized.

Let us first take a look at this function code:

public static function update_user_preferences($userid, …, $preferences) {
…
// If we are trying to edit our own user preferences
if ($userid == $USER->id) {
// Requires the capability to edit our own profile, which we have
require_capability(‘moodle/user:editownmessageprofile’, $systemcontext);
} else { // Otherwise, we are tring to edit someone else’s preferences
/* Require admin capabilities… */
}

// Set the user’s preferences.
foreach ($preferences as $preference) {
set_user_preference($preference[‘type’], $preference[‘value’], $userid);
}
…
}

By looking at the code, we can see that due to the preferences to check, we can edit only their own preferences, but still missing some things. Although the code ensures that we can only edit our own user preferences, but it does not check our change which preferences, while the other is responsible for changing the user preferences of the Ajax page instead – “ setuserpref.php ”it.

A typical example is, if different developers, at different times, different needs for different functions written in different code. This time, they assume that the user preferences can not in any malicious way use. They think that it is not available.

Part 2-Use of non-use

There is a reason why the user preferences are considered non-use. They are in system operation aspects with hardly any impact – they cannot be used for DB queries, they do not define any of the components, they only affect the system is the GUI part, or even only the miner’s way.

So, what do we do now?

Well, we first look at the system GUI part how to work.

Moodle is being used Blocks mechanism to allow the Assembly to display to the user related data. These blocks can be added by the user and removed.

One of the block–“ course_overview ”for display to the user which is the registered courses list. In order to store the registration of the course sequence, the course overview block mechanisms using a program called“ course_overview_course_sortorder ”of a particular user preference is. This preference stores the user registered all the course ID of the list, and in its registration when ordering.

[1] [2] [3] next