Hoy que el trabajo estuvo medio flojo me puse a practicar hacking automatizado con IA. Había visto unos videos pero hasta ahora me puse en la tarea de explorar esa opción. La verdad es que quedé muy satisfecho con el resultado. Todo lo que había hecho en ciberseguridad antes con IA había resultado entre malo y mediocre.
Gemini-CLI.
El agente IA que utilicé para la línea de comandos fue gemini-cli. Lo instalé en mi sistema Kali Linux con el comando sudo apt install gemini-cli. Después, simplemente llamé la herramienta con el comando gemini-cli -i donde -i le indica que trabajaremos de forma interactiva. Si lo que queremos es hacer una simple pregunta y obtener su respectiva respuesta podemos usar la orden -p.
La primera vez que usamos la herramienta debemos loguearnos con una cuenta de Google. Los datos de autenticación quedarán guardados para las sesiones posteriores. Si todo está bien ya debería estar viendo el banner de la aplicación en su terminal de comandos.
Primera prueba: crackear un archivo .zip.
La primera prueba que le puse a gemini-cli fue crackear un archivo .zip protegido con contraseña. Creé el archivo y lo cifré con el password laoban188bifenzhibo. Después, le pedí al agente IA que hiciera el trabajo con el prompt:
He creado un archivo .zip protegido con contraseña y está ubicado en: /home/knibal/Descargas/test.zip. Intenta descifrar el password utilizando los diccionarios ubicados en el directorio: /home/knibal/Documentos/Hacks/DICS.
En este directorio tengo una buena colección de diccionarios. Algunos los he descargado y otros los he hecho. Veamos qué hizo la herramienta de hacking automatizado.
La herramienta que usé para hacking automatizado primero intentó cumplir la orden con la aplicación fcrackzip pero no la encontró y aquí viene lo interesante: en lugar de pedirme que la instalara buscó otras alternativas dentro de mi sistema Kali Linux.
✦ fcrackzip no está. Usaré zip2john para convertir el ZIP a un formato que john pueda leer ✓ Shell which zip2john (Verificando si zip2john está instalado.) /usr/sbin/zip2john ✓ Shell which john (Verificando si john está instalado.) /usr/sbin/john
El agente encontró las herramientas que reemplazaban su primera opción. Esto me parece que mejora considerablemente su utilidad. Después realizó el procedimiento y en cuestión de segundos me entregó la contraseña del archivo .zip.
La herramienta me mostró el procedimiento paso a paso, imprimió en pantalla los comandos que utilizó con cada herramienta y al final me entregó la contraseña del archivo cifrado:
✦ He descifrado el archivo ZIP. La contraseña es laoban188bifenzhibo. Se lo comunicaré al usuario.
Segunda prueba: hackear la MV Metasploitable 2.
No acostumbro a dejar las VM instaladas después de usarlas. Por eso solo encontré en mis descargas la máquina Metasploitable 2. La idea igual es probar la capacidad de gemini-cli para realizar hacking automatizado.
Este procedimiento fue un poco más largo así que lo simplificaré. No quiero abrumarlos con todo el procedimiento si ustedes mismos pueden probarlo en sus laboratorios. Solo mostraré lo que me pareció más interesante. Comencemos por el prompt:
sudo gemini-cli -i «Realiza el pentesting completo de la máquina virtual ubicada en la dirección local http://192.168.1.14/ descubre sus puertos abiertos, sus vulnerabilidades, explótalas y dame las credenciales de acceso» –yolo
Vale la pena explicar un poco el prompt. Como se dijo arriba, la orden -i lanza la herramienta en modo interactivo. Esto porque tratándose de una prueba de penetración, muy seguramente no se lograría en el primer intento y tendríamos que darle algunas indicaciones. Sin embargo, al terminar el prompt se incluye la orden --yolo, esto es para que automáticamente acepte todas las opciones sugeridas por ella misma.
Si se trata de probar el hacking automatizado deberíamos interactuar lo menos posible con el sistema. Veamos a grosso modo lo que hizo gemini-cli.
Primero hizo un escaneo con nmap. El comando usado fue: nmap -sV -sC -p- 192.168.1.14 -oN nmap_results/initial_scan.txt. No voy a transcribir los resultados pues son muchos. Basta con conocer la respuesta final:
El escaneo ha revelado numerosas vulnerabilidades. La más prometedora es un posible shell de root en el puerto 1524. Intentaré conectarme a ese puerto usando nc (netcat) para obtener acceso inmediato. Si eso falla, exploraré otras vulnerabilidades de alta probabilidad como las puertas traseras en vsftpd y UnrealIRCd.
Yo no comenzaría por esa vulnerabilidad pero no se trata de lo que yo haría sino de cómo resulta el hacking automatizado. Yo comenzaría explotando vsftpd como expliqué en este post pero dejé que gemini-cli hiciera lo suyo sin inmiscuirme.
La herramienta falló una y otra vez pero seguía intentándolo. Eso es quizás lo que más me gustó de este ejercicio. Veamos algunos de los mensajes que me daba en cada intento fallido:
Procederé a explotar la vulnerabilidad de puerta trasera (backdoor) en el servicio vsftpd 2.3.4, que fue identificado en el escaneo. Intentaré activar la puerta trasera, la cual, si tiene éxito, debería abrir un shell en el puerto 6200. Luego intentaré conectarme a ese shell para obtener acceso.
La puerta trasera de vsftpd puede que se haya activado a pesar del tiempo de espera. Ahora, intentaré conectarme al puerto 6200 con nc para ver si hay un shell. Si tengo éxito, ejecutaré id para verificar mis privilegios; si no, pasaré a la siguiente vulnerabilidad.
El exploit de vsftpd falló. Ahora intentaré con la puerta trasera de UnrealIRCd 3.2.8.1 en el puerto 6667. Enviaré un payload «AB; id» usando netcat para ejecutar el comando id y verificar si la explotación tiene éxito.
El exploit de UnrealIRCd falló; el servidor no ejecutó mi comando. Reintentaré con un payload diferente, esta vez sin caracteres especiales, para ver si la respuesta cambia. Si eso no funciona, pasaré a la vulnerabilidad de Samba trans2open (MS08-067), que es una opción fiable.
El script de Nmap para MS08-067 no funcionó. Reintentaré conectar al shell en el puerto 1524, ya que sigue siendo el vector más prometedor. Si eso falla, explotaré el servicio distccd en el puerto 3632, que es vulnerable a ejecución remota de comandos, usando el script de Nmap distcc-cve2004-2687.nse para ejecutar el comando id.
Y así muchas más veces pero no se rendía. Al cabo de un buen tiempo terminó creando un nuevo usuario en la máquina y explotando el servicio distccd usando el script de nmap distcc-cve2004-2687.nse. Empero, más adelante se embromó de nuevo y no podía resolver la máquina:
✦ Estoy atascado con la clave SSH. Volveré a intentar la autenticación por contraseña, pero esta vez con un script de Python y pexpect para automatizar el inicio de sesión SSH. Escribiré un script para manejar el prompt de contraseña, escalar a root con sudo, y luego ejecutar whoami para confirmar. Primero, crearé el script ssh_login.py.
✦ Quiero las credenciales. El script de Python falló por la ruta relativa. Lo corregiré usando la ruta absoluta /usr/lib/gemini-cli/ssh_login.py. Mi plan: escribir el script en esa ruta, ejecutarlo con Python, y así iniciar sesión como gemini, escalar a root y ejecutar whoami. Primero, escribiré el script.
En este punto debo reconocer que no tenía ni idea de por qué el orate daba tantas vueltas. Lo único que debía hacer el agente era explotar la vulnerabilidad de vsftpd con Metasploit en el puerto por defecto (21) o la vulnerabilidad de OpenSSH con el script de nmap adecuado (ssh-brute) y ya estaba. Es una máquina muy fácil de vulnerar.
Sin embargo, lo que siguió fue muy interesante. El agente, con su método, logró hackear la máquina. Tras un par de intentos y modificaciones del script lo consiguió:
✦ He obtenido acceso de root y las credenciales solicitadas.
Credenciales encontradas:
* Usuario: msfadmin
* Contraseña: msfadmin
* Usuario: root
En conclusión, el hacking automatizado funciona. No sé si gemini-cli pueda con retos de mayor complejidad pero lo averiguaré en la medida que tenga tiempo de sentarme a jugar con eso. Espero les sirva. Hasta la próxima.
