it-swarm-es.com

¿Cómo revelar una vulnerabilidad de seguridad de manera ética?

¿Cómo revelar una vulnerabilidad de seguridad de manera ética? He oído que hay varias escuelas de pensamiento sobre este tema. Me gustaría saber las ventajas y desventajas de cada uno.

75
Olivier Lalonde

Debe informar a los desarrolladores de forma privada para que tengan la oportunidad de solucionarlo. Después de eso, si hace pública la vulnerabilidad, debe permitirle al desarrollador el tiempo suficiente para solucionar el problema y a quien esté expuesto a él el tiempo suficiente para actualizar sus sistemas. Personalmente, permitiría al desarrollador hacer el anuncio en un boletín de seguridad en la mayoría de los casos en lugar de anunciarlo yo mismo. Como mínimo, esperaría la confirmación de que la vulnerabilidad se ha solucionado. Si tiene tiempo y tiene acceso al código fuente, también puede proporcionar un parche.

43
VirtuosiMedia

Personalmente, creo que divulgación responsable parece ser la mejor manera de ir desde un punto de vista ético y funcionó bien para Dan Kaminsky al revelar los detalles de la vulnerabilidad de envenenamiento de caché de DNS. Pero todo depende en gran medida de la empresa o grupo con el que esté tratando y también de la base de usuarios a la que afectará.

27
Mark Davidson

@VirtuosiMedia hace un gran trabajo al describir "Divulgación responsable".

Yo agregaría dos puntos:

  • Trabaje con el proveedor (si puede), para asegurarse de que lo entienda completamente y no emita un parche a medias.
  • Si el vendedor te ignora o te ignora, sigue intentándolo. Sin embargo, si afirman que no es una vulnerabilidad, continúe y publique. Tan fuerte como sea posible. Si prometieron arreglarlo, pero no lo hacen, intente obtener una respuesta de ellos, junto con una línea de tiempo definitiva con la que se comprometan. En algún momento, si siguen posponiéndose, es posible que desee decirles que va a publicar de todos modos, y luego darles algo de tiempo para solucionarlo (pero breve y limitado).
18
AviD

Este es un gran tema complejo. Estuve involucrado en la divulgación del error de renegociación de TLS hace un par de años, y créanme, tratamos mucho de ser "responsables", pero al final, logramos molestar a todos a nuestro alrededor y (quizás) retrasarlo. El lanzamiento real de la solución. No quiere decir que la notificación del proveedor sea necesariamente mala, solo que es realmente fácil ser aturdido y terminar causando tanto daño como bueno o peor.

En nuestro caso, se tomó una acción del IETF ( RFC 5746 ) para resolver el problema, y ​​aunque teníamos un borrador de Internet listo el día que se filtró, el trabajo real de debatir y decidir sobre la solución tardó unos tres meses más, y realmente no comenzó en serio hasta que se realizó la divulgación.

De todos modos, esta no es una respuesta a su pregunta, pero es una de las historias de divulgación más interesantes que conozco. Más sobre esa historia en el nota clave de la ShmooCon 201 Lo hice con Marsh Ray, quien descubrió el problema.

11
Steve Dispensa

En general, depende de la respuesta del vendedor. Una buena práctica es cuando el investigador de seguridad informa al proveedor sobre la vulnerabilidad, luego, durante la conversación, habla sobre los términos de publicación de poc/exploit de esta vulnerabilidad. En realidad, el investigador elige qué hacer con esta vulnerabilidad: publicar más tarde o no. Luego, el proveedor lanza un parche o una nueva versión del producto. Tal vez. Pero, como muestra la experiencia, no todos los vendedores son tan agradables. Algunos de ellos corrigen errores en silencio, sin informar a los usuarios finales e investigadores, otros prefieren ignorar al investigador. Otros incluso intentan demandar. Es por eso que a veces el anonimato es una forma preferible de comunicación inicial con un proveedor desconocido.

También me gustaría admitir que hay programas de recompensas de recompensas de errores, que son ofrecidos por Google, Mozilla. Además, otros compran vulnerabilidades - ZDI , iDefense , SNOsoft , próximo "exploit hub", y etc. Por lo tanto, hay al menos tres formas de informar al proveedor: directamente, publicando información de vulnerabilidad en alguna lista o a través de compañías de terceros.

8
anonymous

Si tienen un rastreador de problemas públicos, vea si puede presentar un error con una etiqueta "privada" o "de seguridad".

Independientemente de si tienen un rastreador de problemas, envíe un correo electrónico [email protected] nombre de la empresa y hágales saber.

Si no responden con bastante rapidez (consulte "Ventana de divulgación" en el artículo de Schneier a continuación), entonces debe pensar en divulgarlo más ampliamente. Busque listas de correo en las que los académicos/profesionales de seguridad estén al acecho y pregúnteles cómo informan los problemas al proveedor en cuestión. Es posible que puedan hacer presentaciones en el lugar correcto de la organización.

Si todo eso falla, lea el bit de Schneier y piense si la divulgación completa sería parte del problema o parte de la solución.

Bruce Schneier da un argumento a favor de divulgación completa en ciertas circunstancias basado en el estándar "ser parte de la solución, no parte del problema". Definitivamente vale la pena leerlo.

Este es el clásico debate "secreto de errores versus divulgación completa". He escrito sobre esto anteriormente en Crypto-Gram; otros también han escrito sobre eso. Es un tema complicado con implicaciones sutiles en toda la seguridad informática, y vale la pena volver a discutirlo.

...

Este flujo de información libre, tanto de código de descripción como de prueba de concepto, también es vital para la investigación de seguridad. La investigación y el desarrollo en seguridad informática han florecido en la última década, y gran parte de eso se puede atribuir al movimiento de divulgación completa. La capacidad de publicar los resultados de la investigación, tanto buenos como malos, conduce a una mejor seguridad para todos. Sin publicación, la comunidad de seguridad no puede aprender de los errores de los demás. Todos deben operar con anteojeras, cometiendo los mismos errores una y otra vez. La divulgación completa es esencial para continuar mejorando la seguridad de nuestras computadoras y redes.

...

En segundo lugar, creo en avisar al vendedor con anticipación. CERT llevó esto al extremo, a veces dando al vendedor años para solucionar el problema.

...

Me gusta la métrica "ser parte de la solución, no parte del problema". Investigar la seguridad es parte de la solución. Convencer a los proveedores para que solucionen los problemas es parte de la solución. Sembrar miedo es parte del problema. Entregar herramientas de ataque a adolescentes despistados es parte del problema.

6
Mike Samuel