Divulgación completa o responsable de 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 vulnerabilidad 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 en particular..

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

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

Podría pensar que un método particular de divulgación es irresponsable. Incluso podrías 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, lo que no les da a los proveedores la oportunidad de lanzar una solución..

El segundo se llama divulgación responsable, o divulgación escalonada. Aquí es donde el investigador se pone en contacto con el proveedor antes de que se publique la vulnerabilidad..

Luego, ambas partes acuerdan un período de tiempo en el que el investigador se compromete a no publicar la vulnerabilidad, con el fin de brindar al proveedor la oportunidad de crear y lanzar una solución. Este período de tiempo puede ser de 30 días a un año, dependiendo de la gravedad y la complejidad de la vulnerabilidad. Algunos agujeros de seguridad no se pueden reparar 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 forma única cada vulnerabilidad, y la vulnerabilidad se archiva en línea en el OSVDB.

¿Pero qué pasa si el tiempo de espera expira? Bueno, una de dos cosas. El proveedor negociará una extensión con el investigador. Pero si el investigador no está contento con la respuesta o el comportamiento del proveedor, o si considera que la solicitud de una extensión no es razonable, simplemente la publicará en línea sin una solución lista..

En el campo de la seguridad, hay debates acalorados sobre cuál es el mejor método de divulgación. 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..

Como resultado, hay algunos argumentos convincentes para ambos lados.

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 del 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: usted se levanta de una manera hermosa Por la mañana, sírvase una taza de café y luego siéntese frente a su computadora para comenzar su trabajo del día. Antes de que realmente obtenga ... Leer más. Esto es lo que nos permite traducir direcciones web legibles para las personas (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, nos envían al lugar correcto. Simplemente hay mucho sobre la integridad de este sistema.

Si alguien pudo interferir o comprometer una solicitud de DNS, existe un gran potencial de daño. Por ejemplo, podrían enviar a personas a páginas bancarias en línea fraudulentas, lo que les permite obtener sus datos bancarios en línea. Podían interceptar su correo electrónico y tráfico en línea a través de un ataque de hombre en el medio y leer el contenido. Fundamentalmente, podrían socavar la seguridad de Internet en su conjunto. Cosas de miedo.

Dan Kaminsky es un investigador de seguridad muy respetado, con un largo resumen de la 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 en el sistema DNS que se haya encontrado. Esto hubiera 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 una falla tan grave, decidió divulgarla a los proveedores del software de DNS que están afectados por este error..

Hubo una serie de importantes productos de DNS 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 ayudarles 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 lanzarlo públicamente sin dar a los proveedores la oportunidad de emitir un parche.

Por cierto, la vulnerabilidad fue filtrada por accidente por la empresa 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, un exploit Así es como te hackean: el mundo turbio de los kits de exploits Así es como te hackean: el mundo turbio de los kits de explotadores Los estafadores pueden usar paquetes de software para explotar vulnerabilidades y crear malware. ¿Pero cuáles son estos kits de explotación? ¿De dónde vienen? ¿Y cómo pueden ser detenidos? Leer más había sido creado.

La vulnerabilidad del DNS de Kaminsky en última instancia resume el quid del argumento a favor de la divulgación responsable y escalonada. Algunas vulnerabilidades, como vulnerabilidades de día cero ¿Qué es una vulnerabilidad de día cero? [MakeUseOf explica] ¿Qué es una vulnerabilidad de día cero? [MakeUseOf Explica] Leer más - son tan importantes que lanzarlos 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 al público, se desbloquea una caja de pandora en la que los individuos desagradables pueden producir explotaciones rápida y fácilmente, 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 lanzar una vulnerabilidad a la naturaleza, están más motivados para responder rápidamente. Lo que es peor, algunos se inclinan a no dar a conocer por qué las empresas mantener los incumplimientos en secreto podrían ser algo bueno. Por qué las empresas mantener los incumplimientos 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 protegerte. Suena loco, entonces, ¿qué está pasando? Lea más el hecho de que estaban enviando software vulnerable. La divulgación completa los obliga a ser honestos con sus clientes..

Al parecer, @PepsiCo no se preocupa por una vulnerabilidad en su sitio, no acepta ayuda no solicitada. Ya tiene un equipo de seg. Voy a hacer la divulgación completa

- Paquete blanco (@WhitePacket) 4 de septiembre de 2015

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

¿Qué quieren los vendedores??

Los vendedores realmente no les gusta la divulgación completa.

Después de todo, las relaciones públicas son increíblemente malas para ellos y pone en riesgo a sus clientes. Han intentado incentivar a las personas para que revelen vulnerabilidades de manera responsable a través de los 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 enviarlos por error, así es como está loco Oracle quiere que dejes de enviarlos por error: aquí es por qué está loco Oracle está en el agua por una publicación errónea en el blog del jefe de seguridad , Mary Davidson. Esta demostración de cómo la filosofía de seguridad de Oracle se separa de la corriente principal no se recibió bien en la comunidad de seguridad ... Leer más: desaliente a las personas a realizar investigaciones de seguridad en su software.

Pero todavía habrá gente que insista en usar la divulgació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, puede contrarrestar eso.

Explorar más sobre: ​​Seguridad informática, Hacking.