No hace tanto tiempo que estoy en TI, pero recientemente me dejé llevar por el tema de la ciberseguridad. La profesión de pentester es especialmente interesante. Mientras navegaba, vi un artículo interesante "Cómo una base de datos mal configurada nos permitió poseer una nube completa de más de 25K hosts" de Security Shenanigans. Traducción de ambas partes y llamar su atención.
Introducción
En este artículo, aprenderá cómo logramos realizar una conexión sqlmap directa a la base de datos utilizando BMC / IPMI para comprometer a un cliente grande.
Antecedentes
Hace un par de años, nuestro equipo recibió una tarea: realizar una prueba de penetración de la infraestructura en la red Openstack. Consistía en aproximadamente 2000 servidores físicos que alojaban más de 25 000 máquinas virtuales. Comenzamos nuestro trabajo en una subred pequeña con una limitación en la cantidad de tráfico saliente. Después de un análisis rápido, Nmap no pudo encontrar ninguna vulnerabilidad obvia que pudiera explotarse. Por lo tanto, comenzamos a estudiar los servicios disponibles para nosotros. Entre ellos, encontramos un servidor PostgreSQL indefenso alojado en un servidor de desarrollo. Después de crear una lista de palabras personalizada con varias derivaciones del nombre de la empresa, pudimos colamos en el sistema utilizando datos relativamente simples de la cuenta. El nombre de usuario era Postgres y la contraseña era "admin".
A continuación, decidimos usarsqlmap . Esta herramienta fue construida para usar inyección SQL, pero también puede brindarle varias opciones al establecer una conexión directa a la base de datos (cuando tenga sus credenciales). Una de estas opciones es lanzar un shell de comandos contra la base de datos en producción.
Después de probar el shell, decidimos construir una carga útil personalizada (carga útil) para obtener una conexión inversa. Esto permitiría trabajar con mayor comodidad.
Creamos la carga útil usando msfvenom. La carga útil en este caso fue un shell TCP inverso para una máquina Linux x64. En la imagen anterior, puede ver que necesitábamos elegir la arquitectura de la base de datos.
Recolectando una carga útil con msfvenom
La ventaja de esta carga útil es que se puede usar para volver a conectarse usando Netcat simple. La mayoría de las otras cargas útiles requieren algo como Metasploit (elija exploit / multi / handler) para las mismas tareas.
Después de ejecutar la carga útil con el contenedor sqlmap, obtuvimos nuestra conexión con el servidor.
Lanzar una carga útil Volver a conectarse
y probar el acceso
Usar dispositivos BMC
Siempre que ejecute una prueba de penetración de la infraestructura y comprometa una máquina en un nuevo segmento de red, debe volver a escanear para ver si surge algo nuevo. Esta base de datos nos permitió conectarnos a la red en la nube de la empresa, incluidas la mayoría de máquinas virtuales y hosts. Quedamos muy contentos con los resultados del nuevo escaneo, ya que encontramos varios dispositivos BMC.
Uno de los tres dispositivos BMC
El BMC (controlador de gestión de placa base, procesador de servicio) es un dispositivo integrado preferencial conectado al servidor principal que proporciona supervisión y control fuera de banda. Funciona independientemente de la CPU, BIOS y sistema operativo. Los errores que se produzcan en cualquiera de estos elementos no pueden afectar su funcionamiento. El microcontrolador tiene su propio procesador, memoria, interfaz de red, por lo que está disponible incluso si el servidor está apagado. Todos los principales proveedores de equipos tienen BMC específicos para sus productos:
- Dell DRAC
- IBM IMM
- HP iLO
- Supermicro IPMI
Otro término con el que debe familiarizarse, IPMI (Interfaz de administración de plataforma inteligente) es básicamente el protocolo que usa para comunicarse con estos dispositivos. Su propósito es monitorear y administrar el hardware del servidor, independientemente del sistema operativo, incluso cuando el servidor está apagado, pero conectado a una fuente de alimentación.
Digamos que IPMI es, con mucho, uno de los protocolos más inseguros que puede encontrar. Para darle una idea, IPMI 2.0 está diseñado de tal manera que puede solicitar directamente un hash personalizado del servidor durante el paso de autenticación. Existe otra vulnerabilidad cuando solicita autorización en modo "cifrado 0", lo que le permitirá iniciar sesión con cualquier contraseña.
Los
dispositivos BMC de arquitectura de bloque de IPMI que puede encontrar generalmente están mal protegidos, ya que son un tipo de dispositivo que se configura una vez, durante la fase de ensamblaje del centro de datos, y luego se usa solo cuando el servidor no está disponible por medios convencionales.
Pudimos autenticarnos fácilmente en algunos dispositivos que tenían habilitado el cifrado 0 .
Aquí puede ver cómo nos registramos con una contraseña aleatoria. Preste atención a la parte "-C 0".
Iniciar sesión correctamente en el dispositivo con una contraseña aleatoria
Información de red para el dispositivo
Incluso si el cifrado 0 no está habilitado en algunos dispositivos, aún tiene otras formas de iniciar sesión. Los dos más famosos están usando credenciales predeterminadas (que los administradores de sistemas generalmente no intentan cambiar) o explotando una vulnerabilidad de divulgación de hash (y luego rompiendo los hash). Esto último tuvo que hacerse para la mayoría de los dispositivos.
Pares banales de nombre de usuario / contraseña predeterminados para la mayoría de los usuarios
Una lista de palabras que contienen hash de usuarios que solicitamos al servidor
Expandiendo hashes personalizados usando metasploit
Inmediatamente obtenemos datos sobre hashes típicos
Después de revisar todos los hashes, comenzamos a descifrarlos.
Hackear los primeros hashes
En un par de minutos obtuvimos acceso a aproximadamente 600 BMC.
609 hashes descifrados con éxito
Hubo un par de dispositivos HP ILO que no pudimos descifrar. Afortunadamente para nosotros, HP iLO 4 1.00 a 2.50 también tiene un desvío de autenticación. Esto le permite crear una cuenta de administrador a través de un desbordamiento de búfer en el encabezado de la conexión HTTP procesada por el servidor web. El exploit usa esto para obtener acceso privilegiado al resto de la API, que a su vez le da permiso para crear cuentas.
Utilizando CVE-2017-12542
Después de estos pasos, obtuvimos el control total sobre el 90% de los dispositivos BMC de la compañía. Si ha leído sobre los dispositivos BMC, ahora sabe que le permiten:
- Monitor
- Reiniciar
- Reinstalar
- KVM (virtualizar)
dispositivos conectados. Esto es genial y todo, pero solo simulan el acceso físico al servidor, aún necesita ingresar. Sí, puedes perder el tiempo apagando los dispositivos, pero pensamos que no era suficiente, así que seguimos investigando.
Una de las formas más comunes de piratear hardware que tiene una dirección física es reiniciarlo y controlar la ejecución automática del shell raíz. Puede hacer esto en Unix, Mac y Windows.
La dificultad con este enfoque es que cada servidor normalmente aloja alrededor de 2000 hosts virtuales. Entonces, necesitábamos encontrar un servidor sin usar. El plan era apagarlo (o simplemente iniciarlo si ya estaba apagado) y editar la ejecución automática para darnos acceso de root. Después de eso, queríamos mirar la configuración para encontrar errores / cargas útiles que nos permitieran comprometer otros servidores también.
Openstack le permite consultar la infraestructura local y consultar parámetros específicos. Uno de ellos es el estado de la máquina virtual, que en el caso de esta empresa local se definió como la disponibilidad de la VM (lista blanca / negra para recibir tráfico) + estado operativo (iniciado / deshabilitado).
Necesitábamos encontrar un servidor en la lista negra (el estado de funcionamiento no importaba) y encontramos uno que no funcionaba debido a problemas con el disco. Afortunadamente, pudimos arrancar, pero algunas partes del sistema de archivos terminaron en modo de solo lectura.
Solicitud de Openstack para piratear un servidor adecuado
Una vez que lo encontramos, iniciamos sesión con las credenciales que encontramos anteriormente.
Utilización de los accesos obtenidos anteriormente
Acceso a la interfaz KVM La
interfaz KVM simula una conexión directa al servidor a través del BMC. En el arranque, debe editar la carga automática de Grub y agregar
ro init = / bin / basha la línea apropiada para arrancar en el shell raíz... Por lo general, se usa el indicador de lectura / escritura (rw), pero tuvimos que usar el indicador de solo lectura (ro) para evitar cualquier problema con el disco fallido.
Editar el menú de grub
Después de iniciar sesión, examinamos las interfaces de red para probar la conectividad con el servidor. Como puede ver, ifconfig muestra más de 10 interfaces activas.
Después de tomarnos un tiempo para analizar la estructura de la red y entender dónde estamos, comenzamos a estudiar el servidor.
Después de un par de minutos, encontramos un término medio con bash_history (una de las mejores fuentes de información valiosa que puede encontrar en una máquina Linux)
credenciales novadb en bash_history
Para aquellos que no estén familiarizados con la arquitectura Openstack, Nova es una base de datos de administración que almacena información administrativa para toda la nube, como certificados, cuotas, nombres de instancias, metadatos y mucha más información importante .
Verificación de credenciales
Después de iniciar sesión, verificamos el acceso de administrador mediante grant_MySQL.
Una vez hecho esto, podemos ver la estructura interna de NovaDB.
Tablas en la base de datos de Novadb
Mirando la información sobre la VM, pudimos ver alrededor de 34 mil dispositivos. Sin embargo, alrededor de un tercio de ellos no estaban disponibles o no funcionaban. La cantidad exacta se puede ver en la entrada de línea float_ips.
Permítanme explicarles por qué estos datos de la base de datos son tan importantes.
Si desea cerrar toda la empresa, puede cerrar cada servidor virtual a través de la interfaz BMC. No funcionarán hasta que los administradores de sistemas vuelvan a encender las cosas.
Puede escribir su propio malware para infectar todos los servidores, pero la implementación masiva a través de canales BMC no es fácil (recuerde que tuvimos que iniciar un servidor no utilizado para editar la ejecución automática de Grub antes de acceder a él).
Sin embargo, con acceso a NovaDB, simplemente puede corromper la base de datos y todo el entorno de la nube dejará de funcionar. Incluso suponiendo que el administrador del sistema fuera lo suficientemente inteligente como para echar un vistazo rápido a la base de datos, es mucho más difícil solucionar problemas de una base de datos dañada que de una faltante.
Además, el administrador del sistema puede darse cuenta de que algo está mal y simplemente sobrescribir todo con la copia de seguridad más reciente, ¿verdad? También lo pensamos. Es por eso que seguimos adelante y comprometimos las copias de seguridad.
Al principio intentamos consultar la base de datos principal con algo como
SELECT * FROM information_schema.PROCESSLIST AS p WHERE p.COMMAND = 'Binlog Dump'; , pero la empresa usó su propia solución de respaldo que se ejecutó de manera irregular y no usó un esquema maestro / esclavo. Así que continuamos escaneando las subredes vecinas, solo para encontrar las bases de datos de respaldo que se ejecutan en el mismo puerto que el principal.
Cómo logramos encontrar las copias de seguridad
Verificamos la posibilidad de usar las credenciales existentes y, por supuesto, surgieron.
Verificación del acceso a una copia de seguridad
Con nuestras propias copias de seguridad, pudimos demostrar el compromiso total de la infraestructura de virtualización, así como una forma de finalizar las operaciones en pocos minutos.
Siempre me gusta finalizar una revisión / informe escribiendo posibles soluciones para los problemas encontrados. Además, hubo muchos de ellos, por ejemplo:
- Reutilizando credenciales
- No hay segmentación de red
- Contraseñas banales
- Estructura de respaldo insegura
- Firmware desactualizado
Un problema crítico que no fue fácil de solucionar fueron las fallas en el protocolo IPMI.
La solución más exitosa sería colocar los servidores habilitados para BMC en un segmento de red diferente con una lista limitada y controlada de direcciones IP. Esto es lo que hizo esta empresa al final.
Espero que hayas disfrutado de nuestra historia. Tanto como nos hemos divertido aprendiendo este tema.