Explorando Vulnerabilidades de Subida de Archivos sin Romper la Ley
Como saltar validaciones de upload en tu propio lab, mapear clases de fallos y endurecer webservers contra RCE via archivo malicioso.
Un endpoint de subida mal configurado sigue siendo una de las formas mas baratas de convertir un formulario en RCE. En un lab con DVWA, OWASP Juice Shop y un Nginx 1.25 como reverso, pasamos de 'subir avatar' a shell como www-data en menos de 40 minutos. Antes de mostrar payloads, recordemos el contrato: el objetivo es nuestra propia VM, aislada en una red 10.10.0.0/24 sin ruta a internet, y el fin ultimo es escribir reglas de hardening, no coleccionar trofeos. Si aun no tienes ese entorno listo, sigue Pentest Web desde Cero: Montando un Lab Seguro con DVWA, Juice Shop y Burp Suite antes de continuar.
La primera clase de fallo que aparece es la validacion por extension del lado del cliente. En PHP legado es comun ver una lista negra (.php, .phtml, .php5) y cero verificacion del Content-Type real. Renombrar shell.php a shell.pHp.jpg, interceptar con Burp y devolver Content-Type image/jpeg tumba el 80% de los filtros amateur que veo en CTFs corporativos. En una prueba reciente contra un modulo de curriculum, bastaron 12 bytes de GIF89a; en un .gif renombrado a .phtml para ejecucion. Lo que fallo no fue 'el regex', fue la arquitectura: el Apache tenia AddHandler para cualquier cosa terminada en .phtml en cualquier carpeta.
La segunda capa interesante es el parsing doble del Nginx antiguo (CVE-2013-4547 y variantes modernas). Un archivo llamado shell.jpg\x00.php aun engana stacks que combinan Nginx + PHP-FPM con pathinfo mal configurado. En el lab reproduje el escenario con nginx:1.14-alpine y php:7.2-fpm solo como referencia historica; con Nginx 1.25 y cgi.fix_pathinfo=0 el mismo payload muere. Este tipo de ejercicio conecta bien con SQL Injection en la Practica: Explotar, Detectar y Mitigar en Lab Controlado: no sirve cazar una vulnerabilidad puntual si no entiendes toda la cadena de procesamiento, del balanceador al interprete.
Cuando el backend valida magic bytes, el juego cambia. Los polyglots GIF/PHP funcionan contra getimagesize(), pero caen ante finfo + Imagick con reprocesamiento. El truco es atacar el pipeline de transformacion: ImageMagick con policies laxas aun procesa MVG y SVG, y la familia ImageTragick sigue apareciendo en forks de plataformas LMS. En un cliente fintech encontre un upload de comprobante que llamaba convert sin -limit memory y con policy.xml vacio; un SVG de 12KB con xlink:href a file:///etc/passwd filtro contenido en el PDF generado. Para el lado web puro de SSRF derivado de esto, SSRF sin Complicaciones: Explotando Cloud Metadata en Lab AWS Local cubre el caso AWS casi identico.
Otra superficie subestimada es donde acaba el archivo. Storage en /var/www/uploads servido por Apache es el clasico, pero veo el mismo problema en buckets S3 con Content-Disposition equivocado y en CDNs que reprocesan HTML. Path traversal en el nombre (../../tmp/cron.d/pwn) aun funciona contra middlewares Node que confian en originalname de Multer. Para un checklist mas formal de prueba, sobre todo en APIs JSON con base64 embebido, cruza con Pentest de APIs REST y GraphQL: Checklist Tecnico para Bug Bounty Legal y valida limites de tamano, mimetype declarado vs detectado, y cuotas por usuario autenticado.
Del lado defensivo, las reglas que cobro escribir en informes son aburridas y funcionan: nombre aleatorio (UUIDv7), almacenar fuera del document root, servir via handler que fuerza Content-Disposition: attachment y Content-Type: application/octet-stream, validar mimetype con libmagic en el servidor, y bloquear extensiones dobles en el propio Nginx con location ~* \.(php|phtml|phar)\. { deny all; }. En contenedores monto el volumen de upload como noexec,nosuid y ejecuto clamav como sidecar. La auditoria continua entra en AppSec Shift-Left: SAST, SCA y Escaneo de Secretos sin Frenar al Equipo, donde Semgrep detecta regex de validacion debil antes del deploy.
Un detalle etico que repito en formacion: replicar estas tecnicas contra un SaaS en produccion 'solo para probar' no es bug bounty, es delito en la mayoria de jurisdicciones LATAM. Los programas legitimos publican alcance explicito, y aun dentro de ellos, exfiltrar /etc/passwd es innecesario cuando el id de la VM ya prueba el fallo. La diferencia entre investigador y acusado suele ser el snapshot de la VM y el documento de autorizacion. Takeaway practico: en tu proximo sprint, toma un endpoint de upload de tu producto, escribe un test de integracion que intente subir shell.phtml, .htaccess, polyglot GIF/PHP y SVG con xlink, y rompe el pipeline si alguno es aceptado. Vale mas que cien horas de lectura.