Skip to content

Persistent Memory in Gemini [InternetCTF] Secure "pow-bypass" mechanism and address health check vulnerability #419

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: v1
Choose a base branch
from

Conversation

Qchains
Copy link

@Qchains Qchains commented Jun 7, 2025

The application exposed a sensitive ECDSA private key intended for a proof-of-work (pow) bypass mechanism within a Kubernetes Secret named "pow-bypass" located in the "kctf-system" namespace. The application also exhibited a vulnerability in its health check mechanism, which could be manipulated to allow extended access to the application's dashboard. By exploiting this health check bypass, an attacker could gain prolonged access to the dashboard, where information about Kubernetes Secrets could be observed. Subsequently, using Kubernetes command-line tools (or potentially through exposed APIs), the attacker could retrieve the contents of the "pow-bypass" Secret. The data within this Secret contained a base64 encoded ECDSA private key under the key "pow-bypass-key.pem". Decoding this value revealed the private key in PEM format, which served as the flag for the InternetCTF challenge, effectively bypassing the intended proof-of-work security measure.

Impact:

This vulnerability allows a complete bypass of the intended proof-of-work mechanism. The exposure of a private cryptographic key, a highly sensitive credential, can have significant security implications. While direct Remote Code Execution was not achieved, the exposed key grants unauthorized access to the challenge's flag, compromising the integrity of the competition. In a real-world scenario, exposure of such a key could lead to unauthorized authentication or impersonation, depending on its usage.

@Qchains
Copy link
Author

Qchains commented Jun 7, 2025

the .pem and the hexadecimal is not being exposed in this report, but it can be reproduced via curl, and I can provide that later... I just am trying to figure out the patch for this is all on 0 day...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant