Deserialización insegura:

el gadget chain explicado sin drama

Seguridad de aplicaciones web  |  unfantasmaenelsistema.com

Serializar es convertir un objeto que vive en memoria —con sus campos, sus tipos y sus referencias— en una secuencia de bytes que se puede guardar en disco, meter en una cookie o mandar por la red. Deserializar es el camino inverso: reconstruir el objeto a partir de esos bytes. Es una operación cotidiana en casi cualquier aplicación: sesiones, cachés, colas de mensajes, llamadas entre microservicios y ficheros de configuración pasan por ahí.

El problema aparece cuando esos bytes vienen de una fuente que no controlas y el formato permite reconstruir objetos arbitrarios, no solo datos. En ese momento el atacante no te envía un valor: te envía la descripción de un grafo de objetos que tu proceso va a instanciar, y con él una cadena de métodos que se ejecutan durante o justo después de la reconstrucción. Esa cadena es lo que se llama gadget chain. Este artículo explica de dónde sale el riesgo, en qué lenguajes y formatos aparece, cómo se detecta y cómo se corta de raíz, sin entrar en la construcción de payloads.

1. Datos frente a objetos con comportamiento

No toda deserialización es peligrosa. Cuando lees un JSON y obtienes cadenas, números, listas y diccionarios, lo peor que puede pasar es que los datos sean incorrectos y tu validación tenga que rechazarlos. No se instancia nada que ejecute lógica por el hecho de existir.

El riesgo llega con los formatos que serializan el tipo además del valor y son capaces de reconstruir cualquier clase disponible en el proceso. Al deserializar, el runtime crea instancias de esas clases y, según el lenguaje, invoca métodos especiales: constructores, callbacks de post-construcción, métodos de lectura personalizados, destructores. Si entre las clases cargadas en tu aplicación (las tuyas, las del framework, las de cualquier dependencia) hay métodos que hacen algo interesante al ejecutarse —escribir un fichero, cargar una clase por nombre, abrir una conexión, invocar un comando—, el atacante puede encadenarlos.

La idea clave: no necesitas un bug en tu código. El fallo es aceptar bytes no fiables en un deserializador potente. Los gadgets ya están en el classpath, puestos ahí por librerías legítimas.

2. Qué es un gadget chain

Un gadget es un fragmento de código que ya existe en la aplicación y que se ejecuta como efecto secundario de la deserialización o de operaciones inmediatamente posteriores (comparar objetos, calcular un hash, representarlos como texto, recorrer una colección). Aislado, cada gadget hace algo modesto.

Una gadget chain es una secuencia de esos fragmentos colocados de forma que la salida de uno alimenta la entrada del siguiente, hasta llegar a una primitiva potente: cargar una clase remota, invocar un método por reflexión con parámetros controlados o lanzar un proceso. El atacante construye un grafo de objetos anidados tal que, al reconstruirlo, el runtime va disparando esos métodos en el orden deseado.

Por eso la comunidad mantiene catálogos de cadenas conocidas para librerías muy extendidas: el trabajo duro de encontrar los eslabones ya está hecho. Para el defensor, la consecuencia práctica es que actualizar la dependencia no siempre elimina el riesgo —pueden aparecer cadenas nuevas— y que la única defensa robusta es no deserializar datos no fiables con un formato que permita todo esto.

3. Dónde aparece: lenguajes y formatos

El patrón común salta a la vista: los formatos solo-datos (JSON, un CSV, Protocol Buffers, MessagePack sin extensiones peligrosas) son seguros frente a esta clase de ataque porque no llevan instrucciones sobre qué clases instanciar. Los formatos que preservan el tipo y el grafo completo de objetos son cómodos para comunicación interna entre componentes de confianza, y una mala idea en cualquier frontera donde entren datos de terceros.

4. Cómo se detecta

4.1 En el código

Igual que con otras clases de inyección, la detección fiable es leer el código y localizar dónde entra un flujo de bytes externo en un deserializador potente:

• Java: ObjectInputStream.readObject() sobre datos que provienen de HTTP, de una cola o de un fichero subido; uso de librerias de serializacion configuradas para aceptar tipos arbitrarios.
• .NET: BinaryFormatter, SoapFormatter, NetDataContractSerializer, LosFormatter o ObjectStateFormatter con entrada que no sea puramente interna; ViewState sin MAC.
• PHP: unserialize() sobre cookies, parametros o contenido de ficheros controlables; considerar json_decode como alternativa.
• Python: pickle.loads(), pickle.load(), pandas.read_pickle(), joblib.load() o torch.load() sobre ficheros o mensajes de origen no confiable; yaml.load() sin SafeLoader.
• Señal transversal: cualquier estado de cliente (sesion, carrito, preferencias, ‘volver a esta pagina’) que viaje en un blob en vez de en un identificador opaco contra almacenamiento del servidor.

