Moodle e-learning platform fixes session hijacking bug that led to RCE pre-authorization

Adam Bannister January 12, 2022 at 12:32 UTC

Updated: January 14, 2022 10:18 UTC

Researchers Reveal Second Critical Flaw in Authentication Plugin

UPDATE A session hijacking vulnerability in hugely popular e-learning platform Moodle has allowed attackers to commandeer any user’s session and perform remote code execution (RCE), researchers have revealed. security researchers.

Officials of the open-source platform patched the critical flaw last year, protecting 213 million users in 241 countries and customers including Shell, Microsoft and the London School of Economics.

The unauthenticated flaw (CVE-2021-40691) resides in Moodle’s Shibboleth identity management plugin due to “overuse of PHP function when database session handler was configured”, according to a blog post by pen testers Robin Peraglie and Johannes Moritz on January 10.

The bug depends on Shibboleth authentication being enabled in Moodle.

NCE pre-clearance… the prequel

The findings build on another pre-authentication RCE the researchers found in the same plugin last year that was triggered when sessions were stored in individual files, the default configuration for new installs.

RELATED Researchers, cheaters: RCE bug in Moodle could be used to steal data, manipulate exam results

As reported by The daily sipthis bug, which was patched in July 2021, meant that attackers could access student data and papers, and possibly even manipulate exam results.

Both vulnerabilities “originate from attempts to reimplement or mess with PHP’s internal session mechanisms” – a decision not recommended “due to the complexity and pitfalls” involved, the researchers said.

Fraction of a second

The tracking flaw was related to how the function was called by each disconnect request received through a SOAP endpoint, iterated over all available database sessions, and launched sessions within the function.

This decoded serialized session data from the database and populated the superglobal with the decoded data – logging an attacker like every user with an active session for a fraction of a second, the researchers said.

Since the last session was not unloaded, remained populated with the most recent user’s session information. This session was assigned to the attacker’s session cookie due to , so that the attacker could refresh the page and hijack random user sessions.

Learn about the latest education security news

Attackers could log out to remove non-admin sessions from the database and repeat the attack until an admin session surfaces, opening the way to RCE via the plugin installer.

Sorting problem

The bug affects versions 3.11-3.11.2, 3.10-3.10.6 and 3.9-3.9.9 and has been resolved in 3.11.3, 3.10.7 and 3.9.10.

They submitted the bug via Bugcrowd on February 21 and a fix was released on GitHub on September 12.

They described the reporting process as “extremely cumbersome due to issues understanding and reproducing the issue on the Bugcrowd side.” As with the previous bug, it took four months for the report to reach Moodle via triage.

Abby Fry, communications manager at Moodle, said The daily sip: “Our LMS Moodle [learning management system] The team advised that although security issues can be reported both directly to Moodle or through our submission form (which is linked to our Bugcrowd vulnerability disclosure program), the latter is always preferred and our method of reporting. submission recommended. This both ensures more comprehensive submissions (as they must include specific details in the form) and maximizes the resources available to review submissions (by leveraging Bugcrowd’s triage team).

“On the researcher side, this generally ensures that submissions are sorted more efficiently, and within Moodle, it helps us focus our energy on investigating and resolving any confirmed issues by minimizing time spent managing duplicates. , false positives and spam.

“While unfortunately in this case the triage/escalation time for this researcher was longer than desired, the average triage time for all submissions is approximately five days, and there have been incremental improvements to the process since this submission was made in the early months of the program (including internally, to ensure better visibility and response to delays or blockages).

This article was updated on January 14 with a comment from Moodle

YOU MIGHT ALSO LIKE Anti-cheat browser extension fails web security exam

Source link

Comments are closed.