Moodle e-learning platform patches session hijack bug that led to pre-auth RCE

Researchers disclose second critical flaw in authentication plugin

UPDATED A session hijack vulnerability in the hugely popular e-learning platform Moodle enabled attackers to commandeer any user’s session and achieve remote code execution (RCE), security researchers have revealed.

Maintainers of the open source platform patched the critical flaw last year, thus 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 “the over-usage of PHP’s session_decode function when the database session handler was configured”, according to a blog post published by pen testers Robin Peraglie and Johannes Moritz on January 10.

The bug is contingent on Shibboleth authentication being enabled in Moodle.

Pre-auth RCE… the prequel

The findings build on another pre-auth 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 installations.

As reported by The Daily Swig, that bug, which was patched in July 2021, meant attackers could access students’ data and test papers, and possibly even manipulate exam results.

Both vulnerabilities “stem from the attempts to re-implement or mess with PHP’s internal session mechanisms” – an inadvisable move “due to the complexity and pitfalls” involved, said the researchers.

Fraction of a second

The follow-up flaw related to how the logout_db_session() function was invoked by every logout request received via a SOAP endpoint, iterated across all available database sessions and threw sessions into the session_decode function.

This decoded the database’s serialized session data and populated the $_SESSION superglobal with the decoded data – logging an attacker in as every user with an active session for a fraction of a second, said the researchers.

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

Attackers could logout to remove non-admin sessions from the database and repeat the attack until an admin session surfaced – paving the way to RCE via the plugin installer.

Triage trouble

The bug affects versions 3.11-3.11.2, 3.10-3.10.6, and 3.9-3.9.9 and was addressed in 3.11.3, 3.10.7, and 3.9.10.

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

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

Abby Fry, communications manager at Moodle, told The Daily Swig: “Our Moodle LMS [learning management system] team have advised that although security concerns can be reported both directly to Moodle or via our submission form (which is linked to our Bugcrowd Vulnerability Disclosure Program), the latter is still preferred and our recommended submission method. This both ensures more complete submissions (as they must include specific details in the form) and maximizes the resources available to review submissions (by taking advantage of Bugcrowd’s triage team).

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

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

This article was updated on January 14 with comment from Moodle