Responsible full disclosure... por ambas partes

Wednesday, November 13, 2013



La revelación responsable de vulnerabilidades es un viejo debate, pero no necesariamente zanjado. Vamos a observarlo desde el punto de vista del sistema vulnerable o afectado, no desde el investigador (que es al que normalmente se le exigen las responsabilidades). Si se practica la revelación responsable, este adjetivo debe aplicarse tanto al que lo detecta, como al afectado.

La anécdota

En ElevenPaths, alertamos hace algunas semanas sobre un pequeño fallo en la web de Cisco, en concreto de su servicio Meraki de redes a través de la nube. En una ruta concreta se divulgaba información quizás sensible.


Entre otros, se observa el nombre de usuario ssh, el servidor SVN, rutas a la red interna, y otros nombres de usuarios SVN. Quizás no se encuentren actualizados los datos y su impacto sea mínimo, pero es una información que definitivamente no debería estar ahí.

Cisco determina en su programa, bajo estas condiciones, las normas para alertar sobre fallos de seguridad:
 
We take these reports seriously and will respond swiftly to fix verifiable security issues. [...] Any Cisco Meraki web service that handles reasonably sensitive user data is intended to be in scope. This includes virtually all the content under *.meraki.com. [...] It is difficult to provide a definitive list of bugs that will qualify for a reward: any bug that substantially affects the confidentiality or integrity of user data is likely to be in scope for the program.
 
La revelación de información se les notificó a principios de noviembre. Dos días después la respuesta de Meraki fue peor de lo esperado:

I have looked into your report and, unfortunately, this was first reported to us on 9/23/13, with a resolution still pending from our engineers.

Esto implica que se alegaba que un tercero lo había descubierto previamente y lo que es peor, que el problema les era conocido desde hacía al menos cinco semanas y aún no lo habían (y no lo han) resuelto. Simplemente se trata eliminar una página de un servidor o protegerla con contraseña.


Otros problemas y vulnerabilidades descubiertos por nuestro equipo, bastante más complejos, han sido resueltos en mucho menos tiempo. Los problemas que se pueden zanjar eliminando una página, prácticamente suelen solucionarse en el mismo día que se detectan.

Salvando absolutamente todas las distancias, otros usuarios que han participado en los "bounty programs" de Facebook, PayPal (especialmente torpe con su programa) o Google, se quejan de que han recibido, en "demasiadas" ocasiones, la respuesta de que ya alguien les había alertado previamente. Incluso afirma que al pedirle a PayPal pruebas de que alguien se les había adelantado, nunca contestaron. Es incluso más común oír que los fabricantes tardan demasiado en corregir cualquier error cuando se alerta de ellos de forma privada.

Antecedentes

Al margen de la anécdota introductoria, la "divulgación responsable" es un viejo debate, y existen muchos ejemplos con los que periódicamente se ha reabierto. En resumen: al divulgar una vulnerabilidad, en cierta manera, se ataca directamente al crimen en la red donde más le duele,  devaluando un valor muy apreciado. También, hacer público cualquier error hace que su prevención y detección sea mucho más generalizada y por tanto, previene futuros ataques. Incluso, podría llegar a "detener" ataques que hipotéticamente se estuviesen realizando aprovechando un fallo antes de que el investigador lo hiciese público.

En la parte negativa, cuando se hace público, otros atacantes lo incorporan a su arsenal y pueden aprovechar esa vulnerabilidad para lanzar nuevos ataques.  Aunque a su vez, ataques de difusión masiva siempre van acompañados de defensas mucho más variadas y asequibles. Por último también es cierto que el hecho de hacer públicos los fallos acelera el proceso de corrección en el fabricante.

El "full disclosure" en realidad, no elimina el impacto de una vulnerabilidad sino que lo transforma: desde un hipotético uso exclusivo del fallo en el mercado negro, inadvertido y muy peligroso, con objetivos muy concretos y valiosos donde pocos ataques dan un alto beneficio; hasta ataques indiscriminados aunque cazados en mayor medida por los sistemas de detección.

Otras responsabilidades

Ahora que están de moda los programas de recompensa, son muchas las compañías que han intentado motivar la revelación responsable premiando económicamente a los que descubren vulnerabilidades y problemas de seguridad. Pero es necesario recordar que desde la posición del afectado, también se crean nuevas responsabilidades. Es muy habitual que se hable de que, por ejemplo, el descubrimiento se atribuirá al primero que escribe al equipo de seguridad. Pero, ¿cómo se demuestra esto? ¿Cómo podría acreditar alguien que ha enviado un correo describiendo un fallo o vulnerabilidad antes que nadie? Los fabricantes podrían obligar a utilizar PGP firmado con timestamp o incluso servicios gratuitos como eGarante para alertar y garantizar los avisos, pero no parece que ninguno recomiende explícitamente su uso. Las empresas que ofrecen recompensas, sugieren en el mejor de los casos el cifrado en las comunicaciones, pero por confidencialidad, más que por la demostración de autoría.

