Divulgación completa o responsable: cómo se divulgan las vulnerabilidades de seguridad

Anuncio

Hace tres semanas, un grave problema de seguridad en OS X 10.10.4 fue descubierto. Eso, en sí mismo, no es particularmente interesante.

Se descubren vulnerabilidades de seguridad en paquetes de software populares 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 que es interesante es la forma en que se reveló esta vulnerabilidad particular.

En lugar de decirle a Apple y darles tiempo para remediar el problema, el investigador decidió publicar su exploit en Internet para que todos lo vean.

El resultado final fue una carrera armamentista entre Apple y los hackers de sombrero negro. Apple tuvo que lanzar un parche antes de que la vulnerabilidad fuera armada, y los piratas informáticos tuvieron que crear un exploit antes de que se repararan los sistemas en riesgo.

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 vs responsable

Hay dos formas populares de revelar 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 la naturaleza, dando a los vendedores absolutamente ninguna oportunidad de lanzar una solución.

El segundo se llama divulgación responsableo divulgación escalonada. Aquí es donde el investigador contacta al proveedor antes de que se libere la vulnerabilidad.

Luego, ambas partes acuerdan un marco de tiempo en el que el investigador promete no publicar la vulnerabilidad, a fin de darle al vendedor la oportunidad de crear y publicar una solución. Este período de tiempo puede ser de 30 días a un año, dependiendo de la gravedad y complejidad de la vulnerabilidad. Algunos agujeros de seguridad no pueden repararse fácilmente y requieren que se reconstruyan sistemas de software completos desde cero.

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

Pero, ¿qué pasa 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 ha respondido o se ha comportado, o si considera que la solicitud de una extensión no es razonable, simplemente puede publicarla en línea sin ninguna solución preparada.

En el campo de la seguridad, hay acalorados debates sobre qué método de divulgación es el mejor. Algunos piensan que el único método ético y preciso es la divulgación completa. Algunos piensan que es mejor darles a los proveedores la oportunidad de solucionar un problema antes de lanzarlo a la naturaleza.

Resulta que 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 dentro del contexto de Internet, es difícil evitar hablar de el protocolo DNS Cómo cambiar sus servidores DNS y mejorar la seguridad de InternetImagínese esto: se despierta una hermosa mañana, se sirve una taza de café y luego se sienta en su computadora para comenzar con su trabajo del día. Antes de que realmente consigas ... Lee mas . Esto es lo que nos permite traducir direcciones web legibles por humanos (como makeuseof.com) en direcciones IP.

El sistema DNS es increíblemente complicado, y no solo a nivel técnico. Hay mucha confianza depositada en este sistema. Confiamos en que cuando escribimos una dirección web, se nos envía al lugar correcto. Simplemente se depende mucho de la integridad de este sistema.

Si alguien pudo interferir o comprometer una solicitud de DNS, existe un gran potencial de daños. Por ejemplo, podrían enviar personas a páginas bancarias 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 el contenido. Podrían socavar fundamentalmente la seguridad de Internet en su conjunto. Cosas de miedo.

Dan Kaminsky es un investigador de seguridad muy respetado, con una larga trayectoria de búsqueda de vulnerabilidades en software conocido. Pero es más conocido por el descubrimiento en 2008 de quizás el vulnerabilidad más severa en el sistema DNS encontrado alguna vez. Esto habría permitido a alguien realizar fácilmente un envenenamiento de caché (o suplantación de DNS) ataque a un servidor de nombres DNS. Los detalles más técnicos de esta vulnerabilidad se explicaron en la conferencia Def Con de 2008.

Kaminsky, muy consciente de las consecuencias de liberar un defecto tan grave, decidió revelarlo a los proveedores del software DNS que se ven afectados por este error.

Hubo una serie de productos DNS importantes afectados, incluidos los creados por Alcatel-Lucent, BlueCoat Technologies, Apple y Cisco. El problema también afectó a varias 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 habría sido increíblemente imprudente lanzarlo públicamente sin dar a los vendedores la oportunidad de emitir un parche.

Por cierto, la vulnerabilidad fue filtrado por accidente 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. una hazaña Así es como te piratean: el mundo turbio de los kits de exploitLos estafadores pueden usar paquetes de software para explotar vulnerabilidades y crear malware. Pero, ¿qué son estos kits de exploits? ¿De dónde vienen? ¿Y cómo se pueden detener? Lee mas Había sido creado.

La vulnerabilidad de DNS de Kaminsky en última instancia resume el quid de la discusión 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 explica] Lee mas - 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 previa.

El caso para la divulgación completa

Al liberar una vulnerabilidad a la intemperie, desbloqueas una caja de Pandora donde las personas desagradables pueden producir vulnerabilidades 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 suelen ser bastante lentos para responder a las notificaciones de seguridad. Al forzar efectivamente su mano al liberar una vulnerabilidad en la naturaleza, están más motivados para responder rápidamente. Peor aún, algunos están inclinados no publicitar ¿Por qué las compañías que guardan las brechas en secreto podrían ser algo bueno?Con tanta información en línea, todos nos preocupamos por posibles violaciones de seguridad. Pero estas infracciones podrían mantenerse en secreto en los EE. UU. Para protegerlo. Suena loco, entonces, ¿qué está pasando? Lee mas el hecho de que estaban enviando software vulnerable. La divulgación completa los obliga a ser honestos con sus clientes.

Pero también permite a los consumidores tomar una decisión informada sobre si desean continuar utilizando 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 divulgació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 manera responsable a través de programas de recompensas de errores. Estos han sido notablemente exitosos, con Google pagando $ 1.3 millones de dólares solo en 2014.

Aunque vale la pena señalar que algunas empresas: como Oracle Oracle quiere que dejes de enviarles errores: he aquí por qué es una locuraOracle está en apuros por una publicación de blog equivocada de la jefa 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 recibida en la comunidad de seguridad ... Lee mas - Disuadir a las personas de realizar investigaciones de seguridad en su software.

Pero todavía habrá personas que insistan en usar la divulgación completa, ya sea por razones filosóficas o para su propia diversión. Ningún programa de recompensas de errores, por generoso que sea, puede contrarrestar eso.