Security Advisory: Achieving PHP Code Execution in ILIAS eLearning LMS before v7.30/v8.11/v9.1

During my Bachelor’s thesis, I identified several XSS vulnerabilities and a PHP Code Execution vulnerability via an insecure file upload in the learning management system (LMS) ILIAS. The XSS vulnerability can be chained with the code execution vulnerability so that attackers with tutor privileges in at least one course can perform this exploit chain.

The Bachelor’s thesis was motivated by the ever-increasing number of compromised universities in Germany^1,2,3,4,5. The thesis analyzed the importance of LMS systems in that context, as those services are often exposed to the internet.

The most prevalent LMS software in German universities are Moodle and ILIAS, as recent research⁶ by a colleague showed. Both LMS are open source and written in PHP. Due to the limited time available for my thesis, we chose ILIAS as the evaluation target. This software is also used by the German Government, which experienced a security incident for which it was said that ILIAS was the initial attack vector⁷.

My thesis aimed to find vulnerabilities as critical as possible in a limited time frame. Ideally, the scenario’s goal was to identify a vulnerability or chain with which it is possible to gain an initial foothold into a university’s network by being able to execute commands on the LMS web server.

In this blog post, I want to present the vulnerabilities and their coordinated disclosure to ILIAS.

CVE-2024-33529 – PHP Remote Code Execution via File Extension Verification Bypass by Uploading PHAR Files into Web Root

The PHP Remote Code Execution Vulnerability (CVE-2024-33529) was achieved by bypassing the file upload restrictions, enabling an attacker to upload executable php files into the web root. Even though ILIAS enforces an allowlist by default, an administrative account can make changes to this allowlist. Thus, an additional hard-coded blocklist enforces that specific file extensions are blocked even if allowlisted. However, this blocklist was not strict enough, permitting the upload of files with the phar extension.

Vulnerable Code

The blocklist was identified in two locations in the code:

Services/Utilities/classes/class.ilFileUtils.php:

public static function hasValidExtension($a_filename) : bool
    {
        $pi = pathinfo($a_filename);

        $extension = strtolower($pi["extension"]);
        // Regular expression pattern to match PHP file extensions, see https://mantis.ilias.de/view.php?id=0028626
        if (preg_match('/^ph(p[3457]?|t|tml)$/i', $extension)) {
            return false;
        }

        return in_array($extension, self::getValidExtensions())
            && !in_array($extension, self::getExplicitlyBlockedFiles());
    }

src/FileUpload/Processor/BlacklistExtensionPreProcessor.php:

protected function checkPath(string $path) : bool
    {
        $extension = $this->getExtensionForFilename($path);
        $in_array = in_array($extension, $this->blacklist, true);
        // Regular expression pattern to match PHP file extensions, see https://mantis.ilias.de/view.php?id=0028626
        if ($in_array === true || preg_match('/^ph(p[3457]?|t|tml)$/i', $extension)) {
            $this->reason = $this->reason .= " ($path)";
            return false;
        }
        return true;
    }

As seen above, the blocklist was enforced by the regular expression /^ph(p[3457]?|t|tml)$/i. As this regex is not extensive and thus only covers some possible PHP file extensions, this could be bypassed when uploading phar files.

It should be noted that the recommended hardening guidelines from ILIAS⁸ restricting the execution of PHP files located in the data directory solely restrict files with the php extension:

There may be situations where there is no opportunity to disallow uploading php-files e.g. in Computer Science courses. In this case you SHOULD disallow these uploaded code to be executed by the webserver.

Apache2:

<LocationMatch "/data/.*(?i)\.(php)$">
    Order Deny,Allow
    Deny from All
</LocationMatch>

Nginx:

location ~* /data/.*\.php {
    deny all;
}

Furthermore, it should also be mentioned that ILIAS implements a WebAccessChecker (WAC), which is intended to prevent any php or phar files located under the data directory from being executed and instead serves it as plain text. The WAC will perform such checks if the apache2 rewrite module is loaded, as the ILIAS installation guide recommends. The .htaccess file enforces this, as seen in the following line:

RewriteRule ^data/.*/.*/.*$ ./Services/WebAccessChecker/wac.php [L]

