¿Qué es una vulnerabilidad? Debilidad, amenaza, riesgo y exploit

Buena parte de la confusión en seguridad empieza con cuatro palabras que la gente usa como si significaran lo mismo: vulnerabilidad, amenaza, riesgo y exploit. Una noticia dice "se explotó una vulnerabilidad crítica" y el lector entiende que pasó un solo evento. En la práctica son cuatro cosas distintas. Separarlas te dice qué corregir primero, qué vigilar y qué puede esperar.

Este artículo ofrece definiciones de trabajo, muestra cómo se conectan las cuatro en una sola cadena y luego explica dos sistemas de nombres que vas a encontrar en todas partes. CWE nombra tipos de debilidad. CVE nombra fallas concretas en productos concretos. Las últimas secciones tratan dos ideas que sorprenden a quien recién empieza: una vulnerabilidad sin ruta alcanzable suele ser de riesgo bajo, y una configuración incorrecta cuenta como vulnerabilidad aunque nadie haya escrito un error de código.

No necesitas laboratorio para este artículo. La parte práctica es un ejercicio en papel. Si leíste antes el artículo sobre la tríada CIA, el paso de impacto de más abajo te resultará conocido.

#Cuatro palabras, cuatro funciones

Empieza por la definición oficial. El glosario del Computer Security Resource Center del NIST define una vulnerabilidad como una debilidad en un sistema de información, en sus procedimientos de seguridad, en sus controles internos o en su implementación, que podría ser explotada o activada por una fuente de amenaza. La palabra clave es "debilidad". Una vulnerabilidad es una propiedad del sistema. Existe aunque nadie la esté buscando.

#Vulnerabilidad

Una vulnerabilidad es una debilidad que podría usarse para causar daño. Algunos ejemplos:

• Un formulario web que pega lo que escribe el usuario directamente en una consulta a la base de datos. Ese tipo de debilidad es muy conocido y CWE tiene una entrada para él (más abajo lo vemos).
• Un servidor de archivos que todavía acepta un protocolo de cifrado antiguo y débil.
• Un bucket de almacenamiento que permite a cualquiera listar su contenido.
• Una versión de biblioteca de software con un error de corrupción de memoria documentado públicamente.

Una vulnerabilidad no necesita un atacante para existir. Necesita existir en el sistema, y eso es lo primero que hay que comprobar al evaluar algo.

#Amenaza

Una amenaza es una circunstancia, un actor o un evento que podría aprovechar una debilidad y causar daño. El NIST usa el término "fuente de amenaza" para referirse a la parte o al evento: un grupo criminal, un insider malintencionado, una inundación o un administrador que se equivoca en un archivo de configuración.

La diferencia con la vulnerabilidad está en la dirección. La vulnerabilidad describe lo que puede recibir una acción. La amenaza describe lo que puede actuar. La amenaza es potencial. No tiene que estar atacándote ahora mismo para importar.

#Riesgo

El riesgo combina qué tan probable es un evento dañino con qué tan grave sería. La guía NIST SP 800-30 Revisión 1, para evaluación de riesgos, trata el riesgo como una función de la probabilidad y el impacto. En términos simples, el riesgo es cuán probable es que algo ocurra, ponderado por el daño si ocurre. Es un juicio, no un cálculo preciso.

Muchos equipos dibujan una matriz con probabilidad en un eje e impacto en el otro. La matriz es una herramienta para pensar. No es una medición. Dos hallazgos con la misma puntuación de severidad pueden tener riesgos muy distintos, porque la puntuación describe la falla y el riesgo describe tu entorno.

#Exploit

Un exploit es un método, un fragmento de código o una secuencia de pasos que usa una vulnerabilidad para producir un resultado que sus diseñadores no buscaban. La palabra puede referirse a la técnica en sí o a la herramienta que la ejecuta.

Hay dos relaciones que conviene recordar. Primero, un exploit necesita una vulnerabilidad contra la que funcionar. Segundo, una vulnerabilidad no necesita un exploit público para existir. Muchas vulnerabilidades son conocidas y nunca tienen un exploit público. Otras se activan con una entrada simple que cualquiera puede probar.

#Cómo se conectan las cuatro

Las cuatro palabras describen una sola cadena. Aquí va en orden, usando un formulario de inicio de sesión genérico como ejemplo:

1. Debilidad. El formulario de inicio de sesión acepta intentos de contraseña ilimitados. No hay bloqueo ni límite de frecuencia. Esa es la vulnerabilidad.
2. Fuente de amenaza. Alguien tiene una lista de contraseñas filtradas en una brecha antigua y las reutiliza contra muchas cuentas. Esa es la amenaza.
3. Exploit. Un script corto envía miles de intentos de inicio de sesión y registra los que funcionan. Ese script es el exploit.
4. Impacto. Se toma control de una cuenta. El atacante lee los datos de ese usuario, lo que es una pérdida de confidencialidad, y puede cambiar ajustes, lo que es una pérdida de integridad.
5. Riesgo. Cuánto importa depende de dos cosas: qué tan probables son los pasos 2 y 3 en tu entorno, y qué tan grave sería el paso 4 para las cuentas afectadas. ¿El formulario es alcanzable desde internet? ¿Las cuentas usan autenticación de dos factores? ¿A qué puede llegar cada cuenta?

