CVE-2024-35223 - Dapr gRPC Proxy Leaks App Tokens — Deep Dive, Exploit Details, and How to Stay Safe

Dapr is quite popular among cloud-native engineers. It provides a portable, event-driven runtime for building distributed applications across cloud and edge, making microservices easier to build and secure. But, with great adoption comes great responsibility. Recently, CVE-2024-35223 exposed a critical vulnerability related to Dapr's handling of authentication tokens — especially when Dapr acts as a gRPC proxy.

Let’s break down what went wrong, how the vulnerability works, how you could exploit it, and, most importantly, how to stay safe.

What is CVE-2024-35223?

This vulnerability happens when Dapr is used as a gRPC proxy for remote service invocations between microservices. Instead of performing proper token management, Dapr accidentally forwards the _invoker_ app's token when proxying a request, rather than using the _invoked_ app's token.

Why is this dangerous?
Because the invoked service gets to see the invoker's app token, which it was never supposed to access. This opens the door for lateral movement and attacks that could compromise service authentication boundaries.

If you use the Dapr App API token functionality to protect your microservices.

Users on any Dapr version before 1.13.3 are vulnerable.

Service A wants to call Service B using Dapr as a proxy.

2. Service A sends a gRPC request through Dapr-sidecar A, with its own app token in the dapr-api-token header.
3. Dapr-sidecar A should relay the request to Dapr-sidecar B, _without passing along its own app token_.

In the Dapr sidecar, the forwarding logic naively copies the token header

// Hypothetical code
req.Header.Set("dapr-api-token", invokerAppToken) // Incorrect: uses invoker's token!

When it should have sourced the _invoked app’s token_ from Dapr's local configuration

// Secure code
req.Header.Set("dapr-api-token", invokedAppToken) // Correct: uses target's own token!

Proof of Concept: Token Leak in Action

Here's a simple demonstration in Go pseudo-code showing how Service B could capture and log incoming tokens:

// Service B gRPC handler
func (s *server) HandleRequest(ctx context.Context, req *pb.Request) (*pb.Response, error) {
    token := md.Get("dapr-api-token") // md = metadata from context
    fmt.Printf("[!] Received token: %s\n", token)
    // Token now leaked!
    return &pb.Response{}, nil
}

With Dapr versions before 1.13.3, Service B would log the token belonging to Service A — an obvious security risk.

Attacker simply listens for and dumps any token sent in the dapr-api-token header.

- Attacker can now use Service A’s token to impersonate Service A when talking to other Dapr APIs or services, potentially bypassing security.

This is especially dangerous in multi-tenant environments.

The fix was released in Dapr 1.13.3.

Upgrade as soon as possible:
- Dapr 1.13.3 Release Notes
- Official Advisory *(replace with actual link when available)*

If you can't immediately upgrade, consider disabling sensitive features exposed over gRPC and monitor for unexpected token sharing.

References

- GitHub Security Advisory for CVE-2024-35223
- Dapr Issue Tracker – Token Leak
- Dapr Documentation: App API Tokens
- Dapr Release v1.13.3

Summary

CVE-2024-35223 affects any team using Dapr as a gRPC proxy with application tokens. The core issue is a leak of the *invoker’s* app token to the invoked app, unintentionally breaking boundaries of trust. This makes privilege escalation and lateral movement easier for attackers.

Immediate action:

Educate your team on API token handling.

Stay vigilant — microservices are cool, but security is cooler.


To stay current with Dapr updates and security issues, follow Dapr's official GitHub releases and security advisories. Always audit dependencies and practice least-privilege through proper service segmentation and token management!

Timeline

Published on: 05/23/2024 09:15:09 UTC
Last modified on: 06/04/2024 17:34:03 UTC