CIPP Vulnerability Finding – A Third-Party Risk Story

Prior to proceeding with this article, it is important to highlight that the vulnerability is still not fixed at this time but the finding has been disclosed to the vendor and this article is now being published following the mutually agreed upon publish date.

This is in understanding that the severity of this vulnerability was deemed low by Exigence, due to multiple conditions needing to be met for attackers to successfully exploit the vulnerability, as well as part of the overall risk being owed to multi-tenant applications in the Microsoft Entra service.

Background

CIPP is a solution commonly used by IT Service Providers (ITSP) to manage multiple Microsoft Cloud (i.e. Microsoft 365 and Entra) tenants via a central interface. The application is highly regarded amongst the IT community, due to its novel multi-tenant management capabilities, primarily addressing common shared pain points amongst ITSPs, tasked with managing a seemingly endless set of policies and settings, across multiple tenants.

CIPP’s popularity has continued to grow rapidly since its release, due to multiple reasons including:

• CIPP’s comprehensive and dynamic development, seemingly maintaining pace with the rapidly ever-changing Microsoft Cloud technologies.
• CIPP offering the solution to ITSPs in a managed or a self-hosted option.
• CIPP offers its self-hosted solution for free.
• CIPP is open source.

Through CIPP, ITSPs no longer need to develop and maintain custom solutions to manage and monitor an ever-expanding set of configurations and policies in multiple tenants but instead, can now monitor or set desired configurations within a single page and in some cases, with a single click of a button, at scale.

The Vulnerability

CIPP provides a feature called Standards, which allows administrators to apply recommended security controls within Microsoft Cloud tenants. Using Standards, ITSPs can apply industry ‘standard’ (best practice) security controls, consistently and at scale via the CIPP application interface.

The vulnerability stems from the ‘Require admin consent for applications (Prevent OAuth phishing)’ Standard, where an inconsistency was discovered with the CIPP applications interface (front-end) and the underlying PowerShell scripts. This script in particular, is responsible for configuring the standard within tenants, via the Microsoft Graph Application Programming Interface (API).

This Standard’s original intention is to ensure that all application integrations with Microsoft Cloud (via API) are controlled, to mitigate common attacks which leverage the legitimate feature, to deceive users into granting (consenting) malicious applications access to their accounts and/or data.

Within the CIPP interface, an option is presented to enable this standard and to also include exclusions to the standard, thus allowing an excluded application to be used in a tenant. However, once enabled, the underlying script was instead configuring a default exclusion for a Microsoft multi-tenant application. This exclusion is not reflected within the CIPP interface, effectively adding an exception outside the knowledge of the CIPP Administrator.

The Discovery

Upon reviewing the security posture of a Microsoft Entra tenant, our security team had identified that the tenant was being managed by CIPP, with a custom policy being configured for application consent settings.

Once a custom policy is configured in Microsoft Entra, the configuration is no longer viewable in the Entra interface and has to be reviewed via the Microsoft Graph API. This interface design unfortunately further adds to the obscurity of the policy’s current configuration, due to CIPP’s interface also not showing the exclusion.

To further understand the policy configuration, our security team had analysed the consent policy and its configuration via the Graph API, confirming that application consents were not allowed for users but also identifying an excluded application which was not known to our team; Application ID: d414ee2d-73e5-4e5b-bb16-03ef55fea597

Upon investigating the Application ID further, Exigence had discovered that the excluded application was the multi-tenant application published by Microsoft, “Azure Static Web Apps”. This application is used by the Microsoft Azure Static Web App service and allows users to login to custom web applications with their work or school accounts. However, the inclusion of this application was immediately noted to be unnecessary in the context of the CIPP standard.

To ensure this configuration was not isolated to the tenant in question, Exigence subsequently moved to replicate the configuration via a self-hosted instance of CIPP.

Upon investigating the open-source code within CIPP-API public Github repository, Exigence was able to confirm that the default exclusion was included within the source code of CIPP, on line 47. Finally, the independent testing within the self-hosted CIPP instance had revealed the inconsistency, with the application’s interface not showing this default exclusion.

The Risk

Without modelling the potential threats involved with the multi-tenant application being excluded by default, the exclusion could understandably be seen as benign, based on its legitimacy. However, with further analysis of how an attacker might exploit such a vulnerability, we find a path that leads to a valid attack scenario:

1. CIPP is a publicly hosted within a Github repository that is used (forked) by thousands of users on Github, which presumably are mostly ITSPs and IT administrators. Using Github, an attacker can initiate a discovery process to initially identify all Github members who have copied the application.
2. Using the names of the members, attackers can then further discover associated ITSPs, using publicly available information, incl. Github profiles, search engines and social media. Further to this, attackers can then move to discover customers of the ITSPs via public sources (i.e. website affiliations or customer reviews).
3. Once identified, an attacker can then move to create an Azure Static Web App which looks to host malicious code.
4. An attacker can then target vulnerable tenants/users, with a link to the malicious application, via common delivery methods such as email or instant messaging.
5. Due to the application being consented to, users will be presented with their company’s official login page, including company branding in some cases, offering a sense of legitimacy to the underlying malicious web application.
6. Users will then be directed to the malicious web application, where the attack can progress to subsequent stages, including deception measures to retrieve sensitive information or executing malicious code to infect the endpoint.

As highlighted in this attack scenario, the presented risk can be partly attributed to the ‘Azure Static Web App’ application and multi-tenant applications more broadly. However, it is important to highlight that the risks with multi-tenant applications are known and it is industry standard to ensure that application integrations are controlled in some form, to address these risks, hence the Standard within CIPP.

This is where the discovered CIPP vulnerability creates the new risk that has been discovered as part of this vulnerability, primarily via the two following key factors:

• Third-Party supply chain – ITSPs have an extended reach in terms of the client tenants they manage. With the discovery paths presented in this article, the risk likelihood begins to multiply exponentially due to this extended reach and the number of tenants potentially impacted.
• Misconfiguration – Without identifying the vulnerability, administrators will be under the assumption that the CIPP Standard has been applied in their tenant, creating a false sense of security for the risks posed by multi-tenant applications.

The Severity

After analysing the overall risk, Exigence has rated the vulnerability’s severity as ‘low’, due to multiple conditions needing to be fulfilled for successful exploitation, most notably:

• Identification of tenants using CIPP – Although a legitimate discovery path is presented as part of this article, the entailed effort and privacy measures (i.e. private Github profile) will limit the scope of the potentially impacted tenants.
• Identification of tenants with the Standard applied – Tenants managed by CIPP may not have had the vulnerable Standard applied.
• Mitigating Controls – Supplementary security controls may be in place within some tenants/environments (i.e. Conditional Access or web filtering)
• End User Awareness – Exploiting this vulnerability requires end user interactivity which can be greatly hampered by user awareness.

The Lessons

As highlighted in this article, the vulnerability itself does not make up the entirety of the risk identified with Exigence’s findings. Once CIPP has remediated the script to remove the default exclusion, there are two key issues that remain unaddressed:

1. The Azure Static Web App will continue to provide the attack vector.
2. The risk of further security misconfigurations by solutions such as CIPP, either by the solution itself or an administrator.

To begin addressing these remaining issues, organisations and businesses need to ensure that they set the foundation for a Security Governance function within their digital estate, if not set already. Once established, the security governance function can then move to employ the following three key practices and controls within the digital estate, to directly address the risk identified as part of this discovered vulnerability, as well as many others:

• Third-Party Risk Management – Organisations and businesses need to employ internal controls to understand the risks posed to their digital estate by third parties. In the context of this risk, employing a comprehensive process to initially vet and continually assess an ITSP will ensure that the organisation’s/business’s security and compliance requirements are being met, including understanding and addressing the ITSP’s direct and indirect supply chain risks.
• Security Posture Management – Ensuring that processes are in place to continually assess the applicable threats to the digital estate, implementing defensive controls, while also ensuring the continued testing and validation of existing security controls. In this context, validating the application consent Standard (control) independently, would have allowed for the proactive discovery of the vulnerability.
• Application Control – Application control is still often seen as applicable to an endpoint or the network, but with today’s online services (applications/platforms) and native API integrations, application control and its accompanying processes must be factored per platform, where applicable. In the context of Microsoft Entra, organisations and businesses must ensure applications are vetted initially before being granted access to the tenant and data within. Subsequently, applications should be recurringly vetted and continuously monitored (i.e., for anomalous activity).