Cuando te encuentras en un proyecto de
Ethical Hacking y llegas a una
máquina GNU/Linux no fortificada que has tomado
explotando alguna vulnerabilidad y tienes el control de ella, puedes necesitar elevar privilegios para lograr un mayor grado de control en la red o en la propia máquina. Ya hemos visto en otras ocasiones herramientas que ayudan a encontrar esos fallos de seguridad que la máquina no tiene solventada, como, por ejemplo,
AutoLocal Privilege para
encontrar bugs de máquinas GNU/Linux,
Windows Exploit Suggester, si el entorno es un sistema
Microsoft Windows,
OSB-Rastreator para encontrar bugs en funciones inseguras de repositorios de código abierto o, directamente, conocer la vulnerabilidad que afecta al sistema, el temido, en su día,
dirtyCOW.
|
Figura 1: KernelPop: Si haces pop...puede que tu Linux sea vulnerable |
Hoy hablaremos de una herramienta que permite ahondar y verificar las vulnerabilidades que puede presentar un sistema, con las que conseguiríamos elevar privilegio. La herramienta se llama
Kernelpop y está disponible en su GitHub para su descarga. A día de hoy, la herramienta solo permite comprobar
vulnerabilidades en entornos GNU/Linux, aunque viendo algunas carpetas puede que en el futuro ayude a detectar vulnerabilidades en sistemas
macOS y
MS Windows.
|
Figura 2: |
Uno de los requisitos que tiene la herramienta es que se necesita
Python3. Podemos decir que
Kernelpop es un pequeño
framework que permite enumerar las potenciales y, en algunos casos, las reales vulnerabilidades que tiene un
kernel. Como se mencionó anteriormente, la herramienta encuentra
bugs en entornos
GNU/Linux, pero se prevé que pueda encontrar vulnerabilidades en
macOS y
Windows. La herramienta propone varios modos de ejecución, los cuales se muestran a continuación:
• Por defecto.
• Modo de enumeración por fuerza bruta.
• Input mode.
El modo por defecto es ejecutado con
Python kernelpop.py. Este modo compara la información recopilada del sistema de la máquina con los
exploits para
kernel disponibles hasta la fecha para esa versión concreta. Como se puede ver en la imagen, lo primero es identificar la versión exacta del
kernel. Se identifican los
CVE que afectan a esa versión del
kernel y se confirma si existe la vulnerabilidad.
|
Figura 3: versión del kernel y exploits disponibles para ella |
¿Cómo o dónde está el código que detecta la vulnerabilidad?
Como se puede ver en la siguiente imagen, dentro del repositorio de
kernelpop se encuentra una carpeta denominada
exploits. Esta carpeta es la que consta de un módulo llamado
exploit.py con el que se invoca a los ficheros
Python que implementan la detección de los diferentes
CVE. Sistema interesante, sin duda.
|
Figura 4: Detección de exploits |
El modo
brute-enumeration permite realizar las mismas comprobaciones, pero detecta además los prerrequisitos del sistema, es decir, si el sistema operativo está configurado en un estado vulnerable.
|
Figura 5: Mote brute-enumeraton |
El modo
input, permite introducir un ‘
uname –a’ que nos interese evaluar. Por ejemplo, podemos ejecutar la instrucción
kernelpop.py –i y nos solicitarán que introduzcamos la información para su evaluación. En la siguiente imagen, se muestra como, primero obtenemos el
uname –a que nos interese, y después, se lo pasamos a la herramienta en modo
input. Los resultados obtenidos son similares a las pruebas anteriores, porque el
uname –a es el de la máquina, pero si quisiéramos evaluar otro obtendríamos los resultados.
|
Figura 6: |
Una buena herramienta para llevar en la mochila y tener en cuenta en el proceso de
post-explotación. La herramienta está muy actualizada, ya que los últimos
commits constan de hace menos de una semana. Proyecto interesante y que seguiremos de cerca. Además, propone una forma sencilla de aumentar el número de módulos para la detección de vulnerabilidades locales.
1 comentario:
Herramienta interesante, pero me ha sorprendido que tuviera la información o DB de los exploits de manera local.
No sé si esto esta configurado así de manera voluntaria o no.
Desde la ignoracia se puede llegar a pensar que es más lógico realizar una consulta a una base de datos / api actualizada en tiempo real, no sé si, https://www.exploit-db.com/browse/ o https://www.cvedetails.com/product/47/Linux-Linux-Kernel.html?vendor_id=33 dan esa posibilidad.
¿Lo tiene en local de manera voluntaria tal vez para no realizar consultas al exterior y no levantar sospechas? ...
Desde fuera parece que se podría añadir una especie de funcionalidad para que añadiera de manera automática nueva información a la carpeta de exploit (ingnoro si es que lo hace ya).
Saludos
Publicar un comentario