0day.today - Biggest Exploit Database in the World.
Things you should know about 0day.today:
Administration of this site uses the official contacts. Beware of impostors!
- We use one main domain: http://0day.today
- Most of the materials is completely FREE
- If you want to purchase the exploit / get V.I.P. access or pay for any other service,
you need to buy or earn GOLD
Administration of this site uses the official contacts. Beware of impostors!
We DO NOT use Telegram or any messengers / social networks!
Please, beware of scammers!
Please, beware of scammers!
- Read the [ agreement ]
- Read the [ Submit ] rules
- Visit the [ faq ] page
- [ Register ] profile
- Get [ GOLD ]
- If you want to [ sell ]
- If you want to [ buy ]
- If you lost [ Account ]
- Any questions [ admin@0day.today ]
- Authorisation page
- Registration page
- Restore account page
- FAQ page
- Contacts page
- Publishing rules
- Agreement page
Mail:
Facebook:
Twitter:
Telegram:
We DO NOT use Telegram or any messengers / social networks!
You can contact us by:
Mail:
Facebook:
Twitter:
Telegram:
We DO NOT use Telegram or any messengers / social networks!
Moodle Cross Site Scripting / Server-Side Request Forgery Vulnerabilities
Author
Risk
[
Security Risk Low
]0day-ID
Category
Date add
CVE
Platform
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. '< ;' 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 # 0day.today [2024-12-23] #