También debemos atender a la responsabilidad de arreglar en un tiempo razonable una vulnerabilidad o fallo. ¿Cuánto tiempo es aceptable? En agosto de 2010 Zero Day Initiative de TippingPoint, harto de vulnerabildiades que se eternizaban, impuso una nueva regla destinada a presionar a los fabricantes de software para que solucionen lo antes posible sus errores: si pasados seis meses desde que se les avise de un fallo de seguridad de forma privada, no lo han corregido, lo harían público. Para fallos web triviales, como el caso de la anécdota, deberían darse menos tiempo, incluso. Lo que añade un nuevo problema: ¿existe alguna forma "justa" o responsable de evaluar la gravedad de un problema y por tanto, su valor económico a la hora de recompensarlo? En el caso de las compañías que hacen de intermediarias, el precio suele estar más o menos fijado, pero en los bounty programs "privados" de cada empresa, este puede ser un valor muy subjetivo.

Los programas de recompensa pretenden premiar a los investigadores, motivarlos para que las vulnerabilidades salgan del circuito del mercado negro, y además obtener una "auditoría" avanzada a un precio que consideren justo. También pretenden ofrecer una imagen de compañía responsable y que premia el trabajo de los profesionales de la seguridad... pero deben estar preparados para responder diligentemente y actuar de forma tan profesional y responsable como exigen a los investgadores, para mantener esa imagen que se pretende proyectar. Si no, que se lo digan a Yahoo!, que a mediados de año, fue ridiculizada tras ofrecer 12.50 dólares (canjeables en productos de la propia Yahoo!) a una compañía que descubrió serios problemas de seguridad en su red.

Sergio de los Santos
ssantos@11paths.com

2 comments:

  1. Hola Sergio,
    De todo el artículo, me gustaría preguntar haciendo foco en la parte de responsabilidades, aunque sea más moral y ético que técnico...
    Cuándo detectas un fallo de cross-scripting, por ejemplo, en una web de una pyme...sin hablar incluso de una pyme potente, y vas un paso más, y llegas a comprobar que puedes hacer "cosillas"....una vez que has cruzado este "jodido" umbral ¿Cómo se debe de notificar? No saben lo que es un programa de recompensa, seguramente ni se imaginen que la página que le ha diseñado y desarrollado un tercero puede tener fallos que vulneren su integridad y su negocio.
    ¿Puedes tener algún problema al notificar dichos bugs si has cruzado ese umbral?
    Como quizás este no sea el foro adecuado, no me extenderé más.
    Muchas gracias de antemano.

    ReplyDelete
  2. Hola Sergio, el tema de la "revelación responsable" de vulnerabilidades es algo a lo que llevo dando vueltas desde hace mucho tiempo. Me considero un buen experto en seguridad informática, aunque humildemente, creo, aún no llego a "senior". Sin embargo sí he llegado a descubrir fallos importantes en sistemas de determinadas empresas, tan importantes como por ejemplo llegar a exportar los datos de más de 1.000.000 de clientes de determinado servicio.

    Descubrir una vulnerabilidad en ocasiones significa invertir días e incluso meses de tu tiempo en llegar a lograrlo. Además del tiempo en descubrir esa vulnerabilidad, hay que sumar el tiempo y dinero que hemos tomado en aprender nuestro oficio. Grado, Post-grado, Master, cursos, eventos, viajes, equipos, software, etc. Entonces, ¿de verdad hay que considerar que "tenemos la obligación" de reportar ese fallo una vez que lo descubramos?

    En mi caso particular, no soy un ciber-criminal que usa el fallo para mi propio beneficio ni un mercenario que lo vende en el mercado negro (jamás he hecho ninguna de las dos cosas), pero desde luego y, muy importante, según el caso y el tipo de fallo; tampoco me considero una ONG para ir buscando fallos e ir "regalando" mi trabajo (con todo el respeto del que lo haga, cada cual tendrá sus razones). Ojo, hay que diferenciar en alguien que trabaja en una compañía que se dedica a esto o que sus empleados hacen esto para obtener reputación propia o para la empresa; a alguien que desde su casa invierte su tiempo libre después del trabajo o fines de semana. Es decir, el primero quizás le pagan para ello o es su trabajo, sin embargo el último sólo lo hace inicialmente por auto estima personal (insisto, inicialmente).

    Creo que no hay una solución directa ya que cada caso es distinto. Una posible solución es, por ejemplo, participar en esos programas de recompensa, que tienen los problemas que comentas en tu artículo; pero que desde luego son una excelente oportunidad para sentirte valorado. Lamentablemente casi ninguna empresa los aplica (considerando el enorme universo de empresas que hay con servicios IT disponibles). Tomemos en cuenta también que hay empresas que les reportas el fallo, lo parchean y ni siquiera te contestan los emails. Es decir, ni las gracias.

    Yo tengo alguna otra alternativa que he llegado a hacer con lo que he encontrado y que no es ninguna de las 3 que planteé antes (ciber-criminal, mercenario, ONG), pero me gustaría saber qué piensan otros expertos de esta área, por lo que voy a abrir un debate en alguna clase del Máster en Seguridad de las TIC de la Universidad Europea de Madrid, del cual soy estudiante de la 7ma edición. Intentaré que sea en una de las clases donde Chema Alonso sea el docente, para que te llegue el feedback.

    Un abrazo y un caluroso saludo a todo el equipo de Eleven Paths.
    Daniel Ferreira

    ReplyDelete