Un chico de 15 años gana $50,000 al encontrar un bug de puerta trasera en Zendesk

• Un chico de 15 años que disfruta cazar bugs en su tiempo libre encontró un bug relacionado con la verificación de correo electrónico en Zendesk, usado por empresas de la lista Fortune 500
• Lo reportó a varias empresas y ganó más de $50,000, pero se presenta cómo Zendesk parchó el problema sin darle ninguna recompensa al reportero

Introducción a Zendesk

• Zendesk es una herramienta de atención al cliente usada por algunas de las mejores empresas del mundo
• Si conectas un correo de soporte a Zendesk, Zendesk administra los correos entrantes y crea tickets
• Sorprende que muchas grandes empresas dependan de Zendesk en vez de construir su propio sistema de tickets

El eslabón más débil

• Como dice la frase, “una cadena es tan fuerte como su eslabón más débil”, Zendesk suele verse como una simple herramienta de tickets y se usa sin una configuración cuidadosa
• Si se usa el dominio “@company.com” para single sign-on (SSO) y se conecta con Zendesk, puede surgir una vulnerabilidad de seguridad
• Como Zendesk procesa correos del dominio, si el sistema SSO no valida correctamente la dirección de correo, alguien con acceso a Zendesk podría abusar de sistemas internos.

Suplantación de correo electrónico

• Se descubrió una vulnerabilidad grave en Zendesk con la que un atacante podía leer tickets de soporte al cliente de empresas que usan Zendesk
• Zendesk no tenía protecciones efectivas contra la suplantación de correo electrónico
• Si un atacante conocía la dirección de soporte y el ID del ticket, podía acceder al ticket haciéndose pasar por el remitente original mediante spoofing de correo
• El autor reportó el bug, pero al principio Zendesk no mostró interés
  • Respondieron que la suplantación de correo (problemas de SPF, DKIM, DMARC) estaba fuera de alcance
• El reporte se procesó a través de HackerOne, y cuando pidió reportarlo directamente a un integrante del equipo de Zendesk, se lo rechazaron

Escalando este problema hasta tomar control de Slack

• Podía haber reportado el bug de suplantación de correo a empresas individuales, pero quería generar un impacto mayor
• Antes, otro investigador había logrado infiltrarse en el Slack de cientos de empresas a través de Zendesk (TICKETTRICK)
• El autor intentó reproducirlo usando su propio bug, pero hubo algunas dificultades
• Slack cambió su método para verificar agregando un token aleatorio a la dirección de correo
• Pero al iniciar sesión con Apple ID mediante OAuth, no se usaba ese token, así que era posible saltarse esa protección

Pasos de reproducción: Apple → Zendesk → Slack

1. Crear un Apple ID con “[e-mail]” y solicitar un código de verificación, lo que genera un ticket en Zendesk
2. Crear un ticket con su propio correo en el portal de soporte de company.com para rastrear el rango de IDs
3. Usar el bug de spoofing de correo para intentar agregarse a todos los tickets de ese rango de IDs
4. Iniciar sesión en el portal de soporte de esa empresa con la cuenta [e-mail] y revisar los tickets donde quedó en CC
5. Ingresar el código de verificación en el Apple ID
6. Iniciar sesión en Slack usando la función “Iniciar sesión con Apple” con el Apple ID vinculado al correo @company.com, y entrar a Slack
   El autor aplicó estos 6 pasos a cientos de instancias de Zendesk y Slack

Consecuencias del incidente

• Durante una semana reportó la vulnerabilidad a empresas individuales; algunas actuaron de inmediato, pero otras insistieron en que era un problema de Zendesk
• Cuando algunas empresas contactaron a Zendesk, Zendesk finalmente pidió mantener el reporte privado y solicitó pasos de reproducción para la vulnerabilidad de Slack
• Después de que entregó un PoC de toma de control de Slack, Zendesk confirmó el problema, pero tardó 2 meses en resolverlo
• Muchas empresas protegieron sus instancias desactivando la función de colaboración por correo
• A través de este reporte de bug bounty, el autor recibió más de $50,000 en recompensas de empresas individuales en HackerOne y otras plataformas
• Algunas empresas cancelaron sus contratos con Zendesk

La corrección de Zendesk y mi recompensa de 0 dólares

• Dos meses después, Zendesk confirmó que había solucionado el problema
• Usaban los filtros antispam Cloudmark y Rspamd EAP, pero como no aprovechaban la puntuación de Rspamd, muchos correos no quedaban en espera
• Al principio lo corrigieron cambiando automáticamente a Rspamd bajo ciertas condiciones
• Después implementaron un filtro que pone automáticamente en espera los correos de verificación de Apple y Google
• A pesar de haber solucionado el problema, Zendesk decidió no pagar recompensa por este reporte de bug bounty
  • Argumentaron que el autor violó las pautas de divulgación de HackerOne al compartir la vulnerabilidad con las empresas afectadas

