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

Hace tres semanas, se descubrió un grave problema de seguridad en OS X 10.10.4. 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 los sistemas en riesgo fueran parcheados.

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 de inmediato 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..

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 asigna un número CVE. Estos identifican de manera única cada vulnerabilidad, y la vulnerabilidad se archiva en línea en el OSVDB.

Pero, ¿qué pasa si expira el tiempo de espera? 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 vendedores 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 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 Imagínese esto: usted despierta uno hermoso mañana, sírvase una taza de café y luego siéntese en su computadora para comenzar con su trabajo del día. Antes de que realmente consigas ... 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 la vulnerabilidad más grave que se haya encontrado en el sistema DNS. Esto habría permitido a alguien realizar fácilmente un ataque de envenenamiento de caché (o falsificación de DNS) en 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 desarrollados 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 eran 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 se filtró 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 de un exploit 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 se pueden detener? había sido creado.

La vulnerabilidad de DNS de Kaminsky finalmente resume el quid de la discusión a favor de una divulgación responsable y escalonada. Algunas vulnerabilidades, como las vulnerabilidades de día cero ¿Qué es una vulnerabilidad de día cero? [MakeUseOf explica] ¿Qué es una vulnerabilidad de día cero? [MakeUseOf Explains]: 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 se inclinan a no publicitar Por qué las compañías que guardan infracciones en secreto podrían ser algo bueno Por qué las empresas que mantienen infracciones 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? 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.

¿Qué quieren los vendedores??

A los vendedores realmente no les gusta la divulgación completa.

Después de todo, es una RP increíblemente mala 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, aquí está el por qué está loco Oracle quiere que dejes de enviarles errores, por eso está loco Oracle está en apuros por una publicación de blog equivocada del 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 recibida en la comunidad de seguridad ... - desaliente a las personas a 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.