Fedena 2.3 : School management and e-Learning software
CVE-2021-27974 - Remote Code Execution
CVE-2021-27977 & CVE-2021-27978 - Cross-Site Scripting (Persistent & Reflected)
Remote Code Execution
Fedena 2.3 was vulnerable to RCE which was exploitable by an attacker without credentials using pre-existing exploit tools. Static analysis of the applications source code, available via the project GitHub repository revealed a secret key was being used to verify cookie session data integrity. The following screenshot highlights a snippet of the secret value stored in the applications config/initializers/session_store.rb file.
Given that there are a number of Fedena instances still being used I have not disclosed the secret key in full within this post. Using the secret key, it was possible to use a a Ruby deserialization attack module via the Metasploit framework.
Utilising the SECRET key within the Metasploit module settings gains reverse shell access:
This research was undertaken using an instance of Fedena 2.3 in Docker, exploitation resulted in “root” level privileges posing a critical risk to any school who has deployed Fedena using this image. Fedena's installation guide did not include steps to configure a specific OS user account with low privileges. It is therefore unclear what OS privileges would be gained by exploiting this for self-installed versions of Fedena.
Given that the secret value is openly available via GitHub, it is trivial for an attacker to use this information alongside the Metasploit module to gain access to an underlying server. As a result, all instances of Fedena using the static secret value will be vulnerable to this attack. Additional research noted that versions 5.0 of the Ruby on Rails framework is not susceptible to such deserialization attacks.
Persistent Cross-Site Scripting:
The application was vulnerable to persistent Cross-Site Scripting (XSS) via the input field for the School/College Name located at the Settings Tab > General Settings when authenticated as the ‘Admin’ user. The payload included a simple “alert(1)” JavaScript call. This is safe for the reader to use when replicating the issue because it is not malicious. The following screenshot notes the XSS Payload being inserted.
As a result, the payload is added into a HTML div element with the id of “institution-name” as shown: 
Further investigation noted that the HTML element "institution-name” was present throughout the web application when authorised as the “Admin” user. Subsequently, browsing to any page when signed in as this user would result in the previously noted XSS payload rendering in the page, as shown:
The risk posed by this vulnerability is “high” due to it being easy to exploit. The threat model for this attack is limited to users who have the privileges of the administrator role to make amendments withing the ‘Settings’ configuration. As such, the attacker would most likely be an internal user and therefore be an “insider” threat.
Reflected Cross-Site Scripting:
The application was vulnerable to Reflected Cross-Site Scripting ( XSS) via the Search Actions, Events and People input field located at the top right-hand side of the application, as shown.
To test the vulnerability, a simple XSS payload was inserted whilst authenticated to the application using the “Student” role. The payload included a simple “alert(1)” JavaScript call. This is safe for the reader to use when replicating the issue because it is not malicious.
Further investigation noted the vulnerability existed site wide for all authenticated users. The following screenshot notes a similar XSS Payload being reflected whilst using the Admin user.
