miniaturadeimagen|Cronología de una vulnerabilidad de hardware/software desde su aparición hasta su corrección 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.
Los académicos definen una vulnerabilidad como una debilidad en el sistema que es aprovechada por una amenaza, que representa un factor potencial que podría conducir a un evento que cause daño a un sistema. Las amenazas pueden incluir pérdida de datos, autenticación débil, tecnología compartida, errores humanos y violaciones de datos.
Tipos Ejemplos de tipos de vulnerabilidades según la naturaleza del mismo: De software. Ejemplos: Inyección SQL Desbordamiento de búfer Clickjacking Condiciones de carrera Cross-site request forgery Cross-site scripting De hardware Del entorno físico del sistema Del personal involucrado De procedimientos de administración, organización y seguridad involucrados De la red de comunicaciones utilizada
Prevención 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.Introduction to Secure Software Development Life Cycle. infosecinstitute.com. 1 de febrero de 2013.
Ejemplos de buenas prácticas para conseguir un software con menos vulnerabilidades:POLÍTICAS DE SEGURIDAD DE LA INFORMACIÓNR.0POLÍTICA GLOBAL DE SEGURIDAD DE LA INFORMACIÓN. Fundación Pascual Tomás. 25 de septiembre de 2018. Mantener las herramientas de desarrollo actualizadas Usar buenas prácticas de codificación Establecer requisitos de seguridad Eliminar del software los módulos y archivos que no se utilicen. Registrar todos los eventos en un log. Evitar mostrar mensajes de error tal cual los genera el sistema Usar autorizaciones además de autenticar. Separar los datos de las instrucciones de control Validar todos los datos explícitamente. Identificar datos sensibles y como se les debería gestionar Usar procedimientos de actualización seguros La configuración por defecto debe ser una configuración segura Uso de herramientas de prueba especialmente diseñadas para la detección de vulnerabilidades. Por ejemplo: Fuzzers. Se basan en inyectar entradas con datos aleatorios y verificar el comportamiento Herramientas de prueba de seguridad de aplicaciones (AST, del inglés Application Security Testing. Son herramientas que prueban la seguridad de las aplicaciones. Dependiendo de su funcionamiento se pueden clasificar en:Herramientas de prueba de seguridad de aplicaciones (AST). A2Secure. 29 de mayo de 2019. Basadas en el análisis del código (SAST, del inglés Static Application Security Testing) Basada en el análisis en la salida obtenida al ejecutar con ciertas entradas (DAST, del inglés Dynamic Application Security Testing) Herramientas de análisis en tiempo real de la ejecución (RAST, del inglés Run-time Application Security Testing). Están inmersas en el entorno de ejecución y analizan como se realiza la ejecución. Herramientas de análisis interactivo (IAST, del inglés Interactive Application Security Testing). Combinan la observación interna y externa de una aplicación en ejecución. Se suelen implementar como un agente dentro del entorno de ejecución de prueba. Pueden probar si vulnerabilidades conocidas en el código son realmente explotables en ejecución. Herramientas híbridas que combinan varias de las estrategias antes mencionadas.
Hitos o etapas En el tiempo de vida de una vulnerabilidad podemos distinguir los siguientes hitos o etapas importantes:Arbaugh, Fithen y McHugh,"Windows of Vulnerability: A Case Study Analysis"S. Shepherd, "Vulnerability Disclosure: How do we define Responsible Disclosure?Andrew Cencini et ali.,"Software Vulnerabilities: Full-,Responsible-, and Non-Disclosure", diciembre de 2005. Nacimiento. Durante el proceso de desarrollo del producto por parte del proveedor (por ejemplo, el vendedor o una comunidad de desarrolladores de software) se introducen una serie de defectos. Estos defectos pueden ser de diseño, implementación o de gestión. Algunos de esos defectos pueden convertirse en riesgos para la seguridad del producto y por tanto para la seguridad del usuario del producto. Un defecto se convierte en una vulnerabilidad si hace que el comportamiento del sistema sea tal que pueda ser aprovechado para conseguir acceso no autorizado, elevación de privilegios, denegación de servicio o cualquier otra forma de romper la seguridad del sistema. No se consideran vulnerabilidades que son detectadas y corregidas antes del despliegue. Descubrimiento. Este hito ocurre cuando se tiene conocimiento de la existencia de la vulnerabilidad. Si la vulnerabilidad es creada intencionadamente entonces el nacimiento y el descubrimiento ocurren simultáneamente. Se llama descubridor a la primera persona que revela un defecto y determina que ese defecto es una vulnerabilidad. Si el descubridor no es conocido se dice que es anónimo. Comunicación de la vulnerabilidad. Este hito ocurre una vez que el descubridor revela la vulnerabilidad a alguien más. Esta transferencia de información puede ser de distintos tipos. Ejemplos: completa y pública vía (revelación completa) o comunicación privada entre hackers. Se llama originador (en inglés originator) o revelador (en inglés discloser) a la persona u organización que informa de la vulnerabilidad al proveedor del producto. Observar que el descubridor y el originador pueden ser personas distintas. Corrección. Ocurre cuando el vendedor del producto analiza la vulnerabilidad, localiza cual es el problema, y lanza una versión al público que resuelve la vulnerabilidad. Publicación. Es cuando el conocimiento de la vulnerabilidad se extiende a una audiencia importante dándole publicidad. Automatización de explotación. Es cuando a partir de la vulnerabilidad se crea una herramienta o script que automatiza la explotación de la vulnerabilidad. A esta herramienta o script se le llama exploit. De esta forma se permite que no sólo expertos sobre el tema (hackers) puedan vulnerar la seguridad. De esta forma se tiene una herramienta que permite a otros usuarios inexpertos (script kiddies) vulnerarla. Muerte. Ocurre cuando el número de sistemas vulnerables al exploit es insignificante. Esto puede haber sucedido porque el sistema ha sido retirado, el sistema ha sido arreglado mediante algún parche, o porque los hackers no tienen interés en explotarla.
Estos eventos no necesariamente ocurren estrictamente en este orden. Por ejemplo: La publicación y la corrección puede suceder al mismo tiempo, particularmente en casos donde el descubridor de la vulnerabilidad es el propio vendedor del producto, el cual usa el arreglo de la vulnerabilidad como parte de la propia publicidad del producto.E. Rescorla, Is finding Security Holes a Good Idea? La corrección de una vulnerabilidad no tiene por qué suceder antes de la automatización de la explotación. Si se construye un exploit antes de que la vulnerabilidad sea corregida por el proveedor, se dice que se trata de un exploit de día cero que da lugar a ataques de día cero. El descubrimiento se puede producir en el mismo momento del nacimiento, es decir, se trata de una vulnerabilidad intencionada. Se especula que algunos sistemas tienen desde el origen agujeros de seguridad intencionados conocidos por alguna de las partes que interviene en el diseño y/o desarrollo. Este tipo vulnerabilidades funcionaría a modo de puerta trasera o caballo de Troya. Ejemplos: En 2007, el gobierno de los Estados Unidos lanzó la un estándar para la generación de números aleatorios. Se proponían cuatro generadores de números pseudoaleatorios. Uno de ellos, el Dual EC DRBG, promovido por la NSA, tenía una puerta trasera que consistía en un conjunto de números secretos que permitían predecir la salida a partir de recopilar una pequeña porción de los resultados anteriores.Bruce Schneier, The Strange Story of Dual_EC_DRBG. Schneier on Security. Noviembre de 2007. Se ha hablado muchoDavid E. Ross,PGP: Backdoors and Key Escrow. 2002.Phil Zimmermann, Frequently Asked QuestionV. K. Pachghare, Cryptography And Information Security. PHI Learning. 2009. de las supuestas presiones que recibió PGP Corporation para introducir una puerta trasera en su software. Esta supuesta puerta trasera permitiría a la ciertas organizaciones (por ejemplo, FBI, NSA ) poder descifrar el contenido cifrado con esta herramienta. Para camuflar esta supuesta puerta trasera se especula que se presionó a PGP Corporation para que hiciera el código de PGP (software de código abierto) tan enrevesado y extenso que no se pudiera detectar tal puerta trasera. Esto provocó que muchos usuarios se quedaran con las versiones antiguas, fácilmente verificables, y promovió la creación de software alternativo. Otro caso es la supuesta introducción de una puerta trasera en openBSD promocionada por el FBI.Thom Holwerda, More Details Emerge Regarding OpenBSD FBI Backdoors. OS news. Diciembre de 2010.
Búsqueda de vulnerabilidades y motivaciones para su publicación La búsqueda de vulnerabilidades de seguridad es realizada principalmente por dos tipos de personas u organizaciones: Los atacantes de sistemas. Pueden aprovechar las vulnerabilidades para hacer vulnerables a los sistemas y conseguir de forma ilegal beneficios monetarios de ello, ya sea directamente (por ejemplo, permitiendo el uso de tarjetas de crédito ajenas) o indirectamente (por ejemplo, vendiendo información privada sobre las víctimas). Por su propia naturaleza este tipo de investigadores del vulnerabilidades no están interesados en la revelación de las vulnerabilidades descubiertas ya que así se aseguran de que la vulnerabilidad no sea arreglada y así puedan seguir beneficiándose de la misma. Profesionales de la informática y en especial de la seguridad. Estos profesionales, por distintas motivaciones, estudian de forma legal los sistemas y muchas veces logran encontrar vulnerabilidades. Este tipo de personas están interesadas en la revelación de la información. De esta forma acreditan haber encontrado la misma y así pueden apuntarse el mérito. Las motivaciones que tienen estos profesionales para encontrar la vulnerabilidades podríamos resumirlas en: Reputación. El que una persona o organización sea acreditada como la primera en descubrir una vulnerabilidad particular es muy importante en el mundo de la seguridad informática. Por un lado a las personas les acredita de habilidades y esto puede usarse para aumentar sus ingresos o conseguir mejores trabajos. Para una empresa también es importante porque puede utilizarse para conseguir clientes basándose en el alto nivel del personal que trabaja para ella. Perjudicar a competidores. Por ejemplo un desarrollador o compañía puede tener especial interés en buscar vulnerabilidades a productos de la competencia para poner en dificultades al proveedor y desacreditar sus productos. De esta forma se consigue mejorar la posición en el mercado del producto propio. Forzar al proveedor del producto a mejorar su calidad y que tenga más interés en producir software más seguro. Disfrutar del desafío intelectual de encontrar vulnerabilidades. Obtener gratificaciones monetarias por parte del proveedor del producto o de otra entidad.
Tratamiento de la información sobre vulnerabilidades Las formas de conseguir información sobre vulnerabilidades son las siguientes: Investigación sobre el funcionamiento de productos Investigación del funcionamiento de código malicioso que se aprovechan de vulnerabilidades A través de informes que revelan ese tipo de información.