Zimbra: inyección de comandos en la notificación SNMP de zimbra-snmp

Dossier retrospectivo de la inyección de comandos en el camino de notificación SNMP de Zimbra, preservado como línea base del laboratorio. El dossier registra qué llegó a hacer el agente, qué se tuvo adaptar en el laboratorio para llegar al sink y qué quedó explícitamente no establecido.

Qué se publicó y por qué este caso es un dossier

Zimbra corrigió en 10.1.20 una inyección de comandos en el camino de notificación SNMP: NVD la abrió como CVE-2026-73570 con CWE-78 y CVSS 3.1 8.9 (Alto), publicada el 13 de agosto de 2026, y el commit del fabricante estudiado es c4837c66 en zm-build. Las condiciones públicas son ZCS anterior a 10.1.20 con el paquete opcional zimbra-snmp instalado y las notificaciones SNMP activadas. CISA KEV la lista desde el 2026-08-21 con vencimiento 2026-08-24, y CERT Polska reportó explotación activa.

Este es el dossier retrospectivo del laboratorio: la reconstrucción preservada como línea base, con laboratorio, evidencia y registro completo en el repo, pero sin pieza en vídeo publicada. La investigación inicial duró poco más de dos días y se produjo con agentes operando sobre Qwen3.8-27B-FP8 y DeepSeek-V4-Flash-0731, con supervisión humana de alcance y publicación.

La cadena, paso a paso

El camino es de notificación, no de autenticación: un mensaje entrante puede llevar un campo de destinatario hasta el monitor de logs que dispara la alerta SNMP. El sink es la ruta legado doSNMP(), que construye un comando interpretado por shell a partir de datos interpolados usando backticks de Perl. Cualquier cosa que llegue a esa interpolación se ejecuta con los permisos del servicio.

El arreglo del fabricante cambia eso por una invocación de system() con argumentos separados, que ya no pasa por el intérprete de shell. En la comparación del caso, la rama parcheada no ejecutó el canario idéntico mientras la rama sin parche lo ejecutaba con un control positivo vivo el mismo día.

El detalle honesto y central: para que el campo de destinatario crafted llegara hasta el sink, el laboratorio añadió una condición de watch controlada en swatchdog. Eso está declarado en el caso como parte del montaje, y es la razón por la que el propio README escribe que no está establecido que el campo documentado alcance el sink en una instalación sin modificar.

Qué hizo el agente y qué midió

Primero canario: la validación de ejecución se hizo con un canario reversible antes de cualquier demostración de impacto, y la demostración acotada pasó por un gate humano explícito. La ejecución quedó como el usuario de servicio zimbra, con restauración después de la prueba y en una red de runtime aislada con dominio ficticio.

La evidencia publicada son capturas de proceso, transcripts de disparo de reglas, registros de verificación del arreglo, fotogramas, las grabaciones del run y un manifiesto SHA-256 del caso. Nada de esto tocó un sistema de terceros: el README lo declara explícitamente.

Dónde se detuvo el agente

El caso lleva una tabla de "no establecido" en lugar de una narración de éxitos. Lo más importante: no está probado que la ruta de disparo exacta exista en una instalación sin modificar, porque el laboratorio añadió una condición de watch para llegar al sink. Tampoco está establecida la prevalencia de esa ruta en producción, ni el laboratorio observó por su cuenta la explotación en el mundo real (eso se atribuye a CERT Polska y a CISA), ni se reclama cobertura universal de detección ni tuning listo para producción.

Y hay un hueco de registro que prefiero decir en vez de rellenar: a diferencia de los casos 002, 003 y 004, este dossier no publica un attempt log con los intentos rechazados. El repo documenta los límites, pero no la secuencia de intentos fallidos, así que en esta página ese detalle no existe y no se inventa.

Detección y remediación

Remediación: subir a ZCS 10.1.20. Si el producto no se puede parchear de inmediato, lo que corta la cadena son las precondiciones públicas: quitar el paquete opcional zimbra-snmp o desactivar las notificaciones SNMP, porque sin el monitor de notificación no hay sink al que llegar.

Las detecciones publicadas son cinco reglas Sigma (cuatro con status reviewed y una experimental), Suricata y YARA. Cubren el intento por el campo de destinatario de Postfix, la inyección en swatch/dosnmp, el shell inverso por /dev/tcp desde el usuario de servicio, la persistencia genérica por hijo sospechoso bajo el servicio y el banner de login tocado como indicador de defacement. Las YARA buscan el remanente en cola de correo, el artefacto de notificación y el banner del PoC.

Todas las reglas dispararon contra los artefactos de la ejecución de laboratorio, no contra tráfico real, así que el propio caso manda ajustarlas contra la telemetría y las líneas base de cada entorno antes de ponerlas a paginar.

Resultado

• El sink legado doSNMP() construye un comando interpretado por shell usando backticks de Perl; verificado en fuente y en ejecución, y contrastado con el commit del fabricante c4837c66 en zm-build.
• La cadena adaptada del laboratorio ejecutó un canario y una demostración de impacto acotado como el usuario zimbra, con restauración tras la prueba.
• La implementación parcheada, que pasa a system() con múltiples argumentos, no ejecutó el canario idéntico mientras la rama sin parche sí lo hacía con un control positivo vivo.
• Sigma, YARA y Suricata casaron contra los artefactos grabados de la ejecución de laboratorio, con sus transcripts publicados.
• CISA KEV lista CVE-2026-73570 con dateAdded 2026-08-21 y dueDate 2026-08-24; el arreglo estudiado es ZCS 10.1.20, y CERT Polska reportó explotación activa.