Documentación<Anterior | Contenido | Siguiente>
11.2. Tipos de evaluaciones
Ahora que se ha asegurado de que su entorno Kali está listo, el siguiente paso es definir exactamente qué tipo de evaluación está realizando. En el nivel más alto, podemos describir cuatro tipos de evaluaciones: a evaluación de vulnerabilidad, prueba de cumplimiento, prueba de penetración tradicional, y una evaluación de la aplicación. Un compromiso puede involucrar varios elementos de cada tipo de evaluación, pero vale la pena describirlos con cierto detalle y explicar su relevancia para la compilación y el entorno de Kali Linux.
Antes de profundizar en los diferentes tipos de evaluaciones, es importante notar primero la diferencia entre una vulnerabilidad y un exploit.
A vulnerabilidad se define como una falla que, cuando se aprovecha, compromete la confidencialidad, integridad o disponibilidad de un sistema de información. Hay muchos tipos diferentes de vulnerabilidades que se pueden encontrar, que incluyen:
• Inclusión de archivos: vulnerabilidades de inclusión de archivos1 en aplicaciones web te permiten incluir el contenido de un archivo local o remoto en el cálculo de un programa. Por ejemplo, una aplicación web puede tener una función de "Mensaje del día" que lee el contenido de un archivo y lo incluye en la página web para mostrárselo al usuario. Cuando este tipo de función se programa incorrectamente, puede permitir que un atacante modifique su solicitud web para obligar al sitio a incluir el contenido de un archivo de su elección.
• Inyección SQL: una inyección SQL2 El ataque es aquel en el que se omiten las rutinas de validación de entrada para el programa, lo que permite que un atacante proporcione comandos SQL para que se ejecute el programa objetivo. Esta es una forma de ejecución de comandos que puede provocar problemas de seguridad potenciales.
• Desbordamiento de búfer: un desbordamiento de búfer3 es una vulnerabilidad que pasa por alto las rutinas de validación de entrada para escribir datos en la memoria adyacente de un búfer. En algunos casos, esa ubicación de la memoria adyacente puede ser crítica para el funcionamiento del programa objetivo y se puede obtener el control de la ejecución del código mediante la manipulación cuidadosa de los datos de la memoria sobrescritos.
• Condiciones de carrera: una condición de carrera4 es una vulnerabilidad que aprovecha las dependencias de tiempo en un programa. En algunos casos, el flujo de trabajo de un programa depende de que ocurra una secuencia específica de eventos. Si puede alterar esta secuencia de eventos, eso puede conducir a una vulnerabilidad.
An explotar, por otro lado, es un software que, cuando se utiliza, se aprovecha de una vulnerabilidad específica, aunque no todas las vulnerabilidades son explotables. Dado que un exploit debe cambiar un proceso en ejecución, obligándolo a realizar una acción no intencionada, la creación de un exploit puede ser compleja. Además, hay una serie de tecnologías anti-exploit en plataformas informáticas modernas que han sido
1https://en.wikipedia.org/wiki/File_inclusion_vulnerability 2https://en.wikipedia.org/wiki/SQL_injection 3https://en.wikipedia.org/wiki/Buffer_overflow 4https://en.wikipedia.org/wiki/Race_condition
diseñado para dificultar la explotación de vulnerabilidades, como la prevención de ejecución de datos5 (DEP) y distribución aleatoria del diseño del espacio de direcciones6 (ASLR). Sin embargo, el hecho de que no exista un exploit de dominio público para una vulnerabilidad específica no significa que no exista (o que no se pueda crear). Por ejemplo, muchas organizaciones venden exploits comercializados que nunca se hacen públicos, por lo que todas las vulnerabilidades deben tratarse como potencialmente explotables.