Puedes romper la cadena en varios puntos. Un límite de intentos elimina la debilidad. La autenticación de dos factores hace que un acierto sea mucho menos útil. Restringir el formulario a una red privada reduce el alcance de la amenaza. Cada control rompe un eslabón distinto, así que hay que saber en cuál estás trabajando.

#Cómo CWE y CVE nombran las fallas

En noticias de seguridad, avisos de fabricantes e informes de escáneres vas a ver dos identificadores constantemente. Responden preguntas distintas, y confundirlos es uno de los errores más comunes al empezar.

#CWE: el tipo de debilidad

El sitio de CWE describe CWE como una lista de debilidades comunes de software y hardware, desarrollada por la comunidad. Define una debilidad como una condición en un componente de software, firmware, hardware o servicio que, bajo ciertas circunstancias, podría contribuir a la introducción de vulnerabilidades. CWE responde a la pregunta: ¿qué tipo de error es este?

Cada entrada de CWE tiene un número. La entrada para la inyección SQL es CWE-89, que trata de la neutralización inadecuada de elementos especiales en un comando SQL. La entrada para cross-site scripting es CWE-79. Estas entradas no nombran ningún producto. Describen un patrón que aparece en muchos productos y ayudan a los desarrolladores a reconocerlo antes de publicar el código.

#CVE: la falla específica

CVE es una lista de vulnerabilidades de ciberseguridad divulgadas públicamente. Cada registro describe una falla en un producto, normalmente con las versiones afectadas y enlaces a los avisos. El identificador tiene esta forma:

CVE-AÑO-NUMERO

Un ejemplo real es CVE-2021-44228, la falla de Apache Log4j 2 que se conoció como Log4Shell. El identificador dice qué falla es. El registro dice qué producto y qué versiones se ven afectados y dónde encontrar la corrección del fabricante.

CVE responde a otra pregunta: ¿qué falla concreta, en qué producto, es esta? Un mismo tipo de CWE puede tener muchos registros CVE en productos distintos, porque el mismo tipo de error se comete una y otra vez.

#Leer los dos juntos

Al leer un registro CVE, busca el tipo de debilidad al que se asocia. Un registro asociado a CWE-89 indica que la falla es una inyección SQL, aunque el producto te resulte desconocido. Así puedes aplicar lo que sabes de la categoría a un caso nuevo. Lo inverso también ayuda: si un producto tiene un historial de un tipo de debilidad, sabes qué revisar primero.

#Por qué una vulnerabilidad sin ruta alcanzable suele ser de riesgo bajo

Supón que un servicio tiene una falla conocida, pero solo escucha en la dirección de loopback de tu laptop. Ninguna otra máquina puede conectarse a él. ¿Es una vulnerabilidad? Sí. ¿El riesgo es alto? Normalmente no, porque la probabilidad es muy baja. Nadie fuera de tu laptop llega a la falla, así que ninguna fuente de amenaza puede usarla por la red.

Esta es la idea del riesgo en acción. Menos probabilidad da menos riesgo, incluso cuando el impacto sería grave. La severidad por sí sola no decide qué corregir primero.

Pero cuidado. "Hoy no hay ruta alcanzable" es una afirmación sobre un momento concreto. Algunas cosas cambian el panorama:

• Un cambio de red, como una nueva redirección de puertos, una regla de grupo de seguridad en la nube o una ruta de VPN, puede volver alcanzable un servicio.
• Una máquina comprometida en la misma red puede llegar a servicios invisibles desde fuera.
• Un empleado engañado con un mensaje de phishing puede convertirse en el camino hacia un sistema interno.
• La propia aplicación puede exponer el servicio por otra ruta, como un proxy o una redirección.

Así que riesgo bajo no es riesgo cero, y tampoco significa ignorar la falla. La corrección normalmente puede esperar detrás de los hallazgos que sí tienen rutas alcanzables, y conviene volver a comprobar la alcanzabilidad cada vez que cambie la red.

#Por qué la configuración incorrecta cuenta como vulnerabilidad

Muchos principiantes creen que una vulnerabilidad tiene que ser un error en el código. Esa idea es demasiado estrecha. La definición del glosario del NIST incluye la "implementación" del sistema y los "controles internos", y CWE también cubre debilidades de configuración. Un ajuste que expone datos o accesos es una debilidad, aunque ninguna línea de código esté mal.

