SwagShop - HackTheBox

En este post se explicarán los pasos que se han seguido para conseguir vulnerar la seguridad de la máquina SwagShop en Hack The Box, tal y como se refleja, es un sistema Linux con un nivel de dificultad fácil.

Ilustración 1: SwagShop.

La fase de enumeración se dio comienzo realizando un escaneo del tipo SYN-SCAN. Obteniendo los siguientes resultados:

Ilustración 2: Ejecución nmap.

Ilustración 3: Resultados de nmap.

Los servicios más destacados eran SSH y Apache. Se realizaron varios intentos de conexión a través de SSH haciendo uso de contraseñas simples, pero ninguno resultó exitoso. Así que se procedió a investigar el servidor Apache.

Ilustración 4: Tienda en Magento.

Como se puede observar se trata de un eCommerce desarrollado en Magento. Dado que la dificultad de esta máquina no es muy alta, se dedujo que la clave para conseguir penetrar en el sistema pasaba primero por encontrar algún tipo de vulnerabilidad en Magento. Es por ello por lo que se aplicaron herramientas como DIRB y Nikto, para así conocer que directorios son accesibles y las posibles vulnerabilidades que puedan encontrarse.

Ilustración 5: Ejecución y resultados de Nikto.

Ilustración 6: Ejecución de DIRB.

Ilustración 7: Resultados del DIRB.

Se tenía acceso a diferentes rutas que podían ser de interés. Entre ellas estaban los directorios que contenían ficheros de configuración de Magento, con el usuario administrador y el hash de su contraseña. También se tenía acceso al panel de administración MagentoConnect Manager.

Ilustración 8: Directorios accesibles.

Ilustración 9: Fichero de configuración con el hash de la contraseña.

Ilustración 10: Panel de inicio de sesión en Magento Connect Manager.

