Open eClass 2.3 – Security Assessment & Hardening Report

Executive Summary

This report presents the results of a security assessment and hardening initiative for Open eClass 2.3, a legacy e-learning platform. The project demonstrates a systematic approach to identifying, mitigating, and validating the remediation of critical web application vulnerabilities. Through a combination of technical controls and adversarial testing, the engagement highlights best practices in secure software development and provides actionable recommendations for improving the security posture of similar platforms.

Project Context

Open eClass 2.3 is a web-based learning management system, intentionally deployed in a vulnerable state to serve as a controlled environment for security research and training. The project required participants to act as both defenders—by implementing security enhancements—and as adversaries—by attempting to compromise peer deployments. This dual-role scenario closely mirrors real-world security operations, where organizations must both protect their assets and anticipate evolving threats.

Deployment & Configuration

• Platform: Open eClass 2.3 (legacy, intentionally vulnerable)
• Environment: Dockerized for reproducibility
• Access: http://localhost:8001/ (installation wizard required on first launch)
• Database:
  • Host: db
  • User: root
  • Password: 1234
• System:
  • Platform URL: http://localhost:8001/
  • Administrator Username: drunkadmin

Deployment Steps

docker-compose up -d   # Build and start (first run may take several minutes)
docker-compose stop    # Stop services
docker-compose start   # Restart services
docker-compose down -v # Stop and remove all containers and volumes

Security Hardening (Defensive Measures)

SQL Injection Mitigation

SQL injection attacks exploit improper handling of user input in database queries. To address this, we:

