Evaluación de Vulnerabilidades y Kali Linux

  • Posted on: 22 September 2020
  • By: ReYDeS

Una vulnerabilidad es considerada una debilidad la cual podría ser utilizada de alguna manera para comprometer la confidencialidad, integridad, o disponibilidad de un sistema de información. En una evaluación de vulnerabilidades, la meta es crear un inventario simple de las vulnerabilidades descubiertas dentro del entorno en evaluación. Este concepto del entorno es extremadamente importante. Se debe estar seguro de permanecer dentro del alcance de la red del cliente y los objetivos requeridos. Salir del alcance de la evaluación pueden causar una interrupción del servicio, una brecha de confianza con el cliente, o una acción legal contra el profesional o el empleador.

Debido a su relativa simplicidad, una prueba de vulnerabilidades es frecuentemente completado en entornos más maduros sobre una base regular como parte de demostrar su debida diligencia. En muchos casos una herramienta automática como aquellas incluidas en las categorías “Análisis de Vulnerabilidades” y “Aplicaciones Web” en el sitio web de Kali Linux y su menú de aplicaciones, son utilizadas para descubrir sistemas en vivo en el entorno en evaluación, identificar servicios en atención, y enumerarlos para descubrir tanta información como sea posible, como el software servidor, versión, plataforma, etc.

Esta información es luego verificada por firmas conocidas de problemas o vulnerabilidades potenciales. Estas firmas están constituidas de combinaciones de puntos de datos, los cuales tienen como propósito representar problemas conocidos. Múltiples puntos de datos son utilizados, porque mientras más puntos de datos se utilicen más precisa la identificación. Existen un gran número de puntos de datos existentes, incluyendo pero no limitado a:

Versión del Sistema Operativo: Es común el software sea vulnerable sobre una versión del sistema operativo pero no a otro. Debido a esto el escáner intentará determinar tan precisamente como sea posible, cual versión del sistema operativo es hospedando la aplicación.

Nivel de Parche: Muchas veces los parches para un sistema operativo podrían ser publicados sin incrementar la información de la versión, pero esto cambia la manera en la cual responderá una vulnerabilidad, o incluso eliminan completamente la vulnerabilidad.

Arquitectura del Procesador: Muchas aplicaciones de software están disponibles para múltiples arquitecturas de procesadores, como Intel x86, Intel x64, múltiples versiones de ARM, UltraSPARC, etc. En algunos casos una vulnerabilidad podría únicamente existir sobre una arquitectura específica, con lo cual conocer esta pequeña información puede ser crítico para una firma precisa.

Versión de Software: La versión del software es uno de los elementos más básicos necesarios a ser capturados para identificar una vulnerabilidad.

Estos y muchos otros puntos de datos serán utilizados para constituir una firma como parte de una escaneo de vulnerabilidades. Como se espera, mientras más puntos de datos coincidan más precisa será la firma. Cuando se trata con coincidencias de firmas, se puede tener algunos potenciales resultados diferentes:

Verdaderos Positivos: La firma coincide y captura una vulnerabilidad verdadera. Estos resultados son aquellos necesarios a corregir, pues estos son elementos maliciosos los cuales pueden ser aprovechados por individuos para dañar a la organización (o cliente).

Falsos Positivos: La firma coincide sin embargo el problema detectado no es una vulnerabilidad verdadera. En una evaluación estas son frecuentemente consideradas ruidosas y pueden ser muy frustrantes. Nunca se desea descartar un positivo verdadero como un falso positivo sin una validación mas extensiva.

Verdaderos Negativos: La firma no coincide y no es una vulnerabilidad. Este es el escenario ideal, el verificar la vulnerabilidad no existe.

Falsos Negativos: La firma no coincide pero es una vulnerabilidad existente. Tan malo como es un falso positivo, un falso negativo es mucho peor. En este caso existe un problema, pero el escáner no tiene indicios de su existencia.

Como se puede imaginar, la precisión de las firmas es extremadamente importante para tener resultados precisos. Mientras más datos se proporcionen, mayor las probabilidades de tener resultados precisos desde una escaneo automático basado en firmas, lo cual es porque los escaneos autenticados son frecuentemente tan populares.

