We're using Veeam Backup for Microsoft 365 (VB365).
Following the Midnight Blizzard advice from Microsoft, we're trying to apply best practices for the VB365 enterprise application and app registration in our Entra ID tenant.
However, we're running into a couple of issues:
Public Client Flows
The VB365 application registration in Entra ID uses public client flows. This is as designed, but may be improved.
- The credentials that are input during configuration are collected as plain text information.They may be stored as plain text in the config or exposed in logs. I no longer consider DPAPI as an appropriate means to securely store this type of information.
- The default redirect url is http://localhost. It is optional to provide a redirect url in combination with public client flows. The redirect url is is a web address that the user's browser is sent to after they have authenticated with an identity provider. The redirect URI typically contains an authorization code or an access token that the client application can use to obtain the user's identity and access their resources. The redirect URI must be registered with the identity provider and must match exactly the one that the client application sends in the authentication request. Currently, this method is not used.
Veeam regularly updates the Veeam Backup for Microsoft 365 solution, but still it uses an outdated and potentially vulnerable version of the Microsoft Authentication Libraries (MSAL).
Certificate
The VB365 app registration uses a certificate to identify itself. This is a recommended practice from Microsoft. However, The certificate used in the VB365 app registration has a validity period of 10 years. I get that Veeam has chosen the route of least administrative burden and has traded in on certificate lifecycle management and thus security. This is as designed, but the lifetime of certificates on the web should be restricted to 13 months.
Risky permissions and roles
A backup solution will have high-risky API permissions. However, several combinations of permissions and roles are assigned to the VB365 enterprise application and app registration, that have been abused in the Midnight Blizzard attack and have been abused in Business Email Compromise (BEC) attacks:
- The Cloud Application Administrator role assigned to the Enterprise Application
- The EWS.AccessAsUser.All and EWS.full_access_as_app permissions assigned to the App Registration