El tratamiento de la información, una vez detectada una vulnerabilidad en un producto informático, es algo que requiere un tratamiento específico por las consecuencias que puede acarrear una inadecuada divulgación del hallazgo. En esta tercera entrega sobre hacking ético vamos a analizar cómo se aborda esta cuestión.
Prácticamente todo el software que sale al mercado presenta vulnerabilidades y bugs (errores o fallos en un programa de dispositivo o sistema de software que desencadena un resultado indeseado). Estas imperfecciones pueden ocasionar muchos problemas de seguridad a corporaciones o usuarios particulares.
La empresa, que tiene toda la información del código del producto vulnerable, no quiere hacer pública esta información sensible sobre su producto porque puede suponerle diversos problemas de seguridad y prestigio.
El primer problema sería que los detalles del fallo ayudarán a que los crackers utilicen la vulnerabilidad para atacar los sistemas o el software en cuestión. El argumento de la empresa afectada por el fallo se basa en que si el asunto se mantiene confidencial mientras se diseña una solución, los atacantes no sabrán cómo aprovechar la vulnerabilidad.
El otro problema sería que la publicación de ese fallo podría dañar la reputación de la empresa.
Para eso, los hackers éticos tienen que saber actuar de manera responsable y utilizar los métodos adecuados para desvelar ese error de seguridad. No se trata de realizar un ataque y después explicar a otras personas como lo hacen, sino de trabajar en conjunto con el propietario de la aplicación para mitigar la vulnerabilidad.
Veremos el proceso que se tiene que llevar a cabo cuando se detecta un bug o vulnerabilidad en alguna aplicación. El proceso para la divulgación de la vulnerabilidad ha creado un gran debate entre empresas informáticas, cada una percibe el asunto de manera muy distinta. Debido a los diferentes puntos de vista, varias empresas se han unido para crear políticas e instrucciones de cómo proceder en la divulgación de vulnerabilidades.
Se pensó en la idea de crear una lista de distribución, donde las personas que descubrían vulnerabilidades, y conocían formas para aprovechar esas vulnerabilidades, se comunicaban directamente mediante este foro.
Lo que sucede es que, por lógica, ese foro se ha transformado en una fuente de información para los ciberdelincuentes, haciendo que muchas empresas dejaran de publicar sus informaciones y solicitando un tratamiento más responsable de la divulgación de la información. En consecuencia, varias empresas han creado su propia política de privacidad de la información.
Divulgación de las vulnerabilidades
La divulgación adecuada de las vulnerabilidades de software, se lleva a cabo mediante un centro conocido como Centro de Coordinación CERT/CC. Este centro fue creado en 1988 en el Software Engineering Institute debido a los problemas creados por el gusano informático Morris. Desde ese momento se convirtió en un centro de coordinación mundial sobre problemas de seguridad. En el año de 2000 se publicó una política que define los siguientes aspectos:
– La publicación se anunciará dentro de los 45 días siguientes tras la comunicación a CERT/CC.
– El CERT/CC notificará la vulnerabilidad al responsable del software de manera inmediata, de modo que se pueda desarrollar una solución lo más antes posible.
– Junto con la descripción del problema, CERT/CC les enviará el nombre del informante a menos que esa persona solicite el anonimato.
– Durante el transcurso de 45 días, CERT/CC informará al experto que comunicó la vulnerabilidad, sobre el estado de esta, sin revelar información confidencial.
La política que adopta CERT/CC indica que su propósito principal es informar al público de situaciones de amenazas emergentes y, al mismo tiempo, ofrecerle al propietario del software un tiempo hábil para solventar el problema. Otra información importante es que CERT actualmente trabaja con la guía de la Organización para la Seguridad en Internet.
Política de divulgación (Rainforest Puppy Policy)
La política de divulgación de toda la información confidencial, conocida como RFP (Rainforest Puppy Policy), es más dura con los propietarios de software que CERT/CC. Con esa política se tiene que informar de la vulnerabilidad haciendo un esfuerzo para ponerse en contacto con el desarrollador y trabajar juntos para solucionar el problema, pero el hecho de estar cooperando con el propietario es un paso que el informador no está obligado a ejecutar, de modo que se considera algo voluntario. La política es muy estricta con el propietario por temas de confidencialidad.
Los responsables de mantenimiento de la empresa tendrán cinco días para dar una respuesta al informante. Si no se le comunica en el tiempo indicado, el informante es libre para publicar la información del fallo, pero este tiene que hacer todo lo posible para ayudar a la empresa propietaria a reproducir el problema y cumplir con unas demandas razonables.
Rain Forest Puppy es un conocido hacker que ha descubierto vulnerabilidades en distintos productos. Su trabajo consiste en ayudar a desarrollar parches para los problemas desvelados.
Organización para la Seguridad en Internet (OIS)
Básicamente existen tres tipos de información sobre las vulnerabilidades: completa, parcial y sin divulgación. Debido a que se crearon pautas muy estrictas que entraban en conflicto, como las CERT y RFP. Se tuvo la necesidad de crear la Organización para la Seguridad en Internet con el fin de arbitrar esta situación.
La Organización para la Seguridad en Internet es un grupo de investigadores y fabricantes que se formó con el objetivo de mejorar la forma en la que se gestiona las vulnerabilidades de software.
No se trata de una organización privada que le exige el cumplimento de su política a todo el mundo, lo que intenta es crear un amplio y constructivo debate que incluya opiniones cualificadas e imparciales que adquieran la categoría de recomendaciones.
Los objetivos son:
- Reducir el riesgo de aparición de vulnerabilidades desde el exterior, ofreciendo un adecuado método de identificación e investigación.
- Mejorar toda la calidad de ingeniería de software ajustando la seguridad que se aplica el producto final.
Descubrir el fallo en un software.
Ese proceso empieza cuando se detecta algún fallo de seguridad. Tras el hallazgo, se espera que el experto realice las siguientes acciones:
- Descubrir si ya se ha informado de ese fallo anteriormente.
- Buscar parches o actualizaciones.
- Averiguar si el fallo afecta a la configuración predeterminada del producto
- Asegurar que el fallo puede reproducirse de manera consistente.
Después de que el descubridor está seguro de que el fallo existe y tiene toda la información, tiene que elaborar una pauta de informe. OIS ha desarrollado lo que se llama VSR (Informe Breve de Vulnerabilidad). Ese informe incluye la siguiente información:
– La información de contacto del descubridor.
– La política de respuesta de seguridad.
– El estado del fallo (público o privado).
– Si el informe contiene o no información confidencial.
– Los productos implicados.
– Las configuraciones afectadas.
– Descripción del fallo.
Gustavo Romero Sánchez
Gestor de Redes y Recursos Informáticos en el sector de la Seguridad.
Criminólogo y Antropólogo Forense
Tutor Tecnológico en Curso Superior de Ciberseguridad
Fuentes
- Webs
Incibe.es
Wikipedia.com
- Trabajos
Hacking ético y seguridad en red, TFC – UOC, 2014, autor: C. Días, J.Serra, J.M. Castillo
