exploit the possibilities
Home Files News &[SERVICES_TAB]About Contact Add New

Moodle Cross Site Scripting / Server-Side Request Forgery

Moodle Cross Site Scripting / Server-Side Request Forgery
Posted Nov 9, 2021
Authored by rekter0 | Site r0.haxors.org

Moodle versions 3.10 to 3.10.1, 3.9 to 3.9.4, 3.8 to 3.8.7, and 3.5 to 3.5.16 suffer from cross site scripting and server-side request forgery vulnerabilities.

tags | advisory, vulnerability, xss
advisories | CVE-2021-20280
SHA-256 | 5ebbb3e3b937891a7993ff7cfa746f4eb1c07b7273456d6b43b919d3917226a0

Moodle Cross Site Scripting / Server-Side Request Forgery

Change Mirror Download
22-10-2021 - rekter0

Moodle is an opensource learning management system, popular in universities and workplaces largely used to manage courses, activities and learning content, with about 200 million users


Versions affected 3.10 to 3.10.1, 3.9 to 3.9.4, 3.8 to 3.8.7, 3.5 to 3.5.16
CVE identifier CVE-2021-20280

# Summary

When managing a course in Moodle, it's possible to add a 'Feedback' activity. This activity-type allows enrolled students to provide feedback to different questions created by the teacher. Some of these question types allow the students to provide text-input as feedback (eg. 'Short text answer'). The input provided has HTML striped before being inserted into the database and is supposedly sanitized in a safe way before being rendered, during this process, and for unkown reasons to me, moodle did html entities decoding leading to a stored XSS vulnerability and Blind SSRF.

# Vulnerability analysis

When a student submits their feedback text answer it is processed with s() function before being stored in the database

/mod/feedback/classes/completion.php

> $itemobj = feedback_get_item_class($item->typ);
> $newvalue['value'] = $itemobj->create_value($data->$keyname);

// Update or insert the value in the 'feedback_valuetmp' table.
if (array_key_exists($item->id, $existingvalues)) {
$newvalue['id'] = $existingvalues[$item->id];
$DB->update_record('feedback_valuetmp', $newvalue);
} else {
$DB->insert_record('feedback_valuetmp', $newvalue);
}

feedback_get_item_class loads class processor for that feedback input type

/mod/feedback/item/textfield/lib.php

public function create_value($value) {
> return s($value);
}

create_value() process input with s() function

/lib/weblib.php

/**
* Add quotes to HTML characters.
*
* Returns $var with HTML characters (like "<", ">", etc.) properly quoted.
* Related function {@link p()} simply prints the output of this function.
*
* @param string $var the string potentially containing HTML characters
* @return string
*/
function s($var) {

if ($var === false) {
return '0';
}

> return preg_replace('/&#(\d+|x[0-9a-f]+);/i', '&#$1;',
> htmlspecialchars($var, ENT_QUOTES | ENT_HTML401 | ENT_SUBSTITUTE));
}

As in function description, it removes tags and process the input with htmlspecialchars

Stored XSS
When rendering the answer entry, mid of the process, moodle used to do html_entity_decode

/mod/feedback/classes/response_table.php

public function other_cols($column, $row) {
if (preg_match('/^val(\d+)$/', $column, $matches)) {
$items = $this->feedbackstructure->get_items();
$itemobj = feedback_get_item_class($items[$matches[1]]->typ);
$printval = $itemobj->get_printval($items[$matches[1]], (object) ['value' => $row->$column]);
if ($this->is_downloading()) {
> $printval = html_entity_decode($printval, ENT_QUOTES);
}
return trim($printval);
}
return $row->$column;
}

So, if a user supplied a payload with hex-encoded values, e.g. '&#x3c ;' instead of '<' it would have remained the same after s() have had processed it. this would have gone under the radar of the sanitizer, and moodle would have decoded it during rendering process. The stored XSS could have been leveraged to trigger a blind SSRF.
# Impact

An authenticated attacker with the least privilege (student), could inject html/js with a crafted response to feedback activity leading to a stored XSS and blind SSRF. Successful exploitation of the XSS vulnerability allows the attacker to takeover moodle users including teachers and administrators or perform actions on their behalf. Exploiting the Blind SSRF would have given the attacker the ability to interact with internal server services and possible RCE in some environement setups.

# Timeline

12-01-2021 - Reported
01-02-2021 - Vendor confirmed
15-03-2021 - Fixed in new release

Login or Register to add favorites

File Archive:

April 2024

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Apr 1st
    10 Files
  • 2
    Apr 2nd
    26 Files
  • 3
    Apr 3rd
    40 Files
  • 4
    Apr 4th
    6 Files
  • 5
    Apr 5th
    26 Files
  • 6
    Apr 6th
    0 Files
  • 7
    Apr 7th
    0 Files
  • 8
    Apr 8th
    22 Files
  • 9
    Apr 9th
    14 Files
  • 10
    Apr 10th
    10 Files
  • 11
    Apr 11th
    13 Files
  • 12
    Apr 12th
    14 Files
  • 13
    Apr 13th
    0 Files
  • 14
    Apr 14th
    0 Files
  • 15
    Apr 15th
    30 Files
  • 16
    Apr 16th
    10 Files
  • 17
    Apr 17th
    22 Files
  • 18
    Apr 18th
    45 Files
  • 19
    Apr 19th
    0 Files
  • 20
    Apr 20th
    0 Files
  • 21
    Apr 21st
    0 Files
  • 22
    Apr 22nd
    0 Files
  • 23
    Apr 23rd
    0 Files
  • 24
    Apr 24th
    0 Files
  • 25
    Apr 25th
    0 Files
  • 26
    Apr 26th
    0 Files
  • 27
    Apr 27th
    0 Files
  • 28
    Apr 28th
    0 Files
  • 29
    Apr 29th
    0 Files
  • 30
    Apr 30th
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2022 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close