1. Postmortem summary

2. Postmortem report

2.1 API call descriptions

We have identified three API calls in the ManagementPortal backend where the authorization check was insufficient: querying the list of all registered subjects, querying the list of all known sources, and querying a single source.

2.1.1 Query all subjects

API path: /api/subjects

Expected behavior: Only subjects that a user has access to are returned. In the current authorization model, that means that the provided JWT must have the SUBJECT_READ scope. In addition:

• OAuth 2.0 clients have access to all subjects.

• Users with the ROLE_SYS_ADMIN role have access to all subjects.

• Users with the ROLE_PROJECT_ADMIN role for projects P and Q, have access to subjects in projects P and Q.

• Users with the ROLE_PARTICIPANT role have access only to their own subject information.

Current behavior: All subjects may be queried by any logged in user. This is the case because the code only checks whether the JWT of the user contains the SUBJECT_READ scope. It does not check whether the user has access to each individual subject that is queried.

Exposed information: each subject contains the following information:

• ManagementPortal user ID that identifies the user inside a RADAR-base installation.

• External ID and link, an optional user-provided ID for the subject in another system that potentially contains PII.

• Creation and modification dates and authors: when the subject was created and last modified and by whom.

• Associated project. This includes

  • Project name

  • Organization

  • Location

  • Start and end dates

  • Custom attributes added by the user via the frontend or via the API

• Sources: any sources associated with the subject. This includes

  • ID

  • Name

  • Type

  • Optionally a physical ID, like a MAC address.

  • Attributes added via the API, like firmware version or OS version.

• Attributes: custom attributes for the subject stored via the API.

Frontend applicability: the ManagementPortal frontend only uses the API call to list all subjects for users with the ROLE_SYS_ADMIN role. For users with the ROLE_PROJECT_ADMIN role in project P, it calls a modified API call that filters the subjects to only include sources associated with project P. This means that the frontend does not have an information disclosure vulnerability.

2.1.2 Query all sources

API path: /api/sources

Expected behavior: Only sources that a user has access to are returned. In the current authorization model, that means that the provided JWT must have the SOURCE_READ scope. In addition:

• OAuth 2.0 clients have access to all sources.

• Users with the ROLE_SYS_ADMIN role have access to all sources.

• Users with the ROLE_PROJECT_ADMIN role for projects P and Q, have access to sources associated with projects P and Q.

• Users with the ROLE_PARTICIPANT role have access to sources associated with them.

Current behavior: All sources may be queried by any logged in user. This is the case because the code only checks whether the JWT is valid. It does not check whether the user has access to each individual source that is queried.

Exposed information: each source contains the following information:

• ID

• Name

• Type

• Optionally a physical ID, like a MAC address.

• Attributes added via the API, like firmware version or OS version.

• Project name, if a project is associated.

• Subject ID, if  a subject is associated.

Frontend applicability: the ManagementPortal frontend only uses the API call to list all sources for users with the ROLE_SYS_ADMIN role. For users with the ROLE_PROJECT_ADMIN role in project P, it calls a modified API call to filter the sources to only include sources associated with project P. This means that the frontend does not have an information disclosure vulnerability.

2.1.3 Query a single source

API path: /api/sources/{sourceName}

Expected behavior: Only sources that a user has access to return a valid result. Otherwise, a Forbidden HTTP status and message is returned. In the current authorization model, that means that the provided JWT must have the SOURCE_READ scope. In addition:

• OAuth 2.0 clients have access to all sources.

• Users with the ROLE_SYS_ADMIN role have access to all sources.

• Users with the ROLE_PROJECT_ADMIN role for projects P and Q, have access to sources associated with projects P and Q.

• Users with the ROLE_PARTICIPANT role have access to sources associated with them.

Current behavior: All sources may be queried by any logged in user. This is the case because the code only checks whether the JWT is valid. It does not check whether the user has access to each individual source that is queried.

Exposed information: each source contains the following information:

• ID

• Name

• Type

• Optionally a physical ID, like a MAC address.

• Attributes added via the API, like firmware version or OS version.

• Project name, if a project is associated.

• Subject ID, if  a subject is associated.

Frontend applicability: the ManagementPortal frontend only presents links to sources that a user has access to, given the rules listed above. However, a user may change the frontend path in the browser to display sources that have not been linked to and that the user should not have access to. This means that the ManagementPortal frontend can also be used to retrieve the above information.

3. Countermeasures

RADAR-base administrators should upgrade their ManagementPortal installation to version 0.8.0 as soon as possible.

Each project must evaluate for itself whether the API call may have unintentionally leaked PII and decide whether and how users should be informed.