Ekoparty 2010: vulnerabilidad 0-day publicada

Existen fiestas que se esperan con muchas ganas, y una vez que llegan deseamos que jamás terminen para no tener que esperar hasta la próxima. Esta sensación es la que se vive año tras año con Ekoparty, el evento de seguridad informática de habla hispana, a nivel técnico el más importante de la región. El mismo es realizado anualmente en Buenos Aires, Argentina; y reúne a cientos de profesionales del mundo de la seguridad.

Pero además de ser un evento, Ekoparty es un punto de encuentro, una posibilidad de actualización, una oportunidad de conocer nuevos colegas, y mucho más. Cada año la fiesta se renueva, y este año en particular lo hizo con algunas controversias. Si bien en cada nueva edición se anuncian las novedades del sector en su aspecto más técnico (y también podríamos decir más underground) esta vez para algunos se cruzó indebidamente una línea, ya que dos especialistas anunciaron en una de las últimas conferencias, una vulnerabilidad del tipo 0-day (zero day). Una vulnerabilidad 0-day se considera a aquella para la cual existe un exploit pero no una solución. En este caso se trata nada más y nada menos que de Microsoft. Al existir una vulnerabilidad desconocida aún por la empresa de software, los clientes están desprotegidos frente a ataques que se aprovechen de dicho bug. Ahora bien, esto no hubiera sido tan grave si además no hubiera existido un exploit 0-day, es decir, un programa que permite aprovechar dicha vulnerabilidad. Y peor aún, tampoco hubiera sido tan grave si no se hubiera distribuido el exploit entre los asistentes.

Este tema suele resultar álgido a la hora de definir lo que es correcto o no lo es, por lo que un breve análisis nos puede permitir arrojar algo de luz sobre la situación. Veamos: un especialista encuentra una nueva vulnerabilidad y puede reportarla o no al fabricante. Si la reporta, el fabricante puede decidir resolverla en un determinado momento y negociar con el especialista por haberla reportado, o bien puede hacer caso omiso, ignorando la problemática o minimizándola. Si no la reporta, existirá una nueva vulnerabilidad que solo conoce el descubridor, pero si éste la publica, pasa a ser conocida por todos, incluido el fabricante, en el momento que lo hace público. Este último escenario es el peor de todos para lo que a los usuarios se refiere, ya que las empresas y organizaciones que están afectadas por la vulnerabilidad anunciada, pasan a estar expuestos a los ataques de cualquiera que sepa como hacerlo, dado que el mismo es público. Por su parte el fabricante debe apurar sus procesos para liberar un parche, y es probable que dada la velocidad a la que lo hará para evitar mayores inconvenientes, no pueda cumplir con los mismos estándares de calidad que si el error hubiera sido anunciado de otra manera.

La pregunta lógica es: ¿entonces por qué un especialista haría esto? Aquí surgen otras cuestiones mas allá de la ética de cada persona. Históricamente se ha criticado de las grandes corporaciones de software, que no tomaban en cuenta los avisos de vulnerabilidades descubiertas por investigadores independientes. Esto ha sido en alguna medida cierto hasta que comenzaron a establecerse políticas y acuerdos para definir un flujo de trabajo en el que pueda darse contención a este tipo de necesidades, pero sin duda que no es lo más normal hoy en día que las empresas ignoren los avisos de nuevas vulnerabilidades. De lo contrario, saben que podría ocurrir una catástrofe al publicarse un bug grave que afecte a muchos usuarios. Según la opinión de algunos especialistas, las grandes compañías de software muchas veces se muestran reticentes frente a los nuevos anuncios de fallos por parte suya, por lo que algunos optan por la publicación masiva, incluso como medida de protesta o demostración de poder. Por otra parte, aseguran que al estar publicado el error, el fabricante se preocupará mucho más de resolverlo debido a la obligada presión. Además, es razonable que un profesional espere un rédito económico por haber encontrado un problema en un producto o tecnología, que hará que una compañía se beneficie, el problema por lo general es cómo llegar a un acuerdo.

Ahora bien, también existen proyectos como ZDI (Zero Day Initiative) que proponen reunir investigadores para definir un marco de divulgación controlada de fallas de seguridad, operando como intermediario entre los especialistas y las empresas, para evitar problemas comerciales, negociaciones personales, estancamientos en el flujo de comunicación, y por sobre todo, problemas en el mercado. Que existen mercados alternativos de compra y venta de vulnerabilidades también es cierto, pero justamente es decisión de cada profesional ubicarse de alguno de los dos lados de la fina y gris línea de la ética.

En conclusión, la cadena de perjuicios cuando se producen este tipo de acciones de full disclosure arranca por la empresa y, por supuesto, llegando hasta el usuario final, que se transforma en víctima de posibles ataques sin poder elegir qué hacer y en muchos casos sin protección alguna. Por su parte, quien descubre y publica algo así suele ser visto como héroe entre sus pares y colegas, por lo que también es un motivo de incentivo personal para hacerlo, por la necesidad de algunas personas de ser reconocido y de obtener fama o poder. Tal vez la mejor manera de resolver esto para que sea ventajoso para todos, sea trabajar en conjunto entre las empresas y las personas para definir caminos, pautas y condiciones, a fin de que todos ganen y pueda existir tanto el reconocimiento y ganancia para las personas como el beneficio comercial y técnico para las empresas. De esta manera se haría posible un contexto de liberación controlada de vulnerabilidades en el que se respeten los derechos y libertades de ambas partes, en real beneficio de todos los involucrados.

Federico Pacheco
Education & Research Manager

Autor , ESET

Síguenos