exploit the possibilities

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:

May 2022

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    May 1st
    0 Files
  • 2
    May 2nd
    15 Files
  • 3
    May 3rd
    19 Files
  • 4
    May 4th
    24 Files
  • 5
    May 5th
    15 Files
  • 6
    May 6th
    14 Files
  • 7
    May 7th
    0 Files
  • 8
    May 8th
    0 Files
  • 9
    May 9th
    13 Files
  • 10
    May 10th
    7 Files
  • 11
    May 11th
    99 Files
  • 12
    May 12th
    45 Files
  • 13
    May 13th
    7 Files
  • 14
    May 14th
    0 Files
  • 15
    May 15th
    0 Files
  • 16
    May 16th
    16 Files
  • 17
    May 17th
    26 Files
  • 18
    May 18th
    4 Files
  • 19
    May 19th
    17 Files
  • 20
    May 20th
    2 Files
  • 21
    May 21st
    0 Files
  • 22
    May 22nd
    0 Files
  • 23
    May 23rd
    6 Files
  • 24
    May 24th
    19 Files
  • 25
    May 25th
    5 Files
  • 26
    May 26th
    12 Files
  • 27
    May 27th
    0 Files
  • 28
    May 28th
    0 Files
  • 29
    May 29th
    0 Files
  • 30
    May 30th
    0 Files
  • 31
    May 31st
    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