Un agujero de seguridad o vulnerabilidad es un fallo en un sistema de información que se puede explotar para violar la seguridad del sistema.
Ejemplos de tipos de vulnerabilidades según la naturaleza del mismo:
La mejor política contra los agujeros de seguridad, reducir su número y facilitar su localización, es prevenirlos en el proceso de desarrollo. Para ello se ha creado el ciclo de vida de desarrollo seguro de software (S-SDLC) el cual incorpora la seguridad dentro del ciclo de vida de desarrollo del software. Cada fase el ciclo de vida tiene en cuenta la seguridad conseguir maximizar la seguridad.
Ejemplos de buenas prácticas para conseguir un software con menos vulnerabilidades:
En el tiempo de vida de una vulnerabilidad podemos distinguir los siguientes hitos o etapas importantes:
Estos eventos no necesariamente ocurren estrictamente en este orden. Por ejemplo:
La búsqueda de vulnerabilidades de seguridad es realizada principalmente por dos tipos de personas u organizaciones:
Las formas de conseguir información sobre vulnerabilidades son las siguientes:
Los dos aspectos fundamentales a estudiar sobre el tratamiento de la información sobre vulnerabilidades son:
Supongamos que alguien no implicado en un producto descubre una vulnerabilidad. Este puede tomar 4 opciones principales:
Los tres primeros casos podríamos agruparlos diciendo que adoptan una política de revelación basada en no revelar públicamente la información (cada uno por motivos distintos). En el último caso el individuo se enfrentaría a tomar una decisión sobre qué política de revelación pública de la información quiere usar.
La fecha de revelación es la fecha en la que se describe por primera vez la vulnerabilidad en un canal con las siguientes características:
Si el sujeto quiere revelar públicamente la información sobre la vulnerabilidad, se enfrenta a una compleja pregunta: ¿Cómo revelar la información sobre dicha vulnerabilidad?. La información sobre vulnerabilidades, cuando se revela, puede obligar al proveedor del producto a tomar acciones rápidamente para arreglar el defecto que lo hace posible; Sin embargo, esta misma información puede amplificar los riesgos para los usuarios y dar poder a aquellos que con malas intenciones quieren explotar la vulnerabilidad antes de que sea arreglada.
La política a tomar es un tema controvertido y no sólo es exclusivo del mundo informático. Por ejemplo en el pasado hubo controversias en el mundo de la cerrajería sobre la distribución del conocimiento de las vulnerabilidades que tenían las cerraduras.
Teniendo en cuenta los diversos factores (costes, beneficios y riesgos) se han propuesto distintos tipos de prácticas y políticas para la revelación de la información sobre vulnerabilidades. Las propuestas podríamos clasificarlas en 3 tipos: No revelar, revelación completa y prácticas a medio camino entre una otra (revelación parcial).
Podríamos considerar que la no revelación pública (extensiva) de la información sobre la vulnerabilidad es en sí misma una política de revelación. La información se mantiene en secreto. Este enfoque se basa en dar prioridad a mantener en secreto la vulnerabilidad frente a dar publicidad a la información para podernos proteger frente a ella.
Algunas veces en lugar de una no revelación absoluta, la información sobre la vulnerabilidad se comparte de forma restringida (pseudosecreto). Cuanto más amplio sea el número de personan que conocen la vulnerabilidad se incrementa el riesgo para los usuarios finales. La información puede revelarse por ejemplo a:
Muchas veces el descubridor de la vulnerabilidad toma esta política y la información se va divulgando por canales privados hasta que llega a cierta organización o persona que decide publicarla para evitar daños mayores.
La estrategia de revelación completa, revelación total o divulgación masiva (en inglés full disclosure) consiste en revelar a toda la comunidad (divulgación masiva) toda la información disponible sobre un problema de seguridad en cuanto este es conocido. Por ejemplo se puede dar información de como se encontró el fallo, qué sistemas son vulnerables, como explotar la seguridad o como protegerse frente al fallo. Se revelan todo tipo de detalles sobre el fallo y esta información tan detallada puede ser usada por hackers malintencionados para desarrollar exploits que permitan aprovechar la vulnerabilidad a cualquiera que lo utilice, aunque no entiendan el funcionamiento del mismo (script kiddies).
La políticas de revelación revelación parcial (en inglés partial disclosure) intentan establecerse como punto intermedio entre la política de seguridad por oscuridad y las política de revelación completa. Intentan aprovechar buenas ideas de una y otra política para situarse en un punto intermedio con mejores características. Se han desarrollado distintos modelos pero cada uno tiene sus inconvenientes considerándose el problema de la política de revelación como un problema abierto y pendiente de solución.
Alrededor del mundo de los agujeros de seguridad se ha ido creando una importante actividad económica, dando lugar a negocios a veces muy lucrativos. El activo con el que se negocia es la información sobre la vulnerabilidad. El negocio suele estar en:
Se ha propuesto que la existencia de un mercado de vulnerabilidades puede ser una buena idea para incentivar a los proveedor de sistemas para que se preocupen más en mejorar la seguridad de sus productos y en arreglar rápidamente las vulnerabilidades que se vayan encontrando.
Las motivaciones para la existencia de este tipo de mercado son, en última instancia:
Los actores en este mercado son:
Los proveedores de productos juegan un papel especial en este mercado ya que el mercado se basa en la existencia de fallos en sus productos, lo que les puede provocar la pérdida de confianza y finalmente la pérdida de clientes. La existencia de un mercado de vulnerabilidades no les beneficia ya que:
Por tanto intentan no fomentarlo aunque están siendo obligados por su crecimiento a entrar poco a poco en él para no verse excluidos cada vez más del conocimiento de las vulnerabilidades de sus propios productos. Por ejemplo cada vez es más frecuente la convocatoria de concursos remunerados para la búsqueda de vulnerabilidades.
Para fomentar la revelación de la información sin pagar están tomando una serie de iniciativas como por ejemplo:
Podemos hablar de dos mercados de vulnerabilidades claramente diferenciados: el lícito y el ilícito. Al ser una diferencia puramente legal, dependerá de la jurisdicción del país en el que estemos el que ciertos negocios pertenezcan a uno u otro mercado. Por este motivo las contrataciones de hackers con propósitos más controvertidos se realiza en países con legislación no muy restrictiva por ejemplo: Brasil, Rusia y Ucrania.
Para que el mercado lícito sea realmente efectivo tiene que:
Los principales inconvenientes de este tipo de mercado tienen que ver con la revelación de la información, la incentivación a los investigadores y el aumento de los precios de las vulnerabilidades
La existencia del mercado de vulnerabilidades provoca una resistencia a que los agujeros de seguridad sean revelados para que puedan ser arreglados. La información sobre la vulnerabilidad pierde valor cuanto más gente la conoce y pierde totalmente el valor cuando el problema es arreglado y ya no existe. Por tanto hay una tendencia, para proteger el valor de la información, a mantener la información oculta. Todo esto repercute en una menor seguridad de los productos.
En general las más importantes empresas que se dedican a este negocio están comunican a los proveedores sobre las vulnerabilidades que encuentran. Sin embargo hay algunas compañías pequeñas que no lo hacen. Esta política de no revelación de vulnerabilidades es muy criticada pero no se suele considerar ilegal ya que la información es vendida con descargo de responsabilidad diciendo que esa información debería ser usado para pruebas internas, no para burlar la ley.
Los gobiernos, dependen del tipo de vulnerabilidad que encuentren, informan al proveedor del producto o no. Si se trata de un punto débil de sistemas que ellos mismos usan entonces comunicarán al proveedor. Si por ejemplo se trata de una vulnerabilidad utilizada en una herramienta ofensiva, entonces no revelará al proveedor la información sobre dicha vulnerabilidad
La existencia de un mercado donde vender las vulnerabilidades provoca que haya una mayor investigación de vulnerabilidades, lo que provoca que se descubran más y por tanto haya un conjunto más amplio de vulnerabilidades activas que causas inseguridad a los usuarios
La existencia de un mercado cada vez más amplio de vulnerabilidades provoca que los precios suban. Esto provoca que la información sea menos accesibles a los proveedores que en definitiva son los que arreglan la vulnerabilidad para todos sus clientes.
Ejemplos de negocios en el mundo de las vulnerabilidades:
Hay distintas iniciativas cuyo propósito es gestionar información sobre vulnerabilidades.
El MITRE tiene distintas catálogos que permiten hacer un seguimiento de las vulnerabilidades (CVE), debilidades documentadas (CWE) y patrones de ataque (CAPEC). Los tres catálogos están estrechamente vinculadas, es decir, una vulnerabilidad es explotada gracias a una debilidad conseguida en un software o hardware, que a su vez ha sido aprovechada a través de un patrón de ataque. Por tanto, cada vez que cualquiera de las tres listas recibe una nueva entrada, ésta es considerada, comprobada y estudiada, por lo que muy probablemente se puedan generar o complementar los registros en cualquiera de las otras.
Asociado a las anteriores el MITRE tiene un formato (CPE) para identificar de forma detallada sistemas, productos y plataformas
El MITRE CVE List o simplemente CVE es un catálogo de vulnerabilidades que asocia a cada vulnerabilidad conocida un identificador único que se conoce como CVE-ID. Este código CVE-ID es usado como estándar de nomenclatura de vulnerabilidades por la mayoría de repositorios de vulnerabilidades para identificar cada vulnerabilidad. Además del identificador el catálogo describe en qué consiste la vulnerabilidad, que versiones del software están afectadas, posible solución al fall (si existe) o como configurar para mitigar la vulnerabilidad.
El Common Weakness Enumeration o CWE es un catálogo de debilidades documentadas de software y hardware habituales que podría derivar en vulnerabilidades. Por ejemplo, inyección SQL (CWE-89) o desbordamiento de búfer (CWE-120) son entradas de este catálogo. Es muy utilizada por distintas herramientas de seguridad encargadas de identificar estas debilidades y para promover la identificación de las vulnerabilidades, mitigación y su prevención. Para cada debilidad se aporta un identifcador CWE-ID, que es usado como estándar, y datos como la descripción, tiempo de introducción, ejemplos etc.
El Common Attack Pattern Enumeration and Classification o CAPEC es un catálogo de patrones de ataque que recolecta información sobre ellos, junto a un esquema de clasificación exhaustiva. Un patrón de ataque es la descripción del método utilizado para la explotación de una vulnerabilidad, es decir, modelo para hacer un exploit de la vulnerabilidad. Muchas de las vulnerabilidades que se registran comparten patrones de ataques. Por ejemplo, el patrón de ataque 'Explotar confianza en cliente' (CAPEC-22) es un patrón de ataque para canales cliente/servidor con autenticación y integridad de datos, en el que se aprovecha la confianza ientre el cliente y el servidor paara ejecutar un tipo de ataque en el que el servidor cree que es un cliente válido. A cada patrón de ataque se le asocia un identificador CAPEC-ID, que es usado como estándar, y luego se aportan datos como la descripción, mitigaciones, recursos o habilidades necesarias para el ataque,...
El Common Platform Enumeration o CPE es un formato que permite identificar con exactitud, con un nombre único y estándar sistemas, productos y plataformas. Es usado para determinar de forma totalmente unívoca y exacta las versiones, ediciones o idiomas, de un producto que están afectadas por una vulnerabilidad por una vulnerabilidad. EL NIST mantiene una versión autorizada para su distribución como parte de su iniciativa NVDB.
Por ejemplo para referirse a Microsoft Internet Explorer 8.* SP? (sin edición y en cualquier lenguaje) se usa:
Hay distintas iniciativas para evaluar de forma estándar la criticidad de las vulnerabilidades. Se basan en dar puntuaciones en base a distintos criterios. Estos métodos estándar permiten establecer criterios representativos del riesgo en la organización, lo que se suele traducir en una priorización consciente de las medidas de seguridad que se desean aplicar.
El Common Vulnerability Score System o CVSS es un estándar abierto definido por el Forum of Incident Response and Security Teams (FIRST) que cuantifica las vulnerabilidades estimando el impacto derivado de la misma. Se usa un puntaje del 1 al 10 y para establecerlo se usan una serie de métricas públicas. Este estándar es usado por la National Vulnerability Database y por el Common Vulnerabilities and Exposures. La forma de establecer las medidas va evolucionando, produciendo nuevas versiones del estándar.
Creado por el MITRE como parte del proyecto CWE y contando con el apoyo del gobierno de los Estados Unidos, el Common Weakness Scoring System o CWSS es un estándar que pretende ser una evolución del CVSS. Sigue un criterio más avanzado que su antecesor. Por ejemplo: Se tienen en cuenta los efectos de los procesos críticos de negocio, determina hasta qué punto esa vulnerabilidad podría ser aprovechada por hackers (puede otorgar acceso a documentos en modo de sólo lectura o si las cosas serían más graves y se podría acceder en modo de escritura, pudiendo modificar datos o eliminarlos).
El CWSS está orientado a los desarrolladores y a facilitar su trabajo estableciendo criterios para su utilización durante la fase de desarrollo de un programa. Por ejemplo si se descubre un buffer overflow durante una auditoría de código, se le asigna una prioridad CWSS baja si los datos que disparan ese suceso no son ingresados por el usuario sino que son parte del funcionamiento aleatorio del programa.
No existe una web, servicio o aplicación pública que utilice este sistema. En sus inicios, este sistema se solía promover a través de publicaciones (como por ejemplo los documentos desarrollados entre el MITRE y SANS Institute del tipo Top 25 Most Dangerous Software Errors), sin embargo, en la actualidad es difícil encontrar información reciente asociada a debilidades de software. Puede deberse a que hoy por hoy la lista CWE se actualiza muy poco y a que las empresas de desarrollo de software protegen el código de sus aplicaciones y su estudio, valoración y resolución se suele gestionar de manera privada sin compartir la información.
Además de la CVE del MITRE, que funciona más como fuente de información básica que proporciona una identificación estándar de vulnerabilidades, hay distintas bases de datos de vulnerabilidades:
El volumen de crecimiento de las vulnerabilidades junto a la existencia de distintos repositorios de vulnerabilidades, las cuales a su vez no suelen ser muy cómodas de consultar, a provocado la aparición de software que se encarga de buscar automáticamente en los distintos repositorios de vulnerabilidades. Es frecuente que estas herramientas también consulten varias bases de datos de exploits. Ejemplos de este tipo de herramientas son Pompem, vFeed y vulnerability-alerter
Otro enfoque consiste en descargar toda la información, almacenarla en una base de datos y hacer consultas sobre ella. Este es el enfoque de por ejemplo cve-search
Varias industrias, incluida la industria de salud, los bancos e, incluso, el gobierno de los Estados Unidos, se han visto afectadas por brechas de seguridad por causa de vulnerabilidades de sistemas.
Casos incluyen:
Escribe un comentario o lo que quieras sobre Agujero de seguridad (directo, no tienes que registrarte)
Comentarios
(de más nuevos a más antiguos)