23 - Publicar Todo o Nada (Disclosures) - 13/01/2006


Autor: Lic. Cristian F. Borghello

http://www.segu-info.com.ar

A la luz de algunos hechos recientes a saber:

he estado reflexionando sobre las ventajas, desventajas y riesgos de los distintos métodos actuales de publicación de vulnerabilidades: el "Full Disclosure" y la "Seguridad por Oscuridad".

El Full Disclosure (divulgación masiva) se refiere a divulgar todos los detalles de un problema de seguridad de un producto determinado. Estos detalles son divulgados por cualquier persona que encuentra o conoce dicha vulnerabilidad, sin mediar antes una comunicación a la empresa responsable del producto (vendor). Con esto no se da la posibilidad a la empresa de encontrar una solución y si se da la posibilidad a terceros malintencionados para explotar dicha vulnerabilidad. Si bien esto parece una faceta negativa de esta política, los que la defienden sostienen que publicar una vulnerabilidad presiona al fabricante a dar una solución antes de los tiempos políticamente manejados por esa organización. En este modelo se tiene una vulnerabilidad conocida y ampliamente expandida.

Un caso típico de Full Disclosure es la citada vulnerabilidad de Windows. En este caso la presión que ejerció la comunidad obligó a Microsoft a lanzar la solución antes de los tiempos estimados, pero por otro lado el conocimiento de la vulnerabilidad permitió el desarrollo de un amplio espectro de ataques y gusanos basados en el exploit publicado inicialmente.

En el otro extremo del cuadrilátero se encuentra la "Seguridad por Oscuridad" basada en el principio de ocultar la forma en que se otorga seguridad a un elemento determinado. Aquí, un producto es diseñado e implementado pensando en que sus eventuales fallos no serán descubiertos o que sea poco probable que eso suceda. En este modelo se tiene una vulnerabilidad conocida por pocos y no distribuida.

Este tipo de seguridad es utilizado por SQL Server para cifrar sus Stores Procedures y por el Ministerio de Educación Argentino para almacenar los datos de sus usuarios. Como vemos el secreto permanece oculto dependiendo de la cantidad de personas y empeño (y muchas veces suerte) de que se dispongan.

A modo de ejemplo cuando se diseña un clásico sistema de logueo con usuario y clave estos datos pueden ser almacenados de diversas formas: todo en texto plano, todo cifrado, cifrando algunos datos utilizando hashing, etc.

Para el caso de "Seguridad por Oscuridad" el usuario que utiliza el sistema no conoce el método utilizado por los desarrolladores y si un atacante descubre una vulnerabilidad en el mismo, este tendrá acceso a datos privados de todos los usuarios y seguirá teniendo acceso a ellos hasta que la vulnerabilidad sea re-descubierta, informada y solucionada.

Para el caso del "Full Disclosure", el atacante informa a la comunidad y la misma dispone lo que hace con ella.

Existe el caso en que ciertas vulnerabilidades se conocen en algunos círculos "exclusivos" y las mismas son utilizadas por sus miembros sin publicarlas y sin informarlas al vendor. Esto da la posibilidad a estas personas de acceder a ciertos datos o funcionalidades que de otro modo serían privados.

Como en casi cualquier situación los extremos no son buenos: al publicar ampliamente una vulnerabilidad estamos dando poder a cualquier persona para que la explote; pero si no se publica estamos dando tiempo a otros para que la encuentren y la exploten.

Políticas intermedias a la planteada son "Responsible Disclosure" o "Limited Disclosure" que sugieren que el descubridor informe los datos a la organización responsable del producto vulnerable y luego de un "tiempo prudencial" haga pública la vulnerabilidad a la comunidad.

Este modelo más colaborativo tiende a solucionar los contras de los modelos anteriores pero queda poco claro que es un "tiempo prudencial" y se manejan espacios tan dispares como 30 días u 8 horas. En este modelo existe una política que da a la empresa un tiempo determinado (5 días) para responder al informante y si, superado este tiempo, no se tiene respuesta, se autoriza a hacer público el informe. Esta política es conocida como RFPolicy y fue desarrollada por Rain Forest Puppy Labs. La desventaja aquí es la poca importancia que dan ciertas organizaciones a las personas o investigadores responsables que informan el hallazgo de una vulnerabilidad en un producto. Por lo general se termina haciendo pública la vulnerabilidad por la impotencia que se siente al no obtener respuesta.

Este es el caso de Terra, el Ministerio de Educación y el mío propio con la empresa Symantec.

Por último y a modo de referencia mucha de las organizaciones encargadas de la investigación y descubrimiento (research) de vulnerabilidades utilizan esta última política de informar al vendor, esperar su confirmación cierta cantidad de días y sólo publicar la vulnerabilidad una vez corregida la misma, sea cual sea el tiempo que se empleo en el proceso.

Más información:

Actualización 15/01/2006

http://www.sahw.com/wp/archivos/2006/01/13/disclosures-si-o-no-danan-mas-o-menos-al-usuario/
http://www.sahw.com/wp/archivos/2006/01/08/mike-nash-habla-de-la-vulnerabilidad-wmf/

Buenos Aires, 13 de enero de 2006

Con más de 24 años de experiencia compartiendo la mejor información de Seguridad

Contacto