Exploiting SSRF & Redis Unauthorized Access: A Step‑by‑Step Internal Network Attack

1. Introduction

The author, a senior security researcher from 360, focuses on web vulnerability discovery, analysis, and security tool development. The article presents two combined‑vulnerability scenarios to show how attackers view and exploit common operational weaknesses.

2. Scenario One – SSRF Attacks on Redis Services

2.1 SSRF Principle

SSRF (Server‑Side Request Forgery) allows an attacker to make the vulnerable server request arbitrary URLs, including internal resources. If the server does not validate the URL type, target, or allowed range, it can be tricked into fetching internal services such as Redis.

Typical misuse includes replacing an image URL with an internal address; the vulnerable service then retrieves the internal resource and returns it to the attacker.

Key mistakes: No URL type check, no image‑only validation, and no restriction on internal or sensitive addresses.

2.2 SSRF Exploitation Techniques

Attackers can use SSRF for internal port scanning, Web fingerprinting, and protocol conversion (e.g., http → file, gopher) to send arbitrary data to internal services.

By crafting a gopher URL, an attacker can transmit raw Redis commands to the internal Redis instance.

2.3 Redis Unauthorized Access

Redis often runs with default configurations that allow unauthenticated access when misconfigured. Attackers can read, modify, or delete data, and even write files if the Redis process has filesystem permissions.

2.4 Combining SSRF and Redis

When a server vulnerable to SSRF also supports the gopher protocol, an attacker can embed Redis commands in a gopher URL, trigger the SSRF request, and execute those commands on the internal Redis service, achieving arbitrary code execution or data manipulation.

3. Scenario Two – Dangerous Serialization & Weak Middleware in Distributed Systems

3.1 Unsafe Serialization

Serialization enables object transfer between applications. Improper deserialization in languages such as PHP, Java, or Python can lead to remote code execution.

3.2 Celery Message Queue Inspection

Celery, a popular Python distributed task framework, often uses Redis or MongoDB as a broker and serializes messages with pickle or JSON. If an attacker can inject malicious payloads into the broker, the worker will deserialize them, potentially executing arbitrary code.

3.3 Vulnerable Middleware

Large numbers of Redis and MongoDB instances are exposed publicly without authentication, making them attractive targets as Celery brokers. Attackers can identify which services act as brokers and inject malicious messages.

3.4 Attack Flow

By controlling the broker, an attacker crafts a pickle payload containing malicious commands, injects it via the broker, and the Celery worker deserializes and executes the payload, achieving remote command execution on the worker host.

4. Conclusion

SSRF vulnerabilities that lack proper outbound request restrictions, combined with unauthorized Redis access and unsafe serialization in distributed task queues, create powerful attack chains that can compromise internal services and gain full system control. Proper input validation, authentication, and safe deserialization practices are essential to mitigate these risks.