🔓 Cómo Hackers Usaron una Herramienta de Documentos (Pandoc) para Robar Credenciales Cloud
Pandoc. De herramienta de documentos a arma cibernética
Hackers intentaron utilizar Pandoc, una herramienta para conversión de archivos,para robar credenciales en AWS.
📖 La Historia: El Ataque que Pudo Ser
Investigadores de la empresa de seguridad Wiz descubrieron un intento de explotación en la vida real de una vulnerabilidad de Server-Side Request Forgery (SSRF). Esta vulnerabilidad se presentó en la herramienta de código abierto Pandoc. Pandoc se usa para convertir archivos entre formatos de markup (como HTML a PDF). El objetivo de los atacantes era utilizar esta herramienta legítima como un caballo de Troya para robar credenciales temporales de servicios cloud de AWS.
La vulnerabilidad, catalogada como CVE-2025-51591, permite a un atacante inyectar un elemento <iframe> especialmente manipulado en un documento HTML. Cuando Pandoc convertía este documento, el iframe intentaba cargar una dirección interna sensible del servicio de metadatos de AWS (IMDS), específicamente los endpoints que contienen las credenciales de seguridad. De haber tenido éxito, los hackers habrían obtenido acceso a los permisos asociados al servidor vulnerable.
⚙️ ¿Cómo Funcionó el Ataque?
- Punto de Entrada. Los atacantes enviaron un documento HTML malicioso a un servicio web que utilizaba Pandoc para conversión de documentos.
- Explotación de la Vulnerabilidad. El documento HTML contenía un
<iframe>cuyo atributosrcapuntaba directamente a la dirección IP del servicio de metadatos de AWS (169.254.169.254) y a las rutas críticas/latest/meta-data/iam/infoy/latest/meta-data/iam/. - El Objetivo. Al convertir el documento, Pandoc, siguiendo su funcionamiento normal pero sin las debidas restricciones de seguridad, intentaba renderizar el iframe. Para esto, hacía una petición HTTP al servicio de metadatos desde dentro del propio servidor vulnerable. El contenido de esa respuesta (las credenciales) podría haber sido exfiltrado por el atacante
🛡️ ¿Por Qué el Ataque Falló? La Lección Más Importante
El ataque fue neutralizado exitosamente gracias a una sola medida de seguridad: la implementación de IMDSv2 (versión 2 del servicio de metadatos).
- IMDSv1 vs. IMDSv2. La versión original (IMDSv1) funciona con simples peticiones HTTP GET, lo que la hace extremadamente vulnerable a ataques SSRF. La versión 2 (IMDSv2) está orientada a la sesión y requiere que cualquier petición vaya precedida de una solicitud PUT para obtener un token de acceso. Ese token debe incluirse en un encabezado especial (
X-aws-ec2-metadata-token) en todas las peticiones siguientes. - La Mitigación. El iframe HTML explotado en el ataque solo puede realizar peticiones GET simples y no puede ejecutar el paso previo de PUT necesario para obtener el token. Por lo tanto, todas las solicitudes fueron rechazadas automáticamente por el servicio IMDSv2. Este caso es un testimonio perfecto de la eficacia de esta medida de seguridad.
✅ Recomendaciones de Seguridad para Evitar este Peligro
Basado en este incidente, estas son las acciones clave para proteger tus entornos cloud:
| Recomendación | Descripción | Impacto |
|---|---|---|
| Implementar IMDSv2 | Configurar todas las instancias EC2 para usar exclusivamente la versión 2 del servicio de metadatos. | Alto. Mitiga directamente ataques SSRF simples como este. |
| Principio de Mínimo Privilegio | Asignar a las instancias solo los permisos IAM absolutamente necesarios para su función. | Alto. Limita el daño en caso de que las credenciales sean robadas. |
| Configurar Pandoc de Forma Segura | Al usar Pandoc con contenido no confiable, usar los flags -f html+raw_html o --sandbox para deshabilitar la renderización de iframes. | Crítico. Corrige la vulnerabilidad específica en la aplicación. |
| Monitoreo de Accesos Anómalos | Implementar sistemas que alerten cuando aplicaciones que normalmente no acceden a IMDS (como Pandoc) lo hagan. | Medio. Permite la detección temprana de intentos de explotación. |
🤔 Conclusión: Una Carrera Entre la Comodidad y la Vigilancia
El intento de ataque contra Pandoc nos deja una reflexión profunda sobre el estado actual de la ciberseguridad. No se trató de una explotación sofisticada de día cero. Se trató de la manipulación astuta de una herramienta legítima y ampliamente confiable. Este incidente es un microcosmos de un desafío mayor. En nuestra búsqueda por la eficiencia y la funcionalidad, integramos constantemente software de código abierto y servicios en la nube para agilizar procesos. No obstante, a menudo lo hacemos sin una evaluación paralela de los nuevos riesgos que introducimos.
La verdadera lección va más allá de parchear un CVE.
Es un recordatorio de que la seguridad no es un producto que se instala, sino un proceso continuo de adaptación. Los atacantes ya no solo buscan vulnerabilidades en el código. Ellos buscan «grietas» en la configuración, en la arquitectura de la nube y en la confianza que depositamos en herramientas aparentemente inofensivas.
La victoria en este caso no fue de un antivirus milagroso, sino de una decisión proactiva y simple: la migración a IMDSv2. Esto nos enseña que, a menudo, las defensas más robustas no son las más llamativas, sino aquellas que siguen mejores prácticas fundamentales. Hay una pregunta crucial que toda organización debe hacerse. ¿Cuántas de nuestras «medidas simples» están pendientes, dejándonos vulnerables al próximo ataque que, como este, utilizará nuestra propia infraestructura en nuestra contra?
La ciberseguridad es una carrera entre nuestra capacidad de innovar de forma segura y la inventiva de quienes buscan explotar los vacíos que dejamos atrás. Este caso demuestra que, por esta vez, la vigilancia y la aplicación de fundamentos sólidos ganaron la carrera.
Cuéntanos, ¿utilizas pandoc?
Te invitamos a que nos visites periódicamente para leer las notas que compartimos. Esperamos que te sean de utilidad.
