Tema 18
Una vulnerabilidad es una condición que permite que un sistema se comporte fuera de lo esperado en términos de seguridad. Comprender sus causas ayuda a evaluar impacto, reproducir fallos en laboratorio y proponer mitigaciones efectivas.
Una vulnerabilidad no es solo un error de programación. Es una debilidad que puede afectar confidencialidad, integridad, disponibilidad, autenticidad o control de acceso. Puede estar en código, configuración, arquitectura, permisos, diseño de procesos o lógica de negocio.
En explotación controlada, estudiar vulnerabilidades permite demostrar impacto de forma segura. En defensa, permite priorizar correcciones, diseñar mitigaciones y entender cómo un atacante podría encadenar fallas.
Este tema introduce los fundamentos necesarios antes de estudiar buffer overflow, fuzzing, crash analysis y desarrollo de pruebas de concepto en laboratorio.
Conviene distinguir tres conceptos relacionados pero diferentes.
| Concepto | Significado | Ejemplo defensivo |
|---|---|---|
| Vulnerabilidad | Debilidad que puede ser aprovechada | Validación insuficiente de entrada |
| Exploit | Método o prueba que aprovecha la debilidad | Entrada que provoca fallo reproducible |
| Impacto | Consecuencia de aprovechar la vulnerabilidad | Lectura de datos, ejecución, escalada o caída |
| Mitigación | Control que reduce probabilidad o impacto | Parche, validación, hardening o monitoreo |
La superficie de ataque es el conjunto de puntos donde un sistema recibe entradas, expone funciones o interactúa con usuarios, servicios y datos externos.
Reducir superficie implica eliminar exposición innecesaria, validar entradas y limitar permisos.
Una entrada es cualquier dato que llega desde fuera de una función, proceso o sistema. Puede provenir del usuario, red, archivo, base de datos, variable de entorno, token, cabecera o sistema externo.
La validación debe comprobar:
Estos términos suelen confundirse, pero cumplen funciones distintas.
| Acción | Propósito | Ejemplo |
|---|---|---|
| Validar | Decidir si una entrada es aceptable | Rechazar tamaño mayor al límite |
| Sanitizar | Transformar o neutralizar contenido peligroso | Escapar caracteres antes de mostrar HTML |
| Normalizar | Convertir a una forma canónica antes de evaluar | Resolver rutas relativas antes de aplicar permisos |
| Codificar salida | Adaptar datos al contexto de destino | Codificar para HTML, SQL, shell o JSON según corresponda |
Los errores de memoria aparecen cuando un programa lee, escribe, libera o ejecuta memoria de forma incorrecta. Son comunes en lenguajes de bajo nivel o componentes que gestionan memoria manualmente.
Estos errores pueden causar crashes, corrupción de datos, fuga de información o, en casos graves, control de flujo.
Muchas vulnerabilidades de memoria se comprenden mejor observando dónde ocurre el error.
| Región | Uso normal | Riesgo típico |
|---|---|---|
| Stack | Variables locales, llamadas y retornos | Corrupción de datos cercanos o dirección de retorno |
| Heap | Memoria dinámica y objetos | Use-after-free, overflow, corrupción de estructuras |
| Datos globales | Variables compartidas por el programa | Alteración persistente de estado interno |
| Memoria mapeada | Archivos, bibliotecas o regiones especiales | Lecturas indebidas o permisos incorrectos |
Un integer overflow ocurre cuando una operación numérica excede el rango del tipo de dato. En seguridad, puede provocar reservas de memoria insuficientes, cálculos de tamaño incorrectos o validaciones que se eluden.
Señales de riesgo:
Una inyección ocurre cuando datos no confiables se interpretan como parte de un comando, consulta, expresión o documento ejecutable en otro contexto.
Ejemplos defensivos:
La defensa principal es separar datos de instrucciones mediante APIs seguras, consultas parametrizadas y codificación de salida por contexto.
La deserialización convierte datos almacenados o transmitidos en objetos. Si esos datos no son confiables, pueden alterar estado, invocar lógica no prevista o cargar tipos peligrosos.
Riesgos comunes:
El control de acceso falla cuando un usuario o proceso puede realizar acciones o acceder a datos fuera de sus permisos esperados. Es una vulnerabilidad de lógica y diseño, no solo de código.
Una falla de lógica aparece cuando el sistema implementa un flujo permitido técnicamente, pero inseguro desde el punto de vista del negocio o la seguridad.
Ejemplos:
Estas vulnerabilidades suelen requerir comprensión del proceso, no solo herramientas automáticas.
Una condición de carrera ocurre cuando el resultado depende del orden o timing de operaciones concurrentes. En seguridad, puede permitir usar un recurso después de validarlo pero antes de que cambie, duplicar acciones o alterar estado en momentos críticos.
Áreas sensibles:
No todas las vulnerabilidades están en código. Una configuración débil puede exponer servicios, datos o privilegios.
Las aplicaciones dependen de bibliotecas, frameworks, contenedores, imágenes, plugins y servicios. Una vulnerabilidad en una dependencia puede afectar al sistema aunque el código propio sea correcto.
Buenas prácticas defensivas:
Reproducir una vulnerabilidad permite confirmar existencia e impacto. Debe hacerse en entorno autorizado, con datos de prueba y el menor impacto posible.
La severidad técnica debe combinarse con contexto. Una vulnerabilidad crítica en un servicio aislado de laboratorio no tiene el mismo riesgo que la misma falla expuesta a internet con datos sensibles.
| Factor | Pregunta | Impacto en prioridad |
|---|---|---|
| Exposición | Está accesible desde internet o red interna amplia | Aumenta urgencia |
| Privilegios | Requiere usuario autenticado o permisos altos | Puede reducir o cambiar prioridad |
| Impacto | Afecta datos, ejecución, disponibilidad o privilegios | Define gravedad |
| Explotabilidad | Es fácil de reproducir o requiere condiciones raras | Modula riesgo real |
| Controles existentes | Hay mitigaciones, segmentación o monitoreo | Puede reducir impacto residual |
Estas siglas ayudan a clasificar y comunicar vulnerabilidades.
Son herramientas útiles, pero no reemplazan el análisis de contexto propio. Un CVSS alto no siempre implica prioridad máxima en todos los entornos, y un CVSS medio puede ser urgente si afecta un activo crítico.
Mitigar una vulnerabilidad puede requerir más que aplicar un parche. La defensa debe reducir probabilidad, impacto y exposición.
Un reporte de vulnerabilidad debe ser claro, reproducible y responsable.
El malware puede aprovechar vulnerabilidades para entrar, elevar privilegios, moverse lateralmente o evadir controles. También puede incluir exploits como módulos separados o descargar componentes según el entorno.
Durante análisis de malware, buscar:
Comprender vulnerabilidades es esencial para evaluar riesgo real. Una falla técnica solo se vuelve relevante cuando se conecta con impacto, condiciones de explotación, exposición y controles defensivos.
En el próximo tema estudiaremos buffer overflow, control de flujo, stack, heap y condiciones de explotación, profundizando en una de las familias clásicas de vulnerabilidades de memoria.