Completa o responsable de la divulgación: ¿cómo se dan a conocer las vulnerabilidades de seguridad

Hace tres semanas, fue descubierto un problema de seguridad grave 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 vulnerabilidad de base de datos Open Source (OSVDB) muestra al menos 1100 vulnerabilidades en la categoría “OS X”. Pero que es interesante es la forma en que se dio a conocer esta vulnerabilidad 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 puedan ver.

El resultado final fue una carrera de armamentos entre Apple y los hackers de sombrero negro. Apple tuvo que lanzar un parche antes de la vulnerabilidad en armas, y los piratas informáticos tenido que crear un exploit antes de que los sistemas en situación de riesgo consiguen parcheado.

Se podría pensar que el método particular de la divulgación es irresponsable. Incluso se puede llamar poco ético, o imprudente. Pero es más complicado que eso. Bienvenidos al extraño, confuso mundo de la divulgación de vulnerabilidades.

Vs completa revelación responsable

Hay dos formas populares de la divulgación de vulnerabilidades a los proveedores de software.

El primero se llama la divulgación completa. Al igual que en el ejemplo anterior, los investigadores publican inmediatamente su vulnerabilidad en el medio natural, dando a los vendedores absolutamente ninguna oportunidad de liberar una dosis.

El segundo se llama revelación responsable, o escalonada de la divulgación. Aquí es donde los contactos investigador el vendedor antes de la vulnerabilidad se libera.

Ambas partes se ponen de acuerdo sobre un marco de tiempo en que el investigador se compromete a no publicar la vulnerabilidad, con el fin de dar al vendedor la oportunidad de construir y lanzar una solución. Este período de tiempo puede ser desde 30 días a 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 sistemas de software completas que ser reconstruido desde cero.

Una vez que ambas partes están satisfechas con la solución que se ha producido, entonces se da a conocer la vulnerabilidad y dado un número CVE. Estos identifican de manera única cada vulnerabilidad, y la vulnerabilidad se archiva en línea en el OSVDB.

Pero, ¿qué ocurre si se agota el tiempo de espera? Bueno, una de dos cosas. El proveedor será luego negociar una extensión con el investigador. Pero si el investigador no está contento con la forma en que el vendedor haya respondido o se ha comportado, o sentir la solicitud de prórroga no es razonable, que simplemente lo publique en línea con ninguna solución preparada.

En el campo de la seguridad, hay intensos debates en cuanto a qué método de divulgación es lo mejor. Algunos piensan que el único método ético y precisa es la revelación completa. Algunos piensan que lo mejor es dar a los vendedores una oportunidad para solucionar un problema antes de liberarlo en el medio natural.

Como resultado, hay algunos argumentos convincentes para ambos lados.

Los argumentos a favor de la divulgación Responsable

Veamos un ejemplo de que era mejor utilizar una fuente responsable.

Cuando hablamos de la infraestructura crítica en el contexto de Internet, es difícil evitar hablar de el protocolo DNS. Esto es lo que nos permite traducir las direcciones web legible por humanos (como makeuseof.com) en direcciones IP.Cómo cambiar los servidores DNS & Mejorar la seguridad en InternetCómo cambiar los servidores DNS & Mejorar la seguridad en InternetImagínese esto - te despiertas una mañana hermosa, verter una taza de café, y luego sentarse a su ordenador para empezar con su trabajo para el día. Antes de que en realidad obtener ...Lee mas

El sistema DNS es increíblemente complicado, y no sólo a nivel técnico. Hay una gran cantidad de confianza depositada en este sistema. Confiamos en que cuando escribe una dirección web, somos enviados al lugar correcto. Simplemente hay mucho en juego en la integridad de este sistema.

Si alguien era capaz de interferir con, o comprometer una petición DNS, hay un gran potencial para el daño. Por ejemplo, podrían enviar a la gente a páginas fraudulentas de banca en línea, lo que les permite obtener sus datos bancarios en línea. Se podría 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 el contenido. Ellos podrían socavar fundamentalmente la seguridad de Internet en su conjunto. Cosas de miedo.

Dan Kaminsky es un investigador de seguridad muy respetada, con una larga hoja de vida de encontrar vulnerabilidades en el software bien conocido. Pero está más conocido por el descubrimiento de 2008 de quizás la vulnerabilidad más grave en el sistema DNS que se ha encontrado. Esto habría permitido a alguien para realizar fácilmente un ataque de envenenamiento de caché (o la suplantación de DNS) en un servidor de nombres DNS. Los detalles más técnicos de esta vulnerabilidad se explicó en la conferencia Def Con 2008.

