Improper Access Control by Directory Listing Misconfiguration

[emaragkos]

Improper Access Control by Directory Listing Misconfiguration that affects all versions

When the webapp is poorly configured (directory listing is enabled), an unauthenticated remote attacker will be able to read students' submitted assessments because it does not ensure that the web server blocks directory listing.

CVE-2020-24381
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-24381
https://nvd.nist.gov/vuln/detail/CVE-2020-24381

PoC:
Course link
https://127.0.0.1/courses/CS101
Add "work" directory at the end
https://127.0.0.1/courses/CS101/work/

[iamaldi]

Hi,

I was wondering if there's a responsible disclosure policy that we can follow instead of disclosing security issues in the public?

GitHub has added the Security panel to every repository but seems like this one is not configured yet.

Thanks

[XhmikosR]

@adia: has this been taken care of in v3.10.x? The changelog is a little cryptic...

[adia]

Hello, and thanks for reminding us of this bug report. You are right, this is still a problem, especially for smaller installations on shared hosting where directory listings might be enabled and admins might not notice the problem. We do advise disabling them in our installation instructions.

We were preparing a new release (3.11) for tomorrow, and we'll make sure this is addressed by adding an empty "index.html" in all new subdirectories and creating it on upgrade in case it doesn't exist.

As for a disclosure policy, we'll publish something more official in GitHub's Security panel, but if you find any vulnerabilities, please report them by email to [email protected] (which is read only by the core team).

Thanks again, and sorry for not taking care of your report earlier.

[XhmikosR]

@adia: please make sure you mention it properly in the release notes and also have someone update the CVE details. The report here was a valid one IMHO and this has been in public for so long...

If this is fixed, you might have to release new patch versions for 3.9.x etc; I'm unsure what's your support policy.

On a side note, at least the Bootstrap version you are using has known security issues, specifically quite a few XSS issues. You should update to the latest 3.4.1. jQuery and probably other plugins have further security issues too.

Thanks again, and sorry for not taking care of your report earlier.

Not my report, you should give credits to @emaragkos when you publish a security advisory along with any other actions for your supported versions.

PS. I'm still not sure if the files should be accessible from the outside without authentication... Right now anyone with a link can access the file even if they are not authenticated.

[adia]

Will do about giving credit and upgrading our JS dependencies - that "your report" was addressed to everyone participating here, but of course, thanks and credit goes to @emaragkos. Although - we knew that if directory listings are enabled, no files are secure, and that's why disabling directory indexes is one of the first installation steps we recommend.

The proper fix is to support putting the data directory outside the web root, so that there's no need for configuration on the web server to limit direct access, but given our scant development resources we haven't prioritized that. We'll try to work on this for the next release.

Our policy is that all installations should upgrade to the latest release, but if anyone asks, and offers a justification for not being able to upgrade (e.g. being in the middle of exams period so that any changes are unwelcome) we work with them to provide fixes for known problems, as long as the changes are localized - for wider changes we always recommend upgrading to the latest release since we can't properly test big back-ported changes properly.

[XhmikosR]

The thing is that right now even search engines have crawled plenty of files in some cases (the one I have access on). So, even if you place an empty index.html file or the organization fixes their bogus installation, the files are still accessible and easily found in public.

[emaragkos]

This issue might seem of little importance at first, but given the fact that during covid19 quarantine many institutions used eClass as a solution for online remote exams, it poses a huge impact on confidentiality of private and sensitive data.
It does not only expose students' personal data (name, surname, email, student ID, even photos with gov or academic ID used for proof of identity) but also exposes private semester assessments, unreleased exam subjects and submitted answers resulting in compromising the integrity of the whole examination process.
I think this should be fixed asap with a temporary patch such as the index.html mentioned until there is time for a proper solution.
I'm sorry for posting it here in the first place, I wasn't aware of the recommended alternative way to report similar issues.