Con un escaneo auténticado el software para escaneo utilizará las credenciales proporcionadas para autenticarse a aquello a evaluar. Esto proporciona un nivel profundo de visibilidad dentro del entorno en evaluación de lo cual sería posible de otro modo. Por ejemplo un escaneo normal puede únicamente detectar información sobre el sistema, el cual puede ser derivado desde los servicios en atención, y la funcionalidad proporcionada. Esto puede ser algunas veces bastante información, pero no puede competir con el nivel y profundidad de datos los cuales podrían ser obtenidos si se autentica hacia el sistema, y revisar exhaustivamente todo el software instalado, parches aplicados, procesos en funcionamiento, etc. Esta amplitud de datos es útil para detectar vulnerabilidades, los cuales de otro modo no se habrían descubierto.

Un evaluación de vulnerabilidades bien realizado presenta una instantánea de potenciales problemas en una organización, y proporciona métricas para medir cambios a lo largo del tiempo. Esto es una evaluación bastante liviana, pero incluso así, muchas organizaciones regularmente realizar escaneos automáticos fuera de horarios, para evitar potenciales problemas durante el día, cuando la disponibilidad de los servicios y el ancho de banda son lo más crítico.

Un escaneo de vulnerabilidades deberá verificar muchos diferentes puntos de datos para obtener un resultado preciso. Todas estas diferentes verificaciones pueden crear una carga en el sistema en evaluación, como también consumir ancho de banda. Desafortunadamente es difícil conocer exactamente cuantos recursos se consumirán, pues esto depende del número de servicios abiertos y tipos de verificaciones los cuales podrían estar asociados con estos servicios. Este es el costo de hacer un escaneo, va a ocupar recursos del sistema. Tener una idea general de los recursos a ser consumidos y cuanta carga el sistema puede tener es importante cuando se ejecutan estas herramientas.

Cuando finaliza un escaneo de vulnerabilidades, los problemas descubiertos son típicamente enlazados con identificadores estándar de la industria, como número CVE, EDB-ID, y anuncios de proveedores. Esta información, junto con la puntuación CVSS de las vulnerabilidades, son utilizados para determinar la clasificación del riesgo. Junto con falsos negativos (y falsos positivos), estas calificaciones de riesgo asociado son problemas comunes necesario de considerar cuando se analicen los resultados del escaneo.

Debido a las herramientas automáticas utilizan una base de datos de firmas para detectar vulnerabilidades, cualquier desviación leve desde firmas conocidas puede alterar los resultados, y probablemente la validez de la vulnerabilidad percibida. Un falso positivo resalta incorrectamente una vulnerabilidad la cual no existe, mientras un falso negativo es efectivamente ciego hacia una vulnerabilidad y no lo reporta. Debido a esto, un escaner frecuentemente se dice únicamente es tan bueno como su base de reglas de firmas. Por esta razón muchos proveedores proporcionan múltiples conjuntos de firmas: uno podría ser libre para usuarios caseros y otro conjunto bastante costoso el cual es más completo, además de ser generalmente vendido hacia clientes corporativos.

Otro problema frecuentemente encontrado con los escaneos de vulnerabilidades es la validez de las calificaciones sugeridas del riesgo. Estas calificaciones de riesgo son definidos sobre bases genéricas, considerando muchos diferentes factores como el nivel de privilegio, tipo de software, y pre o post autenticación. Dependiendo del entorno estas calificaciones pueden o no ser aplicables, de tal manera estas no deben ser aceptados ciegamente. Únicamente aquellas bien versadas en los sistemas, pueden adecuadamente validar la calificación del riesgo de las vulnerabilidades

Aunque no existe un acuerdo universalmente definido sobre las puntuaciones del riesgo, la publicación especial de NIST 800-30, se recomienda como base para la evaluación de las calificaciones del riesgo, y su precisión en el entorno. NIST SP 80-30 define el verdadero riesgo de la vulnerabilidad descubierta como una combinación de probabilidad de ocurrencia e impacto potencial.

Fuentes:

https://cve.mitre.org/
https://www.first.org/cvss/
https://csrc.nist.gov/publications/sp#800-30

Sobre el Autor


Alonso Eduardo Caballero Quezada - ReYDeS
Instructor y Consultor en Hacking Ético, Forense Digital & GNU/Linux
Correo Electrónico: ReYDeS@gmail.com
Twitter: @Alonso_ReYDeS
LinkedIn: pe.linkedin.com/in/alonsocaballeroquezada
Facebook: https://www.facebook.com/alonsoreydes
Youtube: http://www.youtube.com/c/AlonsoCaballero
Resumen de mi CV: http://www.reydes.com/d/?q=node/1