what you don't know can hurt you
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:

November 2024

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

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2024 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close