Comunicarse con clientes de software vulnerable, ¿está mal?

3

Supongamos que usted es un investigador de seguridad que encuentra vulnerabilidades y las reporta a los proveedores para tratar de recibir una recompensa por errores. Si el proveedor no está dispuesto a pagar ninguna recompensa por cualquier vulnerabilidad, simplemente no revela el error y lo mantiene en privado. El problema permanece abierto.

Sin embargo, el vendedor sí vende su producto a posiblemente cientos de clientes que son vulnerables al error, que definitivamente no quieren seguir siendo vulnerables, ya que podrían sufrir importantes pérdidas financieras si alguien más lo encontrara y lo utilizara. para robar información, o peor.

¿Cuáles son los argumentos legales y éticos para llegar a los clientes del proveedor, informarles que el error existe, explicar sus posibles pérdidas (seis cifras) y utilizarlo como palanca para que el proveedor encuentre el error por su cuenta? (si pueden), o le pagan su recompensa por error deseado?

Mientras el error realmente exista y no asustes a los clientes por nada, y el proveedor es más que capaz de encontrar el error por sí solo si no está dispuesto a pagarte por su divulgación, ¿no es así? ser malo hacer? La opción alternativa de dejar el error solo y mantener a todos los clientes vulnerables, tampoco parece ser una opción muy ética, aunque a corto plazo crea menos problemas para el proveedor.

Cualquier consejo sería apreciado.

    
pregunta David Davidson 27.02.2017 - 22:21
fuente

2 respuestas

4

Hay mejores maneras.

Si su intención es informar a los clientes con fines puramente altruistas (y / o, presionar al proveedor para que los arregle, ya sea que reciba o no beneficios financieros), hay otras vías que puede explorar.

Puede, por ejemplo, comunicarse con su CERT local o con el CERT que cree que podría presionar al vendedor para que lo arregle (para EE. UU., consulte enlace ).

También puede solicitar un CVE ( enlace ) para hacer pública la vulnerabilidad, no solo conocida por los clientes existentes.

Probablemente hay un montón de otras opciones, pero esas son (con suerte) un punto de partida razonable.

Considera también que estos proporcionan algún tipo de revisión por pares, para asegurarte de que tienes lo que crees que tienes.

Si tiene la intención de ponerse en contacto con los clientes con fines de lucro, entonces la cuestión de cómo saber quiénes son se destacará, y lo más probable es que se lo considere una llamada en frío, que a través del correo electrónico (u otros medios) puede tiene consecuencias, por ejemplo, relacionadas con CAN-SPAM si usted está basado en los Estados Unidos.

No soy un abogado, pero esto parece un poco tembloroso.

Y es probable que el vendedor no se sienta bien con usted si lo descubre.

Si realmente no te importa la ética, hay mercados privados de vulnerabilidad que podrías considerar. Esto no conducirá a ninguna solución, pero la explotación del error y personalmente, no sentiría que este es el camino a seguir.

Básicamente: si el proveedor no le está pagando por una vulnerabilidad, entonces creo (y esto es simplemente una opinión) que un informe público hará que sea más probable que lo hagan en el futuro.

Más cerca de casa, también puede consultar ¿Cómo revelar una vulnerabilidad de seguridad de manera ética?

    
respondido por el iwaseatenbyagrue 27.02.2017 - 23:32
fuente
0
  

Mientras el error realmente exista y no asustes a los clientes por nada, y el proveedor no está dispuesto a pagarte por su divulgación, ¿sería incorrecto hacerlo?

Bueno, piénsalo, si lanzas exploits al público sin la cooperación del proveedor, básicamente eres un cracker, ¿no? Espere recibir una demanda y cada paso de cómo obtuvo el conocimiento del error que se colocará bajo un microscopio por violaciones de CFAA, DMCA y los términos del EULA que acompañan al software. Y ganas en todos esos puntos, felicidades, solo te quedan unos $ 150k de cuentas de defensa legal desde donde empezaste.

    
respondido por el DepressedDaniel 27.02.2017 - 22:35
fuente

Lea otras preguntas en las etiquetas