Aquí hay un ejemplo sencillo. Este bloque de nginx activa el listado de directorios para una ruta:

location /backup/ {
    autoindex on;
}

No hay código roto. Nginx hace exactamente lo que dice esta línea. Pero cualquiera que pueda llegar a esa ruta ve la lista de archivos de esa carpeta, y algunos de esos archivos podrían ser copias de seguridad que nunca debieron ser públicas. La debilidad está en la configuración, y alguien puede usarla para averiguar cosas que no debería saber.

Otras configuraciones incorrectas comunes siguen la misma lógica:

• Un bucket de almacenamiento en la nube con lectura pública cuando debería ser privado.
• Una contraseña de administrador por defecto que nunca se cambió.
• Modo de depuración activo en una aplicación de producción, que puede mostrar trazas de error a los visitantes.
• Una interfaz de administración expuesta a internet público en lugar de a una red privada.

Revisa tus propios sistemas de esta manera. Para cualquier ajuste que controle quién puede ver o cambiar algo, pregúntate si un desconocido podría usarlo. Si la respuesta es sí, tienes una vulnerabilidad, la haya escrito un desarrollador o la haya elegido un administrador.

#Práctica: clasifica cinco hallazgos en papel

No hace falta laboratorio. Toma una hoja de papel o un archivo de texto y resuelve cinco casos. Para cada uno, escribe cuatro respuestas breves: la debilidad, la fuente de amenaza probable, si hace falta un exploit para usarla y si es alcanzable desde internet o solo desde dentro de una red.

1. Una aplicación web usa una versión de biblioteca con una falla documentada públicamente. La aplicación es alcanzable desde internet.
2. El listado de directorios está activado en una ruta de copias de seguridad. El servidor solo es alcanzable desde la red de la oficina.
3. Un servicio con una falla conocida escucha solo en la dirección de loopback de una laptop.
4. Un formulario de inicio de sesión no tiene límite de frecuencia, pero todas las cuentas exigen un segundo factor.
5. Un bucket de almacenamiento en la nube está con lectura pública y, por ahora, vacío.

Para cada caso, escribe una frase que empiece con "El riesgo es" y añade la razón. Compara tus respuestas con el razonamiento de arriba. Los casos 1 y 4 dan las frases de riesgo más útiles, porque la alcanzabilidad y el segundo factor cambian la probabilidad del daño. El caso 5 es una configuración incorrecta que sigue siendo una vulnerabilidad aunque hoy no haya nada guardado en el bucket, porque los datos pueden llegar mañana.

Guarda tus respuestas. Cuando leas un aviso real más adelante, podrás aplicar las mismas cuatro preguntas.

#Errores comunes

• Usar vulnerabilidad y exploit como sinónimos. La vulnerabilidad es la debilidad. El exploit es el método que la usa.
• Tomar la puntuación de severidad de un escáner como tu riesgo. La puntuación describe la falla en general. Tu riesgo depende de la alcanzabilidad, de tus datos y de tus controles.
• Ignorar las configuraciones incorrectas porque no hay error de código. Los ajustes también pueden ser vulnerabilidades.
• Pensar que "no hay exploit conocido" significa seguro. Significa que hoy no se conoce ningún exploit público. No dice nada sobre si existe uno privado.
• Pensar que inalcanzable significa inalcanzable para siempre. Los cambios de red y las máquinas comprometidas pueden cambiar la ruta.
• Confundir un identificador CVE con un tipo de debilidad. CVE nombra una falla en un producto. CWE nombra la categoría del error.

#Cómo seguir

Lee la entrada de vulnerabilidad en el glosario del NIST y las secciones de evaluación de riesgo de NIST SP 800-30 Revisión 1. Después abre cualquier registro CVE que te interese y localiza tres cosas: el producto y las versiones afectadas, la descripción de la falla y el mapeo CWE, si aparece. Este hábito convierte una lista de identificadores en un panorama claro, y es la habilidad central para leer avisos de seguridad.

Cuando tengas firmes los cuatro términos, la siguiente pregunta es cómo se podría alcanzar una debilidad a propósito. El artículo sobre modelado de amenazas con STRIDE muestra una forma estructurada de listar amenazas contra un sistema antes de que alguien lo ataque. Usa el mismo vocabulario que acabas de aprender, así que las distinciones de arriba te van a servir allí.

Cuando leas registros CVE con regularidad, notarás que la descripción suele nombrar la condición necesaria para activar la falla. Esa condición es tu primera comprobación de alcanzabilidad. Anótala junto a la versión afectada y tu propia exposición.

#Fuentes

• Glosario NIST CSRC: vulnerability
• CWE: About CWE
• CVE: Overview
• NIST SP 800-30 Rev. 1: Guide for Conducting Risk Assessments