Research

Multiple Vulnerabilities in Fedena 2.3 School Management Software

Researchers:

Pentest

Today we publish seven findings within Fedena School Management Software version 2.3 as summarised below:

Common Vulnerabilities and Exposures (CVE)	Vulnerability	Risk
CVE-2021-27980	Authentication Bypass	A remote unauthenticated threat actor can gain control over any user account including the Fedena admin by cookie spoofing using publicly available knowledge.
CVE-2021-27974	RCE	A remote unauthenticated threat actor can execute commands on the operating system using publicly available tooling and available knowledge.
CVE-2021-27979	SQL Injection	An authenticated user can execute arbitrary SQL commands and can compromise all data stored.
CVE-2021-27976	Broken Access Controls	A lower privileged user can execute functionality not visible to them via their UI. Crucially this enabled SQL Injection from a lower privileged user.
CVE-2021-27975 CVE-2021-27977 CVE-2021-27978	3x XSS	An authenticated user can embed arbitrary HTML and JavaScript commands which will execute within the browser of another user. The most likely impact is privilege escalation and subsequently data theft.

Pentest do not take disclosure of vulnerabilities which impact schools, teachers, children, and their parents lightly. That is especially true when there will be no patches to address them. Unfortunately, that is the case here. Making this disclosure timeline one of the longer ones.

Our tale began in late April 2020 at one of our “Hackathon” events. On that occasion, one team chose to focus on School management and e-Learning software. The Covid-19 pandemic was starting out and remote learning was being embraced rapidly. The team wanted to help ensure that this was being done securely. A brief search found Fedena as an open-source target and some time was scheduled to examine it.

Unfortunately, significant vulnerabilities were relatively easy to locate and exploit.

Mitigation Advice

No patches will be created to address the vulnerabilities outlined above. This is because the open-source version of Fedena is no longer supported. Pentest’s number one recommendation is to migrate to a supported product as soon as possible. Migration is the ideal strategy.

The root cause of the two critical risk vulnerabilities is because the server-side secret is shared between all deployments. It is possible to reduce the risks by:

1. stopping the Fedena application server
2. altering the secret (using a securely generated random string); and
3. starting the server again.

Doing so will mitigate both the authentication bypass and RCE vulnerabilities. In effect that would reduce the threat profile to legitimate users of Fedena.

However, it is crucial to point out that all the other vulnerabilities would remain exploitable. It is just that they would only be exploitable by registered users. That reduces the threat profile but does not remove all risks.

If possible, protect vulnerable Fedena 2.3 installations using network segregation and/or VPN controls. Explicitly this means remove the application from the Internet and provide remote access to it over secure channels. This strategy would significantly reduce the risks.

Unfortunately doing this is complex and may cause usability issues for remote based students and parents. Schools are not in control of the availability of IT kit or knowledge at home and so a VPN would effectively exclude users which is not workable.

It is also possible to reduce the risk by configuring a web application firewall or other detection solution to recognise the highlighted risks. However, Pentest Ltd believe that this will also be an incomplete solution.

The following table lists our assessment of the applicability of this approach:

Vulnerability	Applicability
Authentication Bypass	Ineffective because traffic should be identical to legitimate authentication request. Just that the authentication token was spoofed.
RCE	Detection rules should be possible for this.
SQL Injection	Detection rules should be possible.
Broken Access Controls	Ineffective because the traffic is legitimate and detection rules lack the context that user A should not be able to access function B.
3x XSS	Detection rules should be possible.

If you are reading this and you can provide a solution to the others via detection, then we would be delighted to work with you.

While mitigation can reduce the risks ultimately Fedena 2.3 is unsupported software with known vulnerabilities which relies on seriously outdated Rail Gems. Put bluntly it will remain a security risk wherever it is used.

How widespread is this software?

When version 2.3 was released the release page included this statement:

”Fedena now powers more than 40,000 institutions around the world. It includes the most notable implementation in 15,000 Schools of Kerala – India, which is now a case study for successful implementation of big data e-gov projects across the world.”
https://fedena.com/blog/2013/04/fedena-2-3-is-released-to-public-on-teachers-day-of-india.html