Kaminsky, muy conscientes de las consecuencias de la liberación de un defecto tan grave, decidió revelarla a los vendedores de software DNS que se ven afectados por este error.

Hubo una serie de importantes productos de DNS afectados, incluyendo los construidos por Alcatel-Lucent, BlueCoat Technologies, Apple y Cisco. El problema también afectó a un número de implementaciones de DNS que se entregan con algunas distribuciones populares de Linux / BSD, incluidos los de Debian, Arch, Gentoo y FreeBSD.

Kaminsky les dio 150 días para producir una solución, y trabajó con ellos en secreto para ayudarles a entender la vulnerabilidad. El sabía que este problema era tan grave, y los daños potenciales tan grande, que hubiera sido muy imprudente dar a conocer públicamente que sin dar a los vendedores la oportunidad de emitir un parche.

Por cierto, la vulnerabilidad se filtró por accidente por la firma de seguridad Matsano en un blog. El artículo fue tomado abajo, pero se vio reflejada, y un día después de la publicación un exploit se había creado.Así es como ellos Hack: el turbio mundo de paquetes de exploitsAsí es como ellos Hack: el turbio mundo de paquetes de exploitsLos estafadores pueden utilizar paquetes de software para aprovechar las vulnerabilidades y crear malware. Pero ¿cuáles son éstos explotan los kits? ¿De dónde vienen? Y cómo pueden ser detenidos?Lee mas

la vulnerabilidad DNS de Kaminsky en última instancia, resume el meollo del argumento a favor de, divulgación escalonada responsable. Algunas vulnerabilidades - como vulnerabilidades de día cero - son tan significativos, que, a publicar ellos podría causar daños significativos.

Pero también hay un argumento de peso a favor de no dar aviso previo.

El Caso de la divulgación completa

Por la liberación de una vulnerabilidad a la luz, que se desbloquee la caja de Pandora, donde las personas indeseables son capaces de producir rápidamente y fácilmente hazañas, y comprometer los sistemas vulnerables. Así que, ¿por qué alguien elegiría para hacer eso?

Hay un par de razones. En primer lugar, los vendedores son a menudo bastante lento en responder a los avisos de seguridad. Al obligar eficazmente su mano por la liberación de una vulnerabilidad en el medio natural, son más motivados para responder con rapidez. Peor aún, algunos son inclinados a no dar a conocer el hecho de que estaban enviando software vulnerable. La revelación completa les obliga a ser honesto con sus clientes.Por qué las empresas mantener un secreto infracciones Podría ser una buena cosaPor qué las empresas mantener un secreto infracciones Podría ser una buena cosaCon tanta información en línea, todos nos preocupamos por posibles violaciones de seguridad. Pero estas infracciones podrían ser mantenidos en secreto en los EE.UU. con el fin de protegerlo. Parece una locura, así que lo que está pasando?Lee mas

Pero también permite a los consumidores a tomar una decisión informada sobre si desean seguir utilizando una pieza en particular, vulnerable del software. Me imagino que la mayoría no lo haría.

¿Qué quieren los vendedores?

Los vendedores no le gustan revelación completa.

Después de todo, es increíblemente malas relaciones públicas para ellos, y que pone en riesgo a sus clientes. Han tratado de incentivar a la gente a revelar vulnerabilidades de manera responsable a través de programas de recompensas de errores. Estos han tenido un éxito notable, con Google el pago de $ 1.3 millones de dólares en 2014 solo.

Aunque vale la pena señalar que algunas empresas - como Oracle - disuadir a la gente de la realización de la investigación de seguridad en su software.Oracle quiere que deje de mandarlos Insectos - He aquí el porqué eso es una locuraOracle quiere que deje de mandarlos Insectos - He aquí el porqué eso es una locuraOracle es en agua caliente a través de una entrada en el blog equivocada por el jefe de seguridad, Mary Davidson. Esta demostración de cómo la filosofía de seguridad de Oracle se aparta de la corriente principal no fue bien recibido en la comunidad de seguridad ...Lee mas

Pero todavía va a haber gente que insiste en el uso de la divulgación completa, ya sea por razones filosóficas, o para su propia diversión. Ningún programa de recompensas de errores, no importa cuán generosa, puede contrarrestar eso.