Fuzzing with Bazel: cc_fuzz_test

Recently I have been fuzzing C/C++ projects built with Bazel using libfuzzer, so I thought to share my learnings on some of the details on how to do this.

Using vault-plugin-secrets-artifactory to generate short-lived Artifactory tokens with a non-admin user

How to use the HashiCorp Vault Secrets Plugin for Artifactory to create short-lived Artifactory tokens scoped to a specific user, without the need for an admin token. The main usecase for this is CI workflows (e.g. Github actions) that can authenticate to vault (e.g. Github’s workflow OIDC) and need access to Artifactory.

snyk test docker --fail-on= workaround

I’m running Snyk to scan docker images and break the build if they have high or critical vulnerabilities:

snyk test --severity-threshold=high --docker $IMAGE_NAME

However sometimes the upstream image has high or critical vulnerabilities (e.g. at the times of writing this, debian), so there is very little action one can take (other than moving to a different base image, which is usually not easy). Thus I only want to break the build if there are high or critical vulnerabilities AND they can be fixed by ugrading the base image.

The security of KeyCloak used as an identity proxy

Recently I was involved in a project where KeyCloak was used as an identity proxy: the target app was configured to use KeyCloak as an SSO, but KeyCloak delegated the authentication further to an other IdP. So on login to the target app, the app would redirect the user to KeyCloak, which would further redirect to the IdP’s login page. Upon authenticating there, the IdP redirected back to KeyCloak, which redirected to the target app. This double-redirect flow happened very fast so it was mostly transparent to the user.

My task was to review the security of this setup and I managed to find a few interesting bugs.

Argo CD Privesc Example Walk Through

My Argo CD Privilege Escalations post describes some privilege escalation possibilities, if Argo CD projects are not configured securely. In this post I’ll show a complete walkthrough on abusing one of these possible misconfigurations.

Argo CD Privilege Escalations

Consider a multi-team GitOps setup with Argo CD: each team has their own repository that holds the team’s Kubernetes yaml files that Argo CD deploys to a shared cluster. Inside the cluster, teams are separated into their own namespaces, and Argo CD only deploys resources to the namespace that belongs to the given team.

Let’s see how this setup can be misconfigured to allow deploying to other team’s namespaces or to the cluster level!

Open-redirect to XSS

Open redirects are generally treated as a low risk issue, due to the limited impact (more convincing phishing). However in certain cases a simple open redirect vulnerability can lead to reflected XSS, which I’ll talk about in this post.

Redirecting in a browser can happen in two ways:

1. The browser gets a 30x HTTP response code (e.g. 302 Found) with the destination of the redirect in the Location header
2. The JavaScript running on a site does the redirect by e.g. window.location.href='https://example.com' or window.location.assign('https://example.com'); or window.location.replace('https://example.com');

If an open redirect vulnerability exist with the second type of redirect, it might be an XSS as well using the javascript: pseudo-protocol. E.g. the following JavaScript code will pop up an alert:

url = "javascript:alert(document.domain)"; // coming from the user in real life
window.location.href= url;

Demo

Cross-app Scripting in Android apps

If an Android app accepts Intents to open a URL in a WebView, then a malicious app installed on the same device might open a javascript:alert(1)-like URL, which will run the provided JavaScript in the context of the victim app’s site (that is currently loaded in the WebView). This vulnerability is called Cross-app Scripting.