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

Debes informar a los desarrolladores en privado para que tengan la oportunidad de solucionarlo. Después de eso, si se hace público con la vulnerabilidad, debe permitirle al desarrollador el tiempo suficiente para solucionar el problema y 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 se ha solucionado la vulnerabilidad. Si tiene tiempo y tiene acceso al código fuente, también podría proporcionar un parche.

Personalmente creo que La divulgación responsable parece ser la mejor manera de pasar de un punto ético y funcionó bien para Dan Kaminsky revelando los detalles de la vulnerabilidad de envenenamiento de caché de DNS. Pero todo depende en gran medida de la compañía o grupo con el que esté tratando y también de la base de usuarios a la que afectará.

@VirtuosiMedia hace un gran trabajo al describir "Responsible Disclosure".

Yo añadiría dos puntos:

• Trabaje con el proveedor (si puede) para asegurarse de que lo entienden completamente y no emiten un parche a medias.
• Si el proveedor te ignora o te ignora, sigue intentándolo. Sin embargo, si afirman que no es una vulnerabilidad, siga adelante y publique. Tan fuerte como sea posible. Si prometieron arreglarlo, pero no lo hagan, intente obtener una respuesta de ellos, junto con una línea de tiempo definitiva con la que se comprometan. En algún momento, si continúan posponiendo, eventualmente querrá decirles que publicará de todos modos, y luego darles algo de tiempo para que lo arreglen (pero corto y limitado).

Este es un 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 muy duro de ser "responsables", pero al final, tuvimos éxito principalmente en molestar a todos los que nos rodeaban y (quizás) retrasar 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 silbado y terminar causando tanto daño como bueno o peor.

En nuestro caso, tomó una acción del IETF ( RFC 5746 ) para resolver el problema, y A pesar de que teníamos un borrador de Internet listo el día en que se filtró, el trabajo real de debatir y decidir sobre la solución tomó 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 tu pregunta, pero es una de las historias de divulgación más interesantes que conozco. Más información sobre esa historia en la nota clave de ShmooCon 2010 que hice con Marsh Ray, quien descubrió el problema.

En general, depende de la respuesta del proveedor. Una buena práctica es cuando el investigador de seguridad informa al proveedor sobre la vulnerabilidad y 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 vendedor lanza un parche o una nueva versión del producto. Tal vez. Pero, como muestra la experiencia, no todos los vendedores son tan buenos. Algunos de ellos corrigen errores en silencio, sin informar a los usuarios finales e investigadores, algunos 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 recompensa de recompensas de errores, que son ofrecidos por Google, Mozilla. Además, otros compran vulnerabilidades: ZDI , iDefense , SNOsoft , que viene "centro de explotación", y etc. Por lo tanto, hay al menos tres formas de informar al proveedor: directamente, publicando información sobre vulnerabilidades en alguna lista o a través de empresas de terceros.

Si tienen un rastreador de problemas público, 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 a security@ companyname 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 las listas de correo en las que se encuentran los académicos / profesionales de seguridad y pregúnteles cómo informan sobre los problemas al proveedor en cuestión. Es posible que puedan hacer presentaciones en el lugar correcto en la organización.

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

Bruce Schneier da un argumento para divulgación completa en ciertas circunstancias basadas en un "ser parte de la Solución, no parte del problema "estándar. Definitivamente vale la pena leerlo.

  

Este es el debate clásico sobre "secreto de errores frente a divulgación completa". Lo he escrito previamente en Crypto-Gram; otros han escrito sobre eso también. Es un problema complicado con implicaciones sutiles en toda la seguridad de la computadora, y vale la pena discutirlo nuevamente.

     

...

     

Este flujo de información libre, tanto de descripción como de código 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 puede atribuirse 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 las anteojeras puestas, cometiendo los mismos errores una y otra vez. La divulgación completa es esencial si queremos continuar mejorando la seguridad de nuestras computadoras y redes.

     

...

     

Segundo, creo en avisar al vendedor con anticipación. CERT llevó esto a un extremo, a veces le dio años al proveedor 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 vendedores de solucionar problemas es parte de la solución. Sembrar el miedo es parte del problema. La entrega de herramientas de ataque a adolescentes despistados es parte del problema.