However, it was identified that this WAC only works in ILIAS 7, as the necessary checks are not performed in an ILIAS 8 or 9 installation, even if it is properly configured.

As a result, the attack path for exploiting this vulnerability is:

1. Adding the phar extension to the allowlist with administrative privileges
2. Uploading a PHP web shell with a phar extension using a file upload functionality where the file is stored somewhere in the web root

Prof of Concept

An example of an upload into web root is in the Test object, where creating questions for a test is possible. Here, a question of the type File Upload Question can be chosen to upload files. The application changes the uploaded file name but returns a direct link.

The following request and response show that I could execute PHP code, and in this case, more specifically, operating system commands via my web shell.

Request:

GET /data/myilias/assessment/qst_preview/6/6/fileuploads/file_9dd23ab69e852041ddf3a10abc73dcf2_1711566897.phar?cmd=id HTTP/1.1
Host: 192.168.56.105
[...]
Cookie: ilClientId=myilias; PHPSESSID=p1g9hh0a5s9mma7tucj40k4rfg
Connection: close

Response:

HTTP/1.1 200 OK
Date: Wed, 27 Mar 2024 19:22:29 GMT
Server: Apache/2.4.52 (Ubuntu)
Content-Length: 54
Connection: close
Content-Type: text/html; charset=UTF-8

uid=33(www-data) gid=33(www-data) groups=33(www-data)

As the response shows, the command was successfully executed with web server privileges.

Recommendations

To fix this issue, three measures were recommended to ILIAS:

• Measure 1: Implementing a more extensive blocklist covering all typical PHP file extensions.
• Measure 2: Applying the implemented blocklist should be part of the default installation process.
• Measure 3: All uploaded files should always be stored outside the web root.

CVE-2024-33528 – Stored XSS in Object Name via XML Import

Users maintaining a course in ILIAS can create objects such as folders, exercises, or tests in that course. In addition to creating such objects, importing objects from, e.g., another course is possible. Thus, every object can also be exported. The exported object information is stored in a ZIP file containing the information in various XML files.

The application assumes that the user interface’s input validation is strict and disallows any insecure characters that may be used for XSS but does not consequently implement output encoding. Also, the imported XML files are validated during import, and some input fields have less strict input validation than the respective user interface fields. The combinations allow XSS via file imports.

One example is a Title XML-tag that enabled my user with tutor privileges to stage XSS payloads as no input validation was present during import and also no output encoding for this object in the GUI (CVE-2024-33528). A maliciously crafted XML may look like the following:

<?xml version="1.0" encoding="utf-8"?>
<!--Generated by ILIAS XmlWriter-->
<exp:Export xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:exp="http://www.ilias.de/Services/Export/exp/4_1" xmlns="http://www.ilias.de/Modules/Folder/fold/4_1" InstallationId="0" InstallationUrl="http://192.168.56.106" Entity="fold" SchemaVersion="4.1.0" xsi:schemaLocation="http://www.ilias.de/Services/Export/exp/4_1 http://192.168.56.106/xml/ilias_export_4_1.xsd http://www.ilias.de/Modules/Folder/fold/4_1 http://192.168.56.106/xml/ilias_fold_4_1.xsd">
  <exp:ExportItem Id="488">
    <Folder Id="488">
      <Title>XSS Folder <![CDATA[<script>alert('XSS by Daniel Schlecht at ERNW!')</script>]]></Title>
      <Description/>
      <Sort type="Inherit"/>
    </Folder>
  </exp:ExportItem>
</exp:Export>

After the object is imported, the XSS triggers every time the object’s title is browsed. As the object is located in a course, this automatically affects every course user browsing the course.

Using the exact attack vector, we found three additional occurrences of stored XSS vulnerabilities in administrative functionalities which got assigned CVE-2024-33525,CVE-2024-33526 and CVE-2024-33527.

Recommendations

OWASP states that for an XSS attack to be successful, an attacker must be able to insert and execute malicious content in a webpage. Thus, all variables in a web application need to be protected. Ensuring all variables go through validation and are then escaped or sanitized is perfect injection resistance. Any variable that does not go through this process is a potential weakness. Frameworks make it easy to ensure variables are correctly validated and escaped or sanitized.