• Applied input sanitization using the escapeSimple function to neutralize special characters (e.g., replacing ' with \').
• Enforced type safety with intval for numeric parameters, preventing injection via type conversion.
• Adopted prepared statements (mysqli) to ensure user input is never executed as part of a query, especially for non-numeric input.

These controls were systematically applied throughout the codebase, including but not limited to:

• openeclass/modules/auth/newuser.php
• openeclass/modules/phpbb/viewforum.php
• openeclass/modules/phpbb/viewtopic.php
• openeclass/modules/phpbb/newtopic.php
• openeclass/modules/phpbb/reply.php
• openeclass/modules/dropbox/index.php
• openeclass/modules/dropbox/dropbox_class.inc.php
• openeclass/modules/work/work.php
• openeclass/modules/work/group_work.php
• openeclass/modules/work/grade_edit.php
• openeclass/modules/auth/auth.inc.php
• openeclass/modules/auth/contactadmin.php
• openeclass/modules/auth/contactprof.php
• openeclass/modules/auth/courses.php
• openeclass/modules/auth/formuser.php
• openeclass/modules/auth/ldapnewprofadmin.php
• openeclass/modules/profile/profile.php

Cross-Site Scripting (XSS) Prevention

To mitigate both stored and reflected XSS vulnerabilities, we:

• Escaped user input using htmlspecialchars, escapeSimple, and addSlashes prior to rendering.

Key modules updated include:

• openeclass/index.php
• openeclass/modules/auth/newuser.php
• openeclass/modules/auth/newprof.php
• openeclass/modules/auth/courses.php
• openeclass/modules/dropbox/index.php
• openeclass/modules/conference/pass_parameters.php
• openeclass/modules/work/work.php (submission + id)
• openeclass/modules/work/group_work.php
• openeclass/modules/work/grade_edit.php (intval)
• openeclass/modules/dropbox/index.php (htmlspecialchars)
• openeclass/modules/phpbb/viewforum.php
• openeclass/modules/dropbox/dropbox_class.inc.php
• openeclass/modules/auth/newprof.php
• openeclass/modules/agenda/myagenda.php
• openeclass/modules/auth/ldapnewuser.php
• openeclass/modules/phpbb/reply.php

Cross-Site Request Forgery (CSRF) Protection

To prevent CSRF attacks, we implemented anti-CSRF tokens for all sensitive operations. Tokens are generated at login and validated on each critical request, ensuring only legitimate actions are processed. For each critical POST or GET request, a token is included and validated against the session.

This mechanism was integrated into:

• addfaculte.php (ADD, EDIT)
• openeclass/modules/admin/addusertocours.php (REGISTER)
• openeclass/modules/admin/adminannouncements.php (NEW, MODIFY, DELETE)
• openeclass/modules/admin/auth_process.php (SUBMIT)
• openeclass/modules/admin/auth.php (multiple)
• openeclass/modules/admin/change_user.php
• openeclass/modules/admin/cleanup.php
• openeclass/modules/admin/delcours.php (DELETE)
• openeclass/modules/admin/eclassconf.php (EDIT)
• openeclass/modules/admin/edituser.php (UPDATE)
• openeclass/modules/admin/infocours.php (UPDATE)
• openeclass/modules/admin/listreq.php (multiple UPDATES)
• openeclass/modules/admin/newuseradmin.php (UPDATE, INSERT)
• openeclass/modules/admin/password.php (UPDATE)
• openeclass/modules/admin/quotacours.php (UPDATE)
• openeclass/modules/admin/statuscours.php (UPDATE)
• openeclass/modules/admin/unreguser.php (multiple DELETE)
• openeclass/modules/create_course/create_course.php (multiple INSERT)
• openeclass/modules/auth/courses.php (DELETE, INSERT)
• openeclass/modules/profile/profile.php (multiple UPDATE)
• openeclass/modules/course_info/restore_course.php (multiple POST)

Remote File Inclusion (RFI) Controls

To address RFI risks:

• Language selection parameters are strictly validated against an allowlist (Greek, English, Spanish).
• Uploads of executable files (e.g., .php, .html, .js) are explicitly blocked.

Relevant modules include:

• openeclass/index.php
• openeclass/include/alt_login.php
• openeclass/include/baseTheme.php
• openeclass/include/init.php
• openeclass/modules/course_info/infocours.php
• openeclass/modules/create_course/create_course.php
• openeclass/modules/help/help.php
• openeclass/upgrade/upgrade.php
• openeclass/modules/course_info/restore_course.php
• openeclass/modules/work/work.php
• openeclass/modules/dropbox/dropbox_submit.php

Directory Listing Hardening

A vulnerability was identified where assignment directories were accessible by anyone if the directory name was known at /courses/[course name]/work, allowing execution of uploaded files. To prevent unauthorized access to uploaded assignments, an index.php file is automatically created in each assignment directory, disabling directory listing and direct file enumeration.

Offensive Security Assessment

SQL Injection Testing

Comprehensive testing of all user input vectors (GET/POST parameters, forms) was performed using classic and advanced SQL injection payloads (e.g., 'OR'1'='1, 'OR'1'='1' --). No exploitable injection points were identified in the target deployment. As a proof of concept, a complex injection for viewforum.php was prepared:

'
    OR '1' = '1'
UNION SELECT user_id, password
    FROM eclass.user
    WHERE user_id =1
UNION SELECT f.forum_type, f.forum_name
    FROM TMA103.forums f
    WHERE forum_id = ''
    OR '1' = '1'
ORDER BY forum_type DESC --

When executed in the opponent's phpmyadmin, this returned the password, demonstrating the risk if not mitigated.

XSS Testing

Both stored and reflected XSS vectors were tested. While stored XSS was not exploitable due to proper input handling, several reflected XSS vulnerabilities were identified and exploited (CSRF section), as demonstrated in the following URLs:

• newprof.php XSS
• newuser.php XSS
• ldapnewuser.php XSS

Remote File Inclusion (RFI) Exploitation

By leveraging the directory listing vulnerability in /courses/[course name]/work, we successfully uploaded .phtml files as student assignments and executed PHP code, resulting in:

• Site defacement (defc.phtml): replaced the index page after backing up the original.
• Extraction of hashed and plaintext admin credentials (pssw.phtml, echofilecontents.phtml): retrieved the MD5 hash and plaintext password from the database and config files.
• Password modification (passchange.phtml): changed the admin password hash to that of "12345" (later restored).
• Deployment of additional web shells (setup.phtml, restore.phtml, defc.phtml): setup.phtml created restore and defacement shells for further exploitation.

CSRF Attacks

CSRF vulnerabilities were exploited to:

• Steal administrator session cookies via crafted emails and malicious redirects (getcookie.phtml).
• Chain XSS and CSRF for advanced session hijacking, e.g., sending a shortened link that exfiltrates cookies using XSS.
• Attempt unauthorized configuration changes via forged POST requests (puppiespost.php).

Example Attack Flow

• An email was sent to the admin with a link to a malicious page (puppies). Visiting this page redirected the admin to the uploaded assignment (getcookie.phtml) in openeclass, then redirected back with the session cookie as a parameter, which was logged.
• Another attack used a shortened URL exploiting XSS to exfiltrate the cookie, redirecting the admin in (getcookie.phtml) again.
• With the stolen cookie, a POST request was made to change the database password, which succeeded and triggered the installation wizard, demonstrating the lack of CSRF protection on critical endpoints.

Key Recommendations

• Enforce strict Content Security Policy (CSP) headers to mitigate XSS.
• Implement rate limiting and account lockout on authentication endpoints.
• Conduct regular code reviews and automated security testing.
• Harden file upload and directory access controls further.

---