Entra Application Best Practices

[SanderBerkouwer]

Hi all,

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.

Authentication libraries
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

These permissions are tied to the way that VB365 gets provisioned withint the Entra tenant, but could be further optimized to reduce the risk of VB365 getting abused in supply chain attacks.

[Mike Resseler]

Hey Sander,

Some of these items are being looked into, indeed after the Midnight Blizzard. However, some of those can not be changed. If we don't have those risky permissions and roles, we simply cannot do backups or restores. So those are obviously things we will need to continue to keep.

I'm not sure I understand your concern around MSAL? I do believe we use the correct one?

We certainly do not store credentials as plain text in the config but we do indeed use the DPAPI. Why do you not consider this secure enough anymore?

[SanderBerkouwer]

Hi Mike,

Thank you for your answers.
It's good to know that some of these items are already looked into.

Risky role: Cloud Application Administrator
The Cloud Application Administrator role is specifically mentioned in the current Midnight Blizzard information (here and here). As far as I'm aware, the Cloud Application Administrator role that is assigned to the VB365 enterprise application is not needed for backups or restores. Instead, this role seems to be used to (setup and) maintain the enterprise application, (check and re-) assign permissions and, potentially, update the certificate. If these management actions could instead be provided by an admin manually or through script, this privileged role assignment may be omitted. Additionally, a workload identity premium license could then also be omitted as the enterprise application would impose a lot less risk in terms of roles and permissions.

DPAPI
The Microsoft Data Protection Application Programming Interface (DPAPI) is a Windows API tool to enable storing sensitive data in a way that it is encrypted but still decryptable. I applaud its use by Veeam. However, the problem with DPAPI is its decryption functionality is available to anyone with interactive access to the Windows Server installation running VB365 (and sufficient time to exploit the monthly slew of vulnerabilities that allow privilege escalation to SYSTEM). Tijl de Neut explains it here. From a supply chain attack perspective, I'm afraid this could make the Windows Server running VB365 the ideal candidate for compromise towards lateral movement from on-premises to the Entra environment.