Consequently, input validation is a good first step, but it alone is not sufficient to prevent XSS. Each variable used in the user interface should be passed through an output encoding function that ensures that the input is encoded context-aware safely for HTML, HTML attributes, CSS, etc. This is the only way to protect against XSS, as the application security philosophy should assume that input validation filters can be bypassed.

Exploit Chain

The PHP filter bypass was chained with the XSS vulnerability to gain code execution with administrative user interaction. In the following exploit chain, attackers are assumed to possess tutor privileges in at least one course.

Step One: Import XSS Payload

In the first step of the chain, a maliciously crafted XSS payload is injected through the XML import. This XSS payload contains a payload that, when viewed, performs a POST request to add the phar extension to the allowlist. This functionality is CSRF-protected with a CSRF token. As a result, the JavaScript payload first retrieves a valid CSRF token via a GET request before supplying this token with the POST request.

Step Two: User Interaction with Administrative Privileges

As the before-injected XSS payload only works when viewed by administrators, the persistent XSS will trigger when they visit the course site. The file extension changing request fails for all lower-privileged users due to missing privileges. As attackers have access to a user account with tutor privileges, there may be several ways of pretexting an IT administrator to browse the manipulated course.

Step Three: Exploit PHP Code Execution

As the phar file extension was added to the allowlist by bypassing CSRF restrictions with administrative privileges, the attackers with course tutor privileges can upload phar files in web root and run arbitrary PHP code.

Affected Versions

During testing, we identified the vulnerabilities in ILIAS 7.28 and 8.9, the most recent versions. During the disclosure, we could verify that all ILIAS 7 and 8 versions before ILIAS 7.30 and 8.11 are affected by CVE-2024-33526 (XSS in User Role Titles via XML Import), CVE-2024-33527 (XSS in User Login Names via XML Import), CVE-2024-33528 (XSS in Object Name via XML Import) and CVE-2024-33529 (PHP Remote Code Execution via File Extension Verification Bypass by Uploading PHAR Files into Web Root). The exploit only works in ILIAS 7.29 when the apache2 rewrite module is not loaded. CVE-2024-33525 (XSS in Organisational Unit Titles via XML Import) only affects versions from 7.20 to 7.29 as well as 8.4 to 8.10, and 9.0. CVE-2024-33529 also affects version 9.0.

Disclosure Timeline

• March 14, 2024: ERNW provides vulnerability information on the first XSS in ILIAS 7.28 and 8.9, starting the 90-day disclosure period.
• March 19, 2024: Release of ILIAS 7.29 and 8.10 fixing another XSS (not reported by ERNW).
• March 20, 2024: Initial response from ILIAS confirming that they received the report and that the matter was forwarded to the responsible person.
• March 22, 2024: ERNW informs ILIAS that the reported finding is reproducible in the new releases.
• March 26, 2024: ILIAS states that the vulnerability is being fixed.
• March 26, 2024: ERNW informs ILIAS that the XSS (not reported by ERNW) is not fixed in the releases.
• March 28, 2024: ILIAS confirms that the vulnerability can still be reproduced.
• March 28, 2024: ERNW provides information on the PHP Code Execution vulnerability.
• April 3, 2024: ERNW provides information on three additional Stored XSS vulnerabilities.
• April 8, 2024: ILIAS states that they could reproduce all vulnerabilities and are working on fixes.
• April 10, 2024: ERNW offers to retest when a fix is implemented.
• April 15, 2024: ILIAS appreciates effort after a patched release is rolled out.
• April 30, 2024: Release of ILIAS 9.0.
• May 2, 2024: ERNW informs ILIAS that two findings are still reproducible in ILIAS 9.0.
• May 14, 2024: ILIAS informs ERNW that the issues are fixed. Release of ILIAS 7.30 and 8.11.
• May 16, 2024: ERNW informs ILIAS that the WAC is not working in ILIAS 8.10, 8.11 and 9.0.
• May 17, 2024: Release of ILIAS 9.1.
• May 22, 2024: Release of this Blog Post.

We want to thank ILIAS open source e-Learning e. V. for making such a great open source e-learning platform and their efforts on improving the software.

If you are interested in more web application security insights, you potentially want to check out our Web Application Security 101 training at #TROOPERS24 in Heidelberg, Germany!

Cheers!
Daniel