Hardcoded System User Credentials

Owned by Craig McNally
Last updated: Jul 24, 2023
2 min read

Overview

Unpatched versions of Nolana and Orchid are vulnerable to critical security issues related to system users.  These users are provisioned by modules themselves and are used to perform internal module-to-module operations.  Credentials for these users are hardcoded in the source code.  This makes it trivial to authenticate as these users, resulting in unauthorized access to potentially dangerous APIs, allowing to view and modify configuration including single-sign-on configuration, to read, add and modify user data, and to read and transfer fees/fines in a patron's account, and to read inventory data.

Due to the risk and exploitability of these vulnerabilities, they were embargoed, and details were not fully disclosed until system operators had a chance to patch their systems.

See the following advisories for additional information

Remediation

Unfortunately we are unaware of a workaround.  However, the following releases have been made to patch the aforementioned critical security vulnerabilities:

  • mod-data-export-spring-2.0.2 (Orchid)
  • mod-data-export-spring-1.5.4 (Nolana)
  • mod-remote-storage-2.0.3 (Orchid)
  • mod-remote-storage-1.7.2 (Nolana)

These patch versions will be included in the following official Critical Service Patch (CSP) releases:

  • Nolana CSP #2
  • Orchid CSP #4

System operators are advised to immediately apply this fix for both modules if they haven't done so already.

Patch Instructions

  1. For your flower release configure the new mod-data-export-spring and mod-remote-storage versions, you MUST set the SYSTEM_USER_PASSWORD environment variable. Avoid using values which are easy to guess, such as the module name or the system username.
  2. Deploy the new module versions.
  3. For each tenant $TENANT migrate to the new module version:
    1. For Orchid: curl -d '[{"id":"mod-data-export-spring-2.0.2","action":"enable"},{"id":"mod-remote-storage-2.0.3","action":"enable"}]' $OKAPI/_/proxy/tenants/$TENANT/install?reinstall=true
    2. For Nolana: curl -d '[{"id":"mod-data-export-spring-1.5.4","action":"enable"},{"id":"mod-remote-storage-1.7.2","action":"enable"}]' $OKAPI/_/proxy/tenants/$TENANT/install?reinstall=true
  4. For each tenant verify that the patch has been successfully applied: Go to the UI and try to login. Use the default username data-export-system-user and system-user (for remote-storage) and the new password. NOTE: These system users do not have UI permissions, so once you log in, you won't be able to do anything in the UI/stripes. It's sufficient to check that you're able to authenticate.
  5. You may also want to check the logs for these two modules for any entries which might indicate a problem.

N.B. If you set a non-default system user name by setting SYSTEM_USER_NAME you MUST manually disable or delete the existing system user with the default user name.

N.B. After changing SYSTEM_USER_PASSWORD or SYSTEM_USER_NAME it is NOT sufficient to only redeploy the module; you also MUST reinstall the module as show above.

N.B. Disabling an affected module is NOT sufficient to fix the vulnerability.

Am I a victim?

Unfortunately the Folio Security Team is unaware of a way to conclusively determine if these vulnerabilities have been exploited.  OKAPI does log the user ID for all proxied requests, so you may look for unusual activity associated with either of these users.  Depending on your hosting infrastructure, it may also be possible to look at load balancer and/or reverse proxy logs, but there may not be enough information logged there if request payloads/certain headers aren't captured.  Consider reviewing logs going back to when you upgraded to Nolana.