La primera reacción cuando se obtuvo el hash de la contraseña del administrador fue intentar romperlo, se buscó en diferentes fuentes de información para saber qué tipo de hash era. Pero en un post de StackOverflow (https://stackoverflow.com/questions/13643618/how-to-decrypt-magento-enterprise-edition-password) se explicaba detalladamente como se generaba el hash de la contraseña, no era un simple hash MD5, sino que éste a su vez pasaba por diferentes métodos que lo modificaban y daban como resultado el hash que se obserba en el fichero con extensión xml. Por tanto, se desechó esta opción. La segunda opción fue buscar vulnerabilidades conocidas de Magento, pero para no ir a ciegas había que conocer la versión que estaba instalada en la máquina. Según la información encontrada, la versión de Magento se podía hallar en ficheros almacenados en el directorio pkginfo (pkginfo/Mage_All_Latest.txt):

Ilustración 11: Intentando averiguar la versión del Magento.

En estos ficheros no aparecía la versión instalada de Magento, pero volviendo a observar el panel de administración de MagentoConnect Manager se descubrió que en el footer de la página aparece la versión, concretamente la 1.9.0.0. La cuál hace referencia a la edición Community (también existe la edición Enterprise).

Encontrada la versión, las vulnerabilidades más conocidas que le afectan son CVE-2016-4010 (http://www.elladodelmal.com/2016/09/protege-tu-magento-exploitacion-del-bug.html, también existe un módulo en Metasploit) y CVE-2015-1397 (https://www.exploit-db.com/exploits/37977). Ambas se explican en: https://medium.com/magebit/magento-web-exploit-case-studies-bac57add8c0e.

Se ha de reconocer que durante la realización de las diferentes pruebas en el sistema víctima se encontraron ficheros que hacían referencia a la vulnerabilidad CVE-2015-1397, ya que había más usuarios haciendo pruebas. Se optó por intentar explotar dicha vulnerabilidad, no solo por haber encontrado pistas que revelaban la posibilidad de éxito, sino porque también se había investigado con anterioridad. Además, el sistema víctima dejaba de funcionar muy frecuentemente debido a los ataques que sufría y no existían muchas posibilidades de probar adecuadamente otras opciones.

La vulnerabilidad relatada en el CVE-2015-1397 realiza una inyección SQL en el panel de administración de Magento, creando un nuevo usuario con privilegios de administrador, denominado "forme" con contraseña "forme".

Ilustración 12: Panel de administración de Magento.

El exploit señala que la ruta del panel es "/admin/Cms_Wysiwyg/directive/index/", es correcto, solo que en este caso hay que añadir con anterioridad a ésta, "index.php", sino no se puede encontrar, quedando así: "http://10.10.10.140/index.php//admin/Cms_Wysiwyg/directive/index/. Dicha ruta junto con la dirección IP de la máquina son los datos que se deben añadir al exploit:

Ilustración 13: Introduciendo los datos necesarios para la ejecución del exploit.

Se ejecutó el exploit con éxito y se consiguió entrar al panel de administración:

Ilustración 14: Ejecución del exploit.

Ilustración 15: Acceso al panel de control del administrador.

Una vez dentro, el objetivo era penetrar en el sistema desde Magento. Se encontró este vídeo donde a mitad de este se realiza el proceso deseado: https://www.youtube.com/watch?v=rWKJP0Mb7Cg.

Los pasos son simples, primero se instala una extensión en Magento (File_System-1.0.0.tgz, procedente de https://arc.bukancoder.co/Magento-Stuff/) que permite administrar el sistema de ficheros:

Ilustración 16: Fuente desde donde se obtuvo la extensión a instalar.

Ilustración 17: Subiendo el fichero comprimido para instalar la extensión.

Ilustración 18: Correcta instalación de la extensión.

Cuando se instala correctamente se puede acceder a los ficheros de la siguiente forma:

Ilustración 19: Accediendo a la extensión instalada.

Ilustración 20: Ficheros a los que se tiene acceso.

Lo siguiente fue usar msfvenom para abrir una sesión de meterpreter en el sistema víctima. Se generó el código PHP necesario, se sustituyó por el código de uno de los ficheros PHP existentes a los que se tiene acceso desde la extensión "File System" y se ejecutó accediendo a dicho fichero desde el navegador.

Ilustración 21: Creación de una conexión TCP reversa con msfvenom.

Ilustración 22: Modificando cron.php e introduciendo el código malicioso de msfvenom.

Ilustración 23: Ejecutando el código introducido.

Mientras se ejecutaba el fichero PHP modificado (cron.php) se tenía a la máquina atacante a la escucha en el puerto 4444. Donde se inició la sesión de meterpreter:

Ilustración 24: Obtención de la flag del usuario.

Como se muestra en la imagen, obtener la primera flag del usuario sin privilegios es bastante fácil, ya que el directorio donde se encontraba no requería de permisos de administrador.

Dado que en la sesión de meterpreter no se contaba con todos los comandos disponibles, se optó por abrir una shell en la máquina víctima de la siguiente forma:

Ilustración 25: Obteniendo una shell en el sistema.

Se comprobó que no se tenía permisos para ver el contenido del fichero que almacenaba la última flag, ya que éste se encontraba bajo el directorio del administrador:

Ilustración 26: Permiso denegado para visualizar el contenido del fichero.

Esto se debía a que el usuario con el que se abría la sesión de meterpreter era el siguiente:

Ilustración 27: Usuario en la sesión de la shell.

Para solucionarlo se listaron los privilegios que poseía este usuario, ejecutando en la shell:

Ilustración 28: Privilegios de administrador que posee el usuario www.data.

La aplicación /usr/bin/vi se podía ejecutar como administrador al igual que se tenía permisos de administrador en el directorio /var/www/html/. Por tanto, se decidió crear un fichero con extensión .sh en dicho directorio, que ejecutara los comandos necesarios para obtener la última flag:

Ilustración 29: Creación del script.

Ilustración 30: Obtención de la flag del usuario administrador.

Se obtuvo la última flag y se finalizó el reto.