¿$ 50,000 por una vulnerabilidad son demasiado?



Las grandes recompensas de errores llaman la atención, pero no alivian las fallas de seguridad de la aplicación que están tratando de resolver.

Zoom recientemente aumentó su pago máximo por vulnerabilidades a $ 50,000 como parte de su programa de seguridad crowdsourced. Una figura tan elevada llega a grandes titulares, atrae nuevos talentos en busca de mucho dinero y plantea la pregunta: ¿cuánto vale una vulnerabilidad?

Encontré varios errores en los productos de Zoom hace varios años, cuando su programa de seguridad de colaboración colectiva period una empresa incipiente. Tres de ellos fueron encontrados por otros antes que yo, lo que llamamos un «duplicado» en seguridad de colaboración colectiva, lo que significa que no recibe ninguna recompensa por su tiempo o esfuerzo a pesar de que es un error válido.

La cuarta vulnerabilidad fue bastante interesante y reapareció al comienzo de la pandemia cuando Zoom estaba bajo un mayor uso (y un mayor escrutinio). Etiqueté la vulnerabilidad como «URI potencialmente inseguros pueden causar la inclusión de archivos locales, la inyección de comandos o la conexión remota». que es exactamente lo que hizo. Para resumir, puede enviar identificadores uniformes de recursos que aparecerían como enlaces a alguien con quien estaba chateando, y estos podrían hacer varias cosas como abrir sitios net maliciosos, descargar archivos o incluso ejecutar comandos en el sistema del usuario. (Curiosamente, incluso funcionó con el protocolo gopher: //.) La vulnerabilidad que reapareció a principios de 2020 fue idéntica y se centró en las rutas de la Convención de nomenclatura universal (UNC) para que pudiera enviar credenciales de NT LAN Manager (NTLM) a un dominio del atacante.

Por informar de esta vulnerabilidad, (eventualmente) me pagaron la suma «principesca» de $ 50, y me tomó alrededor de seis meses para que la vulnerabilidad se abriera camino hacia los poderes fácticos. Dos años después, recibí un mensaje que decía que se había solucionado y que podía dedicar mi tiempo libre a comprobar la solución. (No lo hice). Hoy en día, los pagos mucho más generosos son comunes en la seguridad de colaboración colectiva, y distraen del problema true: ¿Deberíamos pagar 50.000 dólares por una vulnerabilidad?

Cómo las recompensas generosas dañan a las personas y los productos
Este tipo de sumas no son nuevas, por supuesto. Los días cero de Zoom en el punto álgido de la pandemia supuestamente fueron se vende por $ 500,000 para la aplicación de Windows, y empresas como Zerodium trafican con frecuencia en este tipo de vulnerabilidades en el área del «mercado gris» de transacciones de vulnerabilidades.

Volviendo a la pregunta que nos ocupa, hay muchas desventajas en los pagos cada vez mayores en los programas de seguridad de colaboración colectiva. Si bien el objetivo principal es aumentar el interés en el programa (recuerde, los programas de crowdsourcing se basan en una economía de conciertos orwelliana, donde trabaja free of charge a menos que encuentre un error válido), también tienen el efecto contraproducente de canibalizar el talento fuera de las áreas de seguridad legítimas. , asalariados o no.

El costo de pagar para reparar las vulnerabilidades cuando están activas también está en juego. Esos 50.000 dólares se podrían gastar fácilmente en corregir las causas fundamentales de las vulnerabilidades y «cambiar a la izquierda» para pagar mucho más que una sola solución. Algunos ejemplos obvios de cómo se podría usar ese dinero:

  • Un ingeniero de seguridad de aplicaciones a tiempo completo
  • De 10 a 20 pruebas de penetración o revisiones de código (según tarifa diaria)
  • Un conjunto completo de program de prueba de lápiz automatizado
  • Despliegue e implementación completos del software program de pruebas de seguridad de aplicaciones estáticas (SAST) (escaneo de código / dependencias) en más de 10 millones de líneas de código
  • Capacitar a cientos de desarrolladores en técnicas de codificación segura

Cualquiera de los anteriores detectaría problemas planteados en programas de colaboración colectiva mucho antes de que llegaran a un entorno en vivo, y a un costo mucho más económico. Si bien el argumento es que la recompensa por mistake compensa el impacto monetario de un eventual exploit de vulnerabilidad, el contrario es que si adoptara un enfoque de cambio a la izquierda, la compensación se multiplicaría por un issue de 10. Si su SAST o Los ingenieros de seguridad de aplicaciones o incluso sus revisiones de código detectan 10 de estas vulnerabilidades antes de lanzarse, también ha mitigado el costo adicional de refactorizar el código y presionar una sola compilación para corregir una sola vulnerabilidad.

Persiga la causa, no el síntoma
La seguridad de colaboración colectiva se adapta a un problema que siempre persigue el síntoma, no la causa, y ofrecer recompensas cada vez mayores no aliviará los problemas estructurales que están tratando de resolver: una buena higiene de seguridad de las aplicaciones. Si bien podría decirse lo mismo de la sopa de letras de acrónimos en el espacio de la tecnología de ciberseguridad (piense en IAM, WAF, DAST, SIEM, and many others.), muchas tecnologías son simplemente vendajes sobre lo que resolvería una tubería de seguridad de aplicaciones integral.

Pagar recompensas de cinco cifras por vulnerabilidades individuales no significará de repente que tenga una mejor seguridad. Al decidir cuánto pagar por una vulnerabilidad, si la pregunta es «¿es demasiado para una vulnerabilidad?» entonces debería preguntarse «¿Me estoy moviendo lo suficiente a la izquierda?»

Alex Haynes es un ex pentester con experiencia en seguridad ofensiva y se le atribuye el descubrimiento de vulnerabilidades en productos de Microsoft, Adobe, Pinterest, Amazon Web Providers e IBM. Él es un ex investigador clasificado entre los 10 primeros en Bugcrowd y miembro de Synack … Ver biografía completa

Lectura recomendada:

Más información





Enlace a la noticia unique