After discovering these vulnerabilities Pentest used Shodan, and Google Dork techniques and identified thirty instances online in 2020. This did not match the high number of institutions listed in the release announcement.

The answer may be that Fedena is rarely deployed facing the Internet, but it may remain reasonably popular within schools. Pentest can make no assumptions around how widespread Fedena 2.3 may be on Internal networks since these cannot be detected remotely.

This is not going down in the annals of disclosures that affect millions of sites. However, we were conscious that each exposed installation contains children’s personal information. Exploitation could affect the safety of children making it impactful, nonetheless.

Disclosure Complexity

Disclosure of this was complex for a couple of reasons.

First, the vendor effectively no longer existed. Fedena 2.3 was the final open-source version. It was maintained by ProjectFedena.org. There seems to be no activity at all from ProjectFedena.org or the GitHub repository in the last 8 years. Though there were support tickets on GitHub for people installing it recently indicating some usage. No response was received from ProjectFedena.org via their contact form. This made things complex because there was no vendor to engage with and ensured that no patch was going to arrive to solve the problem.
Secondly, multiple open source and commercial forks of the vulnerable software were observed. A company called Foradian looks to have grown from ProjectFedena.org and they now sell a commercial version known as Fedena Pro. When ProjectFedena.org ended the community tried to take it forward with projects such as “Fedena-Upgradation” and others. Additionally, a post on ProjectFedena.org pointed towards “Sampoorna”. This was a fork of Fedena maintained for use in Kerala, India in over 15,000 schools with over 7 million students.

The forks may or may not be vulnerable to all or some of the vulnerabilities discussed. Neither Fedena Pro, or Sampoorna could be targeted as the vendors did not authorise testing. It is possible that the issues discovered will affect various vendors that have not been located or contacted by us date.

Timeline

[Mid to Late April 2020] – initial discovery by the team after the hackathon.
[11-05-2020] GitHub project – this was not enrolled for security disclosures. Opening a public ticket was not deemed appropriate since this would instantly disclose vulnerabilities publicly.
[11-05-2020 approximately] ProjectFedena.org – related to the GitHub repository directly. This was used to initiate contact. No response was received.
[11-05-2020 and over the next few weeks] Foradian – We contacted Foradian by email to attempt disclosure since it was likely that they were involved in the opensource project initially. Over several emails they stated that 2.3 was no longer supported and were not interested in providing access to Fedena Pro to enable us to confirm that the known issues no longer affected their customers.
[08-07-2020] Sampoorna – contact was made via an email located for the vendor used to maintain this forked version of Fedena. No response was received.
[21-09-2020] Cert India – due to the Sampoorna fork being directly relevant to India’s interests in Kerala contact was made via email. Cert India were sent full technical details for the most significant vulnerabilities along with a request to help with disclosure to Kerala’s schools.
[06-01-2021] NCSC – via the vulnerability reporting service on HackerOne. No impact to UK schools was suspected over the Internet it felt prudent to seek advice before disclosure.
[07-01-2021] Cert India – as shown below they had informed the appropriate authority for necessary action.

[11-01-2021] NCSC – via hacker one. They confirmed the vulnerabilities and stated that our approach to disclose this was appropriate.
[01–03–2021] Mitre.org – Requested CVE Identifiers
[07-05-2021] Mitre.org – Reserved seven CVE identifies.
[10-05-2021] Pentest.co.uk – Prepared this blog post.
[11-05-2021] Pentest – Emailed every vendor with software that might be based on Fedena and schools using it on the Internet (where possible). This included a statement of the seven CVEs, that we suspected they may be at risk, and encouraged them to comment or reply if they wanted to be involved.

In parallel with this timeline the lead consultant sought to identify institutions using Fedena 2.3 online and to privately contact them. Identification was not always successful.

Appeal

Dear reader. How often can you be heroic? Today you can help by sharing this post far and wide to try and reach institutions that may have been missed during the run up to disclosure. If you have any knowledge that anyone is using Fedena then please forward this to them. They are not safe from attack even if they are behind a VPN or Firewall. A legitimate user can exploit their access.