🎯Principal

Hacking "Principal": JWT Authentication Bypass, SSH CA Exploitation, and Cryptographic Misconfigurations

The conquest of the "Principal" machine demonstrates how a single cryptographic oversight in a modern library can lead to a total system compromise. This operation transitions from a sophisticated JSON Web Encryption (JWE) authentication bypass to lateral movement via hardcoded secrets, finally concluding with the exploitation of an internal SSH Certificate Authority (CA). It highlights the importance of understanding not just that a vulnerability exists, but the mechanical details of how tokens are parsed and how trust is managed in SSH environments.

The Cryptographic Crack: pac4j-jwt Auth Bypass

The initial reconnaissance via Nmap revealed a Jetty web server running on port 8080. The HTTP headers explicitly identified the backend as pac4j-jwt/6.0.3. This specific version is vulnerable to CVE-2026-29000, a critical flaw involving imbalanced trust in JSON Web Encryption (JWE) objects.

After analyzing the app.js file, the attack surface became clear. The application expected a JWE token encrypted with the server's public RSA key (found at /api/auth/jwks). However, the library failed to properly validate the "inner" JWT if the algorithm was set to none.

By crafting a Python script using the jwcrypto library, I performed the following:

• Created a "Plain" JWT with the alg: none header.
• Set the claims to include sub: admin, role: ROLE_ADMIN, and the required iss: principal-platform.
• Wrapped this insecure JWT inside a JWE layer using the server's public RSA key.

Mindset Note: We assumed that the backend might trust the inner content of a decrypted JWE without further verification. By injecting this token into the browser's sessionStorage, I bypassed the login screen entirely and landed in the administrative dashboard. Always investigate the specific versions of authentication frameworks; a "secure" encryption layer (JWE) does not automatically make the underlying identity (JWT) valid.

Pivot via Dashboard Secrets: Credential Harvesting

Once inside the administrative panel, the goal shifted to lateral movement. Administrative dashboards are often treasure troves of infrastructure details.

The "Users" tab revealed a service account named svc-deploy, noted for "automated deployments via SSH certificate auth." More importantly, the "System Settings" page leaked an encryptionKey value: D3pl0y_$$H_Now42!. In HTB environments, what is labeled as an encryption key is frequently a reused password for system users.

Testing this hypothesis, I attempted an SSH connection: ssh svc-deploy@10.129.244.220. Using the leaked key as the password proved successful, granting a stable shell and the user flag.

Mindset Note: Credential reuse remains a top-tier attack vector. We observed a service account and a complex-looking string in the settings; we immediately tested the link between them. Never ignore "notes" in a user database; they often provide the roadmap for the next step in the kill chain.

Forging the Royal Seal: Root via SSH CA

The path from svc-deploy to root required an understanding of SSH Certificate-Based Authentication. While checking our group permissions (id), I noticed membership in the deployers group. This group had read access to /opt/principal/ssh/.

Inside this directory, I found the CA Private Key (ca). This is the "Master Key" for the entire server's SSH trust model. The system's sshd configuration was set to trust any key signed by this specific CA.

To exploit this, I followed a professional certificate forgery process:

1. Preparation: Moved to /tmp and copied the CA key. I used chmod 600 to satisfy the strict security requirements of SSH tools.
2. Key Generation: Created a new, temporary RSA key pair on the target machine.
3. The Forgery: Used ssh-keygen to sign my temporary public key with the stolen CA private key. By using the n root flag, I explicitly instructed the certificate to identify the bearer as the root user.
4. The Final Strike: Used the newly signed certificate to SSH into the local loopback address: ssh -i my_root_key root@127.0.0.1.

The server checked the certificate, saw it was signed by its trusted CA, and granted immediate root access without a password.

Mindset Note: We identified that the server trusts a "Certificate Authority" rather than individual keys. By obtaining the CA's private key, we effectively became the identity provider for the machine. In any environment using SSH certificates, the CA private key is the single most sensitive file on the system.

Key Concepts and Takeaways

• JWT "alg: none" Vulnerability: Even when tokens are encrypted (JWE), the underlying logic must still verify the signature of the claims. Cryptographic wrappers do not fix logic flaws.
• SSH Certificate Authority (CA): Unlike standard SSH keys (where you add a public key to authorized_keys), the CA model trusts any key signed by a specific private key. Protecting this CA key is paramount.
• Bypassing SSH Security Checks: SSH binaries will refuse to work with private keys that have "loose" permissions. Using chmod 600 is a technical requirement for the exploit to run.
• Hardcoded Secrets in Web Apps: Configuration pages and environment variables are primary targets during post-exploitation. Developers often use descriptive names for keys that actually serve as passwords.
• Information Leakage in Frontend Code: The app.js file provided the entire JWT schema and the location of the JWKS endpoint, proving that "Security by Obscurity" is not a defense.