Pentest Results H2 / 2022

At ZITADEL we believe that working transparently creates trust in our project and cloud service. With this mantra as one of the cornerstones of ZITADEL we actively and regularly engage with external security testers to test different scopes of our offerings.

As always we tested ZITADEL against the OWASP Top Ten risks. Besides that we instructed our testers to assess our cloud provider’s configuration to reduce the risk of problematic settings, since we run the majority of our infrastructure on Google Cloud Checkout our trust center if you are interested in what services and providers we use.

TL;DR

The overall result was rated good with only one high issue, which was mitigated during the test. Other issues were minor but nonetheless important for us and were fixed within a few days.

Findings

In the following section I will give you a short summary and comment on the highest ranked issues. You can download the full report here. Findings with a low criticality will be mitigated, if needed, during our regular security operations.

5.1 Privilege Escalation by Actions

“The Actions feature allows an authorized user with the role “Organization Owner” to add a grant to a new external user for a project within another organization's scope. An attacker can utilize this vulnerability to create/escalate its privileges on another organization’s projects.”

During the test it was brought to our attention that the tester was able to use a ZITADEL Action to elevate access rights inside a ZITADEL Instance. Even though this vulnerability only could be exploited if access was granted to deploy new Actions, we decided to publish a CVE and create a mitigation instantly.

Exactly these types of findings are the reason why we think working with external testers is an important part of the integral security of a project.

5.2 Missing Logging for Firewall

“Logging for existing Firewall rules is deactivated. Policy violations will not be logged and thus cannot be monitored.”

We use the Google Cloud Firewall to policy traffic from different networks. Especially traffic flowing from our Google Cloud Run deployment to the VPC Interconnected CockroachDB Dedicated Cluster.

To improve our observability of violations we activated the logging and integrated the information into our monitoring platform.

5.3 Insufficient Monitoring

“No policies were defined in the Google Cloud Platform to be informed about possible changes or security-relevant incidents. An attacker can apply unnoticed changes or perform attacks on the ZITADEL services.”

In the past we mainly used the Google Cloud Monitoring Suite to observe and alert behaviors of our service. After doing this test we revised our standpoint and created an umbrella monitoring platform to ingest all the observability data from many different systems and services we rely on. To specifically address this issue we also incorporated the Google Cloud Audit log.

We will follow-up with an upcoming blog about how we observe and monitor ZITADEL Cloud in more detail.

5.4 Basic Roles in Use / 5.5 Service Account with Admin Privileges

“Basic Google Cloud Platform roles are assigned, this does not follow security best practices as these roles can have extensive permissions.”

“Custom service accounts have administrative privileges assigned. A compromised service account would have extensive permissions on the assigned services.”

Some users had broad permissions for their needs. After highlighting this during the test we removed overarching permissions and integrated the permissions management into our Terraform process where a four-eye process is required for all changes. To keep everything auditable we store our terraform files in a Git repository and we ingest the Google Cloud Audit Events into our monitoring platform.