There is no indication that these issues have been exploited or known outside of the Northern.tech team, and we have not found any effective ways these issues could be exploited (see explanation below), but still choose to be transparent about the security issues we've discovered and fixed. These issues have already been fixed for customers of hosted Mender. On-premise customers have already been notified and need to upgrade to version 3.7.7 or later versions to fix the issues.
The REST APIs for SAML and OIDC, require the backend to make HTTP requests based on the user input. These APIs would cause the backend to follow redirects and make HTTP requests based on the user supplied data, without implementing proper protections. This could allow a malicious user to make internal API GET requests inside the Mender backend, which they are not supposed to.
In order to leverage this vulnerability, an attacker would need authenticated access to an admin level account, which has access to change SSO settings. If you use a Mender on-prem in a single-tenant setup, with a minimal number of administrators, there is limited concern here, as an attacker with access to an admin account would have access to a lot of damaging operations anyway. However, in a multi-tenant setup (such as hosted Mender), it’s possible to gain admin level access in one tenant (organization), and attempt to use that to affect other tenants / organizations. Note that while it was possible to get the backend to make HTTP requests, we are not aware of any effective ways to exploit this, because:
To see if this issue has been exploited, simply open up the SSO configuration in the UI, and verify that the URLs are correct. In a multi-tenant environment, you can run the following mongosh script to dump all SSO configuration:
db.getSiblingDB("useradm").sso.
find({}, {tenant_id: 1, idp_raw_xml: 1}).
forEach(doc =>
{doc.idp_raw_xml
&&
print(`${doc.tenant_id} SSO config XML:\n${doc.idp_raw_xml}\n`)
})If you are using hosted Mender, this issue has already been fixed and you do not have to take any action. For customers running Mender Enterprise on-prem, the issue was fixed in 3.6.6 and 3.7.7. Upgrading to these versions, or later versions, will resolve the issue.
Similar to the other issue, we also discovered some SSRF issues specific to hosted Mender. These issues have been fixed, and as a hosted Mender user, you do not need to take any action.
An admin user with access to change SAML / OIDC settings, could affect what HTTP requests the Mender backend would make, without restricting it to the intended purpose, which was fetching SAML OIDC identity provider metadata from a URL. The most obvious way to try to exploit this is to target internal API endpoints, hoping to access / affect other tenants. However, we are not aware of any effective ways of exploiting this, for the same reasons as the CVE above (GET request only, no way to get response, no GET API to target for making changes).
We have verified in the database that this issue was not being exploited in hosted Mender prior to being fixed.
We have fixed the issue in hosted Mender and you do not have to take any action. This issue was specific to hosted Mender, not present in Mender LTS (on-prem).
If you have any questions or need assistance, don’t hesitate to contact support:
If you believe you have discovered a security issue in one of our products, see our security.txt file for information about how to responsibly disclose security vulnerabilities:
https://northern.tech/security.txt