Conclusión

• Un pequeño bug de correo terminó abriendo la puerta a la intrusión en sistemas internos de algunas de las empresas más grandes del mundo
• Zendesk finalmente solucionó la vulnerabilidad, pero el proceso fue duro por los rechazos, la lentitud en la respuesta y la indiferencia
• Esa es la realidad de la caza de bugs: a veces se gana y a veces se pierde

Opinión de GN⁺

• El caso de Zendesk muestra el riesgo de adoptar soluciones de terceros sin una revisión crítica. Incluso productos de empresas muy conocidas requieren evaluación de seguridad.
• Tomar control de sistemas internos de grandes empresas puede causar daños enormes, así que la respuesta tardía de Zendesk fue muy irresponsable. Negarse a pagar recompensas también desincentiva a los investigadores de seguridad.
• Las empresas deben elegir con cuidado sus dominios de SSO y reforzar sus procesos de verificación de correo. Hace falta aprovechar activamente tecnologías de autenticación de correo como DMARC, SPF y DKIM.
• Las pautas de divulgación de HackerOne son demasiado rígidas desde la perspectiva del investigador. En vulnerabilidades graves debería compartirse la información con rapidez, por lo que parece necesaria una aplicación más flexible según el contexto.
• La caza de bugs debería ser un ganar-ganar tanto para las empresas como para los investigadores. Ojalá se consolide una cultura que respete la buena fe y el esfuerzo de los investigadores, y los recompense de forma adecuada.

[aer0700]

Viendo este tipo de incidentes, parece mucho mejor no solo traer e implementar soluciones de seguridad, sino contratar y formar expertos en seguridad. 😢

[GN⁺]

Opiniones de Hacker News

• Un usuario mencionó que reportó el mismo bug a Zendesk, Apple y Slack en junio de 2024, y que probablemente no le dieron recompensa porque no fue la primera persona en reportarlo

  • La opción de SSO no basada en directorio, Sign in with Apple (SIWA), estaba mal implementada, y eso también ocurría en grandes empresas como Slack
  • El SSO no basado en directorio no puede tener el mismo nivel de confianza que el SSO basado en directorio, y los proveedores de SSO no son intercambiables entre sí aunque usen la misma dirección de correo electrónico

• Otro usuario afirmó que Zendesk creó una banda falsa llamada "Zendesk Alternative" para contaminar los resultados de búsqueda de Google

  • Mencionó que esto no es ilegal, pero sí una conducta manipuladora que muestra su forma de pensar

• Un usuario dijo que es decepcionante que Zendesk se negara a pagar por el bug, y comentó que esa es una forma de hacer que la gente no quiera participar en programas de recompensas grandes

  • Agregó que su experiencia de entrevista con Zendesk fue muy mala

• Otro usuario comentó que los programas de bug bounty ineficientes tienen un impacto negativo en los servicios de software

  • Sostuvo que Zendesk debería pagar, disculparse y corregir el programa

• Un usuario criticó que Zendesk no pagara a pesar de ser una empresa con ingresos de 1.3 mil millones de dólares, diciendo que eso es una visión de corto plazo

  • Mencionó que no es una decisión racional y que el capital privado está recortando costos y desgastando la marca

• Otro usuario explicó que probablemente Zendesk lo ignoró porque no entendió correctamente el impacto del bug

  • Comentó que, sin un impacto claro, muchas vulnerabilidades pueden parecer simplemente bugs

• Un usuario señaló que Zendesk solo corrigió el problema del correo de verificación de la cuenta de Apple, pero no resolvió el problema de fondo

  • Mencionó que, con la configuración predeterminada, cualquiera que conozca el correo electrónico y el ID del ticket podría potencialmente secuestrar un ticket de soporte

• Explicó que existían dos vulnerabilidades separadas

  • Zendesk permitía enviar respuestas desde la dirección de correo del solicitante original y agregar CC
  • Slack permitía el inicio de sesión para todo el dominio mediante Sign in with Apple sin verificación adicional

• Criticó que Zendesk ignorara el problema e intentara mantenerlo en privado

  • Mencionó que eso es una actitud poco profesional y que podría ser la razón por la que no pagaron la recompensa

• Por último, un usuario criticó que Zendesk se negara a pagar por el bug y enfatizó que quien lo reportó siguió correctamente todos los procedimientos