4.2 En tránsito: magic bytes y blobs

Los objetos serializados tienen firmas reconocibles al principio del contenido, y a menudo viajan codificados en Base64 dentro de cookies o parámetros. Ver uno de estos marcadores en una petición es indicio de que hay deserialización del lado del servidor y conviene revisar cómo se valida:

Detectar la marca no dice si la implementación es vulnerable —puede haber una firma HMAC que impida manipular el blob— pero sí marca el punto exacto que hay que auditar.

5. Defensa en capas

El orden importa: las dos primeras filas resuelven el problema de verdad. La allowlist de clases y la firma del estado son contención sólida cuando no puedes cambiar el formato de golpe. El resto son redes de seguridad. Y una advertencia concreta: firmar el blob protege la integridad, no la confidencialidad ni el diseño; si además el contenido es sensible, cífralo, y si puedes evitar mandarlo, mejor.

6. Un caso ilustrativo en laboratorio

Monta un servicio propio en Python con un endpoint que guarde las preferencias del usuario en una cookie. En la versión vulnerable, serializa el diccionario de preferencias con pickle y lo devuelve en Base64; al recibir la cookie, hace pickle.loads sobre su contenido. Cualquiera que entienda el formato puede sustituir ese blob por otro y el proceso ejecutará lo que el nuevo objeto exprese durante la carga.

# ANTES (vulnerable): pickle sobre datos que vuelven del cliente
import pickle, base64
 
def guardar_prefs(prefs: dict) -> str:
    return base64.b64encode(pickle.dumps(prefs)).decode()
 
def cargar_prefs(cookie: str) -> dict:
    return pickle.loads(base64.b64decode(cookie))   # reconstruye lo que sea
 
# DESPUES (correcto): formato solo-datos y validacion explicita
import json
 
CLAVES_PERMITIDAS = {'tema', 'idioma', 'resultados_por_pagina'}
 
def guardar_prefs(prefs: dict) -> str:
    limpio = {k: prefs[k] for k in prefs.keys() & CLAVES_PERMITIDAS}
    return base64.b64encode(json.dumps(limpio).encode()).decode()
 
def cargar_prefs(cookie: str) -> dict:
    datos = json.loads(base64.b64decode(cookie))
    return {k: datos[k] for k in datos.keys() & CLAVES_PERMITIDAS}

Con la versión corregida, el peor caso es una cookie con claves o valores inesperados, que el filtrado descarta. No hay ningún camino por el que el contenido de la cookie se convierta en código. Si el estado tuviera que ir firmado para detectar manipulaciones, se añade un HMAC con una clave que solo conoce el servidor y se verifica antes de parsear.

# Opcion puente si el estado debe viajar y quieres detectar manipulacion
import hmac, hashlib
 
def firmar(payload: bytes, clave: bytes) -> bytes:
    mac = hmac.new(clave, payload, hashlib.sha256).digest()
    return base64.b64encode(mac + payload)
 
def verificar(blob: bytes, clave: bytes) -> bytes:
    crudo = base64.b64decode(blob)
    mac, payload = crudo[:32], crudo[32:]
    esperado = hmac.new(clave, payload, hashlib.sha256).digest()
    if not hmac.compare_digest(mac, esperado):
        raise ValueError('estado manipulado')
    return payload            # solo ahora se parsea, y con json, no con pickle

Conclusión

La deserialización insegura no es un exploit puntual: es una decisión de arquitectura. Aceptar bytes no fiables en un deserializador que sabe reconstruir objetos arbitrarios pone a disposición del atacante todos los métodos con efectos secundarios que hay en tus dependencias, sin necesidad de un solo fallo en tu código.

La corrección es tan estable como la causa: usa formatos solo-datos en toda frontera con datos externos, guarda el estado real en el servidor y deja que el cliente lleve solo un identificador. Donde no puedas migrar de inmediato, restringe las clases permitidas y firma el estado. Con eso, la clase entera de vulnerabilidad desaparece de tu aplicación en lugar de quedar pendiente del próximo gadget chain que alguien publique.

unfantasmaenelsistema.com | Seguridad, sistemas y todo lo que no debería funcionar (pero funciona)