Listen to this Post
How CVE-2024-XXXXX Works
The vulnerability exists in the `VolumeServer.FetchAndWriteNeedle` gRPC endpoint of SeaweedFS volume servers. This RPC is designed to fetch data from a caller-supplied remote endpoint and write the response into a needle (a blob of data). Prior to version 4.24, this RPC performed no authentication and no validation of the target endpoint. This means anyone able to reach a volume server’s gRPC port could coerce the server into issuing requests to arbitrary hosts.
The lack of validation allows an attacker to specify internal or sensitive addresses, including loopback (127.0.0.1), link-local, RFC 1918 private IP ranges, and cloud metadata endpoints such as 169.254.169.254. On cloud deployments, this exposes instance metadata and IAM credentials. Furthermore, it can be used to reach otherwise-unexposed internal services, making it a classic SSRF vulnerability with response read-back.
The volume server’s gRPC plane is unauthenticated by default, requiring no credentials for exploitation. Critically, even if the documented JWT signing keys are configured, the hardening does not apply to this RPC, leaving it exposed. The affected components are `weed/server/volume_grpc_remote.go` (specifically the `FetchAndWriteNeedle` function) and weed/remote_storage/s3/s3_storage_client.go.
The fix in version 4.24 introduces two key protections: admin authorization is now required for the RPC, and a guarded dialer refuses connections to loopback, link-local, RFC 1918, and IMDS destinations. This dialer resolves the host itself and pins the resolved address for the duration of the request, effectively defeating DNS-rebinding attacks. The Rust volume server carries the equivalent endpoint validation. As a workaround, administrators can restrict volume server gRPC ports to trusted hosts via firewall or network policy and enable mTLS via security.toml.
DailyCVE Form:
Platform: SeaweedFS
Version: < 4.24
Vulnerability: SSRF
Severity: Critical
date: 2024
Prediction: 2024-04
What Undercode Say:
The `FetchAndWriteNeedle` RPC is the entry point for this critical SSRF vulnerability. Before 4.24, it lacked authentication and endpoint validation, allowing attackers to force the volume server to make arbitrary requests to internal and cloud metadata services. The fix in version 4.24 adds admin authorization and a guarded dialer that blocks requests to internal and metadata endpoints, while also pinning the resolved address to prevent DNS rebinding. The following commands and code snippets illustrate the vulnerable and patched states.
Check the version of your SeaweedFS volume server:
weed version
Inspect the gRPC service definition for `FetchAndWriteNeedle`:
grep -r "FetchAndWriteNeedle" weed/pb/volume_server.proto
Review the vulnerable code in `weed/server/volume_grpc_remote.go` (pre-4.24):
// Vulnerable: No authentication or target validation
func (s VolumeServer) FetchAndWriteNeedle(ctx context.Context, req pb.FetchAndWriteNeedleRequest) (pb.FetchAndWriteNeedleResponse, error) {
// Directly fetches from req.RemoteEndpoint without validation
}
The patched version (4.24+) includes a guarded dialer:
// Patched: Requires admin authorization and uses a guarded dialer
func (s VolumeServer) FetchAndWriteNeedle(ctx context.Context, req pb.FetchAndWriteNeedleRequest) (pb.FetchAndWriteNeedleResponse, error) {
if !s.hasAdminAuthorization(ctx) {
return nil, status.Errorf(codes.PermissionDenied, "admin authorization required")
}
dialer := guardedDialer{}.WithValidation()
// Refuses loopback, link-local, RFC1918, and IMDS destinations
}
Exploit: (Educational Purposes!)
An attacker can exploit this by sending a crafted gRPC request to the volume server’s port (default 8080). The request specifies a target such as the AWS metadata endpoint:
Example using grpcurl to call FetchAndWriteNeedle with a malicious target
grpcurl -plaintext -d '{"remote_endpoint": "http://169.254.169.254/latest/meta-data/iam/security-credentials/"}' <volume-server-ip>:8080 volume_server_pb.VolumeServer/FetchAndWriteNeedle
If the volume server is running on a cloud instance, this request would return the IAM role credentials, allowing the attacker to assume the role and access cloud resources. The same technique can be used to probe internal services, effectively turning the volume server into a proxy for internal network scanning.
Protection:
- Upgrade: Immediately upgrade to SeaweedFS version 4.24 or later.
- Network Segmentation: Restrict access to the volume server’s gRPC port (default 8080) to only trusted hosts using firewall rules or network policies.
- mTLS: Enable mutual TLS (mTLS) via the `security.toml` configuration file to authenticate clients.
- Monitoring: Monitor logs for unusual `FetchAndWriteNeedle` calls, especially those targeting internal IP ranges or cloud metadata endpoints.
Impact:
- Confidentiality: Exposure of cloud instance metadata and IAM credentials, leading to potential compromise of the entire cloud environment.
- Internal Network Access: The volume server can be used as a pivot to access internal services that are not exposed to the public internet, such as databases, internal APIs, and configuration servers.
- Data Exfiltration: An attacker can read responses from internal services, potentially exfiltrating sensitive data.
- Lateral Movement: The obtained credentials or internal service access can be used to move laterally within the infrastructure.
- CVSS Score: This vulnerability is considered Critical due to the ease of exploitation (unauthenticated, network-accessible) and the high impact on confidentiality and internal network security.
🎯Let’s Practice Exploiting & Learn Patching For Free:
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
