Security Flaws discovered in the Pandemic Management System SORMAS

Health departments in Germany increasingly employ the open source software SORMAS for contact tracing. Until recently, attackers could have accessed SORMAS

Lesezeit: 7 Min.
In Pocket speichern
vorlesen Druckansicht Kommentare lesen 1 Beitrag

(Bild: HZI)

Von
  • Andreas Kurtz
  • Benjamin Kraft

(german version: Sicherheitslücken im Pandemie-Management-System SORMAS)

SORMAS, the Surveillance, Outbreak Response Management and Analysis System, is chiefly developed by the German Helmholtz-Zentrum für Infektionsforschung (HZI), a research institute dedicated to studying infectious diseases. This software is used for contact tracing and to track infection chains. Originally designed to help contain the outbreak of the Ebola epidemic in West Africa in 2014, SORMAS has been adopted by German government agencies in the fight against the novel coronavirus.

Mehr von c't Magazin Mehr von c't Magazin

In 2016 SORMAS became an open source project. Its source code is available on Github, making it easy for countries and agencies around the world to start using it for management with little bureaucratic fuss. A scan conducted by German computer magazine c’t revealed dozens of active SORMAS installations around the globe. Usually, such systems compile names, addresses and test results as well as quarantine orders for infected citizens in addition to tracking their potential contacts. If such sensitive information were easily accessible, fell into the wrong hands or could even be manipulated, it would mean grave consequences not only for the people who were directly affected, but for the overall fight against the pandemic.

As late as the middle of March 2021, every installation of SORMAS automatically created and activated numerous unsecured default accounts, even including an account with administrative privileges. These accounts were meant for demonstration and testing purposes, with their simple passwords hard-coded into the program's source. Anyone who took the time to study the code would have been able to access running SORMAS servers via the internet and to read, edit or delete personal information stored there at will.

Such standard accounts with static passwords have repeatedly caused seriously problems in the past. They also violate the "security by default" paradigm, which calls for software to be configured as securely as possible in its default state.

Sormas Account Types

(Bild: SORMAS ÖGD)

At its core, SORMAS consists of a back-end server based on Jakarta Enterprise Edition, with a web front-end acting as a user interface. A supplementary Android app is available as well, which communicates with the back-end via a REST API. Pre-built Docker images are freely available to facilitate the use of this system.

To bring together the complex processes of epidemic management and all of the groups of people involved therein using a single system, SORMAS offers a comprehensive role concept with varying authorization levels. Individuals belonging to the role group "Hospital Informant", e.g. someone working in a clinic, are responsible for recognizing suspected cases in the population and report them to the system. Next, a "Laboratory or Surveillance Officer/Supervisor" is meant to analyze and verify the incoming information. "Case/Contact Officers or Supervisors" check confirmed cases and quarantine measures, monitor them, and follow up. Lastly, administrators can be granted comprehensive rights and permissions in order to manage the system, its accounts and users.

Problematically, SORMAS automatically created and activated an account for each of these roles upon installation up to and including version 1.57. Their passwords were identical to the accounts' user names.

By evaluating the digital certificates used by SORMAS (certificate transparency logs) and through simple scans using pertinent search engines, c’t discovered a number of potentially vulnerable SORMAS installations at the beginning of February. Some were located in Europe, others in Africa, India or Australia. Since insecure default settings are rarely corrected later, there's a good chance that at least some of the systems we found were configured with default accounts and passwords.

When asked about these issues, the HZI responded that it did not consider them vulnerabilities. For example, the HZI argued, the changelog explained that the automatically created default accounts were not meant for productive use, but only for demonstration and testing purposes. Administrators were reminded to remove these accounts or to change the associated password on production systems.

If, however, the administrators forgot to do this or simply didn't read the changelog, the accounts stayed active and the systems remained vulnerable. The system itself did not warn admins about active default accounts with unchanged passwords.

According to the HZI, most German health departments should not be affected. A total of 336 subsidiaries applied for their instances of SORMAS through the joint SORMAS@DEMIS project, with an IT service provider installing, configuring and running them. None of these instances were set up with default logins, and each one received a unique administrator password. Configuring the SORMAS instance further and operating it falls in the purview of the individual agencies or their subsidiaries. It remains unclear how many of the remaining 39 health agencies attached to the Robert Koch Institute (RKI) in Germany forego this service, choosing to configure and operate SORMAS on their own.

The developers at the HZI heeded c’t's warning and changed SORMAS' standard configuration so that future installations would no longer create default accounts during the initial setup. The new behavior rolled out with SORMAS version 1.58 in March.

However, this official fix did nothing to address existing installations. Even with the newest patches applied, default accounts with hard-coded passwords remained active if they had already been created. Additionally, SORMAS still did not warn about the administrator account it was creating with every new installation, continuing instead to use an identical, hard-coded password each time.

In its changelog on the GitHub page, the HZI lists the forced password change as a "Feature". However, users are not told this is an important security update.

Release 1.59 was meant to solve these remaining issues, and this version was slated to be pushed out to all of the health agencies overseen by the HZI by May 14. c’t had also contacted a research group at the Hochschule Heilbronn (Heilbronn University of Applied Sciences) specializing in cybersecurity in medical applications. The group headed by Prof. Dr.-Ing. Andreas Mayer recognized the problems we had identified and provided a solution in the form of fresh code on short notice.

The code supplemented by the team in Heilbronn now warns SORMAS users if the system finds default accounts and forces administrators to change the passwords for affected accounts -- including that of the administrator.

A look at the activity on their GitHub page reveals that the SORMAS team has been busy, adding new features, improvements and bug fixes in quick succession. This certainly deserves praise. At the same time, we can't help but wish that the team had taken more decisive action and communicated in a more transparent manner -- not just regarding the original security flaw, but also where the fixes were concerned and what they required users to do.

Considering the sensitive nature of the health data and personal information the SORMAS servers process, a whole slew of additional measures and improvements come to mind. One need only look at the OWASP application security verification standard for inspiration, which lists an entire catalog of criteria to safeguard web applications. Its section 2 details the requirements for secure authentication, such as two-factor authentication, to name an example.

As the cooperation with the research group from Heilbronn has shown, the team at the HZI is both open to accepting external help and grateful for it. Anyone who is willing to lend a helping hand on GitHub will be welcomed with open arms.

Agencies and institutions that use SORMAS should ensure that all of the default accounts have either been disabled or have had their passwords changed. Additionally, installing the most recent release is highly recommended in order to fix vulnerabilities before attackers can exploit them. SORMAS 1.59 is available at Github.

(hag)