Full Report
Akash is a decentralized cloud computing platform built for the Cosmos ecosystem. It appears to have offer a product similar to EC2 instances on AWS. There are four main parties involved: Blockchain layer: Handles payments of tokens and used for governance. Application layer: Intermediary between buyers and sellers. Sellers want people to use their resources and buyers need resources. Provider layer: The instance where computational resources are located. There is a daemon from Akash that integrates with the usres to give them access. User layer: Where users buy the resources. On the Akash network, the authentication process is solely down through TLS certificates. Here's the flow: Auser creates a certificate and submits it to the blockchain. The user initiates an mTLS connection with the provider. Provider verifies the client certificate to ensure that it's valid. They check the common name, subject and serial number. The cert is added to the certificate pool of valid users that can access the system. You know what's really important about certificates? The signatures! In this case, the fingerprint is not checked to see if the client certificate and the registered certificate are the same! So, a self signed certificate with the spoofed information is good enough to bypass this. To do this, we generate a self-signed root CA with the target's address in the common name. Next, we add the serial number to the cert of the target. Finally, we use this cert to run arbitrary commands on the instance, giving us free access to everything. How did they fix this? Check the fingerprints! I would guess that since this by design allows for self-signed CAs, they didn't consider the ability to spoof all of the things. Great find by the team at Chainlight!
Analysis Summary
# Vulnerability: Akash Network Provider Authentication Bypass via Certificate Spoofing
## CVE Details
- **CVE ID:** CVE-2024-37152
- **CVSS Score:** 9.9 (Critical)
- **CWE:** CWE-295 (Improper Certificate Validation)
## Affected Systems
- **Products:** Akash Network (specifically the Provider daemon)
- **Versions:** `akash-network/provider` versions prior to v0.6.1
- **Configurations:** Systems utilizing the standard mTLS authentication flow for managing cloud resources via the Provider Gateway.
## Vulnerability Description
The vulnerability exists in the `NewServerTLSConfig` function within the Akash Provider's application logic. While the system uses mTLS for authentication, it fails to perform cryptographically secure validation of client certificates.
Instead of verifying the certificate's unique fingerprint (hash) against the record stored on the blockchain, the provider only checks the **Common Name (CN)** and the **Serial Number**. Because the system was designed to allow self-signed certificates, an attacker can generate a malicious self-signed certificate and manually set the CN and Serial Number to match those of a legitimate deployment owner. The provider's `VerifyPeerCertificate` function accepts these spoofed attributes without verifying the signature or the fingerprint, leading to a complete authentication bypass.
## Exploitation
- **Status:** PoC available (demonstrated by ChainLight)
- **Complexity:** Low
- **Attack Vector:** Network
- **Method:**
1. Identify a target user's address and certificate serial number from the Akash blockchain.
2. Generate a self-signed Root CA and client certificate.
3. Set the `Subject.CommonName` and `Issuer.CommonName` to the target's address.
4. Set the certificate `SerialNumber` to match the target's registered certificate.
5. Connect to the Provider Gateway using the spoofed certificate.
## Impact
- **Confidentiality:** Total (Unauthorized access to data/secrets within containers)
- **Integrity:** Total (Ability to execute arbitrary commands on active instances)
- **Availability:** Total (Ability to shut down or modify deployments)
## Remediation
### Patches
- **Akash Provider v0.6.1:** Implements mandatory certificate fingerprint verification. All providers are urged to update to the latest version immediately.
### Workarounds
- There are no viable local workarounds other than upgrading the provider software, as the vulnerability is inherent to the authentication handshake logic.
## Detection
- **Indicators of Compromise:** Review provider logs for successful mTLS connections where the client certificate fingerprint does not match the known fingerprint associated with the account on-chain.
- **Detection Methods:** Audit the blockchain for multiple certificates sharing identical metadata but different cryptographic signatures.
## References
- **ChainLight Advisory:** hxxps://blog[.]chainlight[.]io/finding-a-critical-vulnerability-in-akash-network-d9c728c2606b
- **Akash Network Github:** hxxps://github[.]com/akash-network/provider
- **Security Advisory:** hxxps://github[.]com/akash-network/node/security/advisories/GHSA-9763-p98v-36f7