Hace tres semanas, se descubrió un grave problema de seguridad en OS X 10.10.4. Eso, en sí mismo, no es particularmente interesante.
Las vulnerabilidades de seguridad en los paquetes de software populares se descubren todo el tiempo, y OS X no es una excepción. La Base de datos de vulnerabilidades de código abierto (OSVDB) muestra al menos 1100 vulnerabilidades etiquetadas como "OS X". Pero lo interesante es la forma en que se divulgó esta vulnerabilidad en particular.
En lugar de decirle a Apple y darles tiempo para remediar el problema, el investigador decidió publicar su hazaña en Internet para que todos lo vean.
El resultado final fue una carrera de armamentos entre Apple y hackers de sombrero negro. Apple tuvo que lanzar un parche antes de que la vulnerabilidad se convirtiera en un arma, y los piratas informáticos tuvieron que crear un exploit antes de que los sistemas en riesgo fueran reparados.
Puede pensar que ese método particular de divulgación es irresponsable. Incluso podría llamarlo poco ético o imprudente. Pero es más complicado que eso. Bienvenido al extraño y confuso mundo de la divulgación de vulnerabilidades.
Divulgación completa frente a responsable
Hay dos formas populares de divulgar vulnerabilidades a los proveedores de software.
El primero se llama divulgación completa . Al igual que en el ejemplo anterior, los investigadores inmediatamente publican su vulnerabilidad en la naturaleza, dando a los proveedores absolutamente ninguna oportunidad de lanzar una solución.
El segundo se llama divulgación responsable o divulgación escalonada. Aquí es donde el investigador contacta al proveedor antes de que se libere la vulnerabilidad.
Ambas partes acuerdan un marco de tiempo en el que el investigador promete no publicar la vulnerabilidad, con el fin de darle al proveedor la oportunidad de crear y liberar una solución. Este período de tiempo puede ser de entre 30 días y un año, dependiendo de la gravedad y la complejidad de la vulnerabilidad. Algunos agujeros de seguridad no se pueden arreglar fácilmente y requieren que los sistemas de software completos sean reconstruidos desde cero.
Una vez que ambas partes están satisfechas con la corrección que se ha producido, la vulnerabilidad se revela y se le asigna un número CVE. Estos identifican de forma única cada vulnerabilidad, y la vulnerabilidad se archiva en línea en el OSVDB.
Pero, ¿qué sucede si el tiempo de espera expira? Bueno, una de dos cosas. El vendedor negociará una extensión con el investigador. Pero si el investigador no está satisfecho con la forma en que el proveedor respondió o se comportó, o si considera que la solicitud de una extensión no es razonable, es posible que simplemente la publique en línea sin una solución preparada.
En el campo de la seguridad, hay debates acalorados sobre qué método de divulgación es mejor. Algunos piensan que el único método ético y preciso es la revelación completa. Algunos piensan que es mejor dar a los vendedores la oportunidad de solucionar un problema antes de lanzarlo a la naturaleza.
Como resultado, hay algunos argumentos convincentes para ambas partes.
Los argumentos a favor de la divulgación responsable
Veamos un ejemplo de dónde era mejor usar la divulgación responsable.
Cuando hablamos de infraestructura crítica en el contexto de Internet, es difícil evitar hablar sobre el protocolo DNS Cómo cambiar sus servidores DNS y mejorar la seguridad de Internet Cómo cambiar sus servidores DNS y mejorar la seguridad de Internet Imagine esto: se despierta una bella Por la mañana, sirva una taza de café y luego siéntese en su computadora para comenzar con su trabajo del día. Antes de que realmente consigas ... Leer más. Esto es lo que nos permite traducir direcciones web legibles por el ser humano (como makeuseof.com) en direcciones IP.
El sistema DNS es increíblemente complicado, y no solo a nivel técnico. Hay mucha confianza en este sistema. Confiamos en que cuando ingresamos una dirección web, nos envíen al lugar correcto. Simplemente hay mucho que depende de la integridad de este sistema.
Si alguien pudo interferir o comprometer una solicitud DNS, existe un gran potencial de daño. Por ejemplo, podrían enviar personas a páginas de banca en línea fraudulentas, lo que les permitiría obtener sus datos bancarios en línea. Podrían interceptar su correo electrónico y el tráfico en línea a través de un ataque de hombre en el medio, y leer los contenidos. Básicamente podrían minar la seguridad de Internet en su conjunto. Cosas de miedo.
Dan Kaminsky es un investigador de seguridad muy respetado, con un largo currículum para encontrar vulnerabilidades en software conocido. Pero es más conocido por el descubrimiento en 2008 de la vulnerabilidad más severa del sistema DNS jamás encontrada. Esto habría permitido a alguien realizar fácilmente un ataque de envenenamiento de caché (o suplantación DNS) en un servidor de nombres DNS. Los detalles más técnicos de esta vulnerabilidad se explicaron en la conferencia 2008 Def Con.
Kaminsky, muy consciente de las consecuencias de la publicación de un error tan grave, decidió revelarlo a los proveedores del software DNS afectados por este error.
Hubo una serie de importantes productos DNS afectados, incluidos los construidos por Alcatel-Lucent, BlueCoat Technologies, Apple y Cisco. El problema también afectó a una serie de implementaciones de DNS que se distribuyeron con algunas distribuciones populares de Linux / BSD, incluidas las de Debian, Arch, Gentoo y FreeBSD.
Kaminsky les dio 150 días para producir una solución, y trabajó con ellos en secreto para ayudarlos a comprender la vulnerabilidad. Sabía que este problema era tan grave y los daños potenciales tan grandes que hubiera sido increíblemente imprudente publicarlo públicamente sin dar a los proveedores la oportunidad de publicar un parche.
Incidentalmente, la vulnerabilidad fue filtrada accidentalmente por la firma de seguridad Matsano en una publicación de blog. El artículo fue retirado, pero fue reflejado, y un día después de la publicación de una hazaña Así es como te piratean: El mundo turbio de los kits de exploits Así es como te piratean: El mundo turbio de los kits de exploits Los estafadores pueden usar suites de software para explotar vulnerabilidades y crear malware Pero, ¿qué son estos kits de exploits? ¿De dónde vienen? ¿Y cómo pueden ser detenidos? Leer más había sido creado.
La vulnerabilidad de DNS de Kaminsky finalmente resume el quid del argumento a favor de una divulgación responsable y escalonada. Algunas vulnerabilidades, como vulnerabilidades de día cero ¿Qué es una vulnerabilidad de día cero? [MakeUseOf Explains] ¿Qué es una vulnerabilidad de día cero? [Explicaciones de MakeUseOf] Leer más: son tan importantes que liberarlos públicamente causaría un daño significativo.
Pero también hay un argumento convincente a favor de no dar una advertencia anticipada.
El caso para la divulgación completa
Al liberar una vulnerabilidad a la intemperie, desbloqueas una caja de pandora donde los individuos desagradables pueden producir exploits de manera rápida y fácil, y comprometer los sistemas vulnerables. Entonces, ¿por qué alguien elegiría hacer eso?
Hay un par de razones En primer lugar, los proveedores a menudo son bastante lentos para responder a las notificaciones de seguridad. Al forzar su mano al liberar una vulnerabilidad en la naturaleza, están más motivados para responder rápidamente. Peor aún, algunos se inclinan a no publicitar por qué las empresas que mantienen un secreto pueden ser buenas. Por qué las empresas que mantienen un secreto pueden ser buenas. Con tanta información en línea, todos nos preocupamos por posibles infracciones de seguridad. Pero estas violaciones podrían mantenerse en secreto en los EE. UU. Para protegerlo. Parece una locura, entonces, ¿qué está pasando? Lea más sobre el hecho de que estaban enviando software vulnerable. La divulgación completa los obliga a ser honestos con sus clientes.
Aparentemente @PepsiCo no se preocupa por un vuln en su sitio, no acepta ayuda no solicitada. Ya tiene un equipo de sec. Haré una divulgación completa
- Paquete blanco (@WhitePacket) 4 de septiembre de 2015
Pero también permite a los consumidores tomar una decisión informada sobre si desean continuar usando un software particular y vulnerable. Me imagino que la mayoría no lo haría.
¿Qué quieren los vendedores?
A los vendedores realmente no les gusta la revelación completa.
Después de todo, es un RP increíblemente malo para ellos, y pone en riesgo a sus clientes. Han tratado de incentivar a las personas a revelar vulnerabilidades de forma responsable a través de programas de bonificación de errores. Estos han sido notablemente exitosos, con Google pagando $ 1.3 millones de dólares solo en 2014.
A pesar de que vale la pena señalar que algunas empresas, como Oracle Oracle, quiere que deje de enviarlos. Aquí está el por qué ese loco. Oracle quiere que deje de enviarles errores. Aquí está el porqué de lo loco. Oracle está en la mira por una publicación errónea del jefe de seguridad., Mary Davidson. Esta demostración de cómo la filosofía de seguridad de Oracle se aleja de la corriente principal no fue bien recibida en la comunidad de seguridad ... Leer más - desalentar a las personas de realizar investigaciones de seguridad en su software.
Pero todavía habrá personas que insisten en usar la revelación completa, ya sea por razones filosóficas o por su propia diversión. Ningún programa de recompensas de errores, no importa cuán generoso, pueda contrarrestar eso.