🐧Linux - Enumeración del entorno
La enumeración es la clave para la escalada de privilegios. Existen varios scripts auxiliares (como LinPEAS y LinEnum) que ayudan con la enumeración. Sin embargo, también es importante comprender qué información buscar y poder realizar la enumeración manualmente. Cuando obtenga acceso inicial al host a través del shell, es importante verificar varios detalles clave.
Versión del S.O
: Conocer la distribución (Ubuntu, Debian, FreeBSD, Fedora, SUSE, Red Hat, CentOS, etc.) le dará una idea de los tipos de herramientas que pueden estar disponibles. Esto también identificará la versión del sistema operativo para la que puede haber exploits públicos disponibles.
Versión del Kernel
: Al igual que con la versión del sistema operativo, puede haber exploits públicos que tengan como objetivo una vulnerabilidad en una versión específica del kernel. Los exploits del kernel pueden provocar inestabilidad del sistema o incluso un bloqueo total. Tenga cuidado al ejecutarlos en cualquier sistema de producción y asegúrese de comprender completamente el exploit y las posibles ramificaciones antes de ejecutar uno.
Servicios corriendo
: Es importante saber qué servicios se están ejecutando en el host, especialmente aquellos que se ejecutan como root. Un servicio mal configurado o vulnerable que se ejecute como root puede ser una victoria fácil para la escalada de privilegios. Se han descubierto fallas en muchos servicios comunes como Nagios, Exim, Samba, ProFTPd, etc. Existen PoC de explotación pública para muchos de ellos, como CVE-2016-9566, una falla de escalada de privilegios local en Nagios Core < 4.2.4.
Adquirir conciencia situacional
Digamos que acabamos de obtener acceso a un host Linux aprovechando una vulnerabilidad de carga de archivos sin restricciones durante una prueba de penetración externa. Después de establecer nuestro shell inverso (y, idealmente, algún tipo de persistencia), deberíamos comenzar por recopilar algunos conceptos básicos sobre el sistema con el que estamos trabajando.
Primero, responderemos la pregunta fundamental: ¿Con qué sistema operativo estamos tratando? Si aterrizamos en un host CentOS o Red Hat Enterprise Linux, nuestra enumeración probablemente sería ligeramente diferente que si aterrizamos en un host basado en Debian como Ubuntu. Si aterrizamos en un host como FreeBSD, Solaris o algo más oscuro como el sistema operativo propietario HP HP-UX o el sistema operativo IBM AIX, los comandos con los que trabajaríamos probablemente serán diferentes. Aunque los comandos pueden ser diferentes, e incluso puede que necesitemos buscar una referencia de comandos en algunos casos, los principios son los mismos. Para nuestros propósitos, comenzaremos con un objetivo Ubuntu para cubrir tácticas y técnicas generales. Una vez que aprendamos los conceptos básicos y los combinemos con una nueva forma de pensar y las etapas del proceso de prueba de penetración, no debería importar qué tipo de sistema Linux elijamos porque tendremos un proceso completo y repetible.
Existen muchas hojas de trucos que ayudan a enumerar sistemas Linux y algunos datos que nos interesan tendrán dos o más formas de obtenerse. En este módulo, cubriremos una metodología que probablemente se pueda usar para la mayoría de los sistemas Linux que encontramos en el mundo real. Dicho esto, asegúrese de comprender qué hacen los comandos y cómo modificarlos o encontrar la información que necesita de una manera diferente si un comando en particular no funciona. Desafíese durante este módulo para probar varias formas de practicar su metodología y lo que funcione mejor para usted. Cualquiera puede volver a escribir comandos de una hoja de trucos, pero una comprensión profunda de lo que está buscando y cómo obtenerlo nos ayudará a tener éxito en cualquier entorno.
Normalmente necesitaremos ejecutar algunos comandos básicos para orientarnos:
whoami
: ¿Con qué usuario estamos corriendo?id
: ¿A qué grupos pertenece nuestro usuario?hostname
: ¿Cómo se llama el servidor? ¿Podemos deducir algo de la convención de nombres?ifconfig
oip -a
: ¿en qué subred aterrizamos?, ¿el host tiene NIC adicionales en otras subredes?sudo -l
: ¿Puede nuestro usuario ejecutar cualquier cosa con sudo (como otro usuario como root) sin necesidad de una contraseña? A veces, esta puede ser la forma más fácil de hacerlo y podemos hacer algo comosudo su
para ingresar directamente a un shell de root.
Incluir capturas de pantalla de la información anterior puede resultar útil en un informe de cliente para proporcionar evidencia de una ejecución de código remoto (RCE) exitosa y para identificar claramente el sistema afectado. Ahora, pasemos a nuestra enumeración más detallada, paso a paso.
Comenzaremos comprobando con qué sistema operativo y versión estamos tratando.
Podemos ver que el objetivo está ejecutando Ubuntu 20.04.4 LTS ("Focal Fossa") . Sea cual sea la versión que encontremos, es importante ver si estamos tratando con algo desactualizado o mantenido. Ubuntu publica su ciclo de lanzamiento y, a partir de esto, podemos ver que "Focal Fossa" no llega al final de su vida útil hasta abril de 2030. A partir de esta información, podemos suponer que no encontraremos una vulnerabilidad de kernel conocida porque el cliente ha estado manteniendo su activo con conexión a Internet parcheado, pero de todos modos buscaremos.
A continuación, queremos comprobar la PATH de nuestro usuario actual, que es donde el sistema Linux busca cada vez que se ejecuta un comando para encontrar archivos ejecutables que coincidan con el nombre de lo que escribimos, es decir, que id
en este sistema se encuentra en /usr/bin/id
. Como veremos más adelante en este módulo, si la variable PATH de un usuario de destino está mal configurada, es posible que podamos aprovecharla para aumentar los privilegios. Por ahora, la anotaremos y la agregaremos a nuestra herramienta de toma de notas preferida.
También podemos consultar todas las variables de entorno que están configuradas para nuestro usuario actual. Puede que tengamos suerte y encontremos algo confidencial, como una contraseña. Lo anotaremos y seguiremos adelante.
A continuación, anotemos la versión del kernel. Podemos realizar algunas búsquedas para ver si el objetivo está ejecutando un kernel vulnerable (que aprovecharemos más adelante en el módulo) que tenga alguna prueba de concepto de explotación pública conocida. Podemos hacer esto de varias maneras, otra forma sería con cat /proc/version
o usar el comando uname -a
.
A continuación, podemos recopilar información adicional sobre el propio host, como el tipo/versión de la CPU:
¿Qué shells de inicio de sesión existen en el servidor? Anótelos y resalte que tanto Tmux como Screen están disponibles para nosotros.
También debemos comprobar si existen defensas y podemos enumerar cualquier información sobre ellas. Algunas cosas que debemos buscar incluyen:
A menudo no tendremos los privilegios para enumerar las configuraciones de estas protecciones, pero saber cuáles están implementadas, si las hay, puede ayudarnos a no perder tiempo en ciertas tareas.
A continuación, podemos echar un vistazo a las unidades y a los recursos compartidos del sistema. En primer lugar, podemos utilizar el comando lsblk
para enumerar información sobre los dispositivos de bloque del sistema (discos duros, unidades USB, unidades ópticas, etc.). Si descubrimos y podemos montar una unidad adicional o un sistema de archivos desmontado, es posible que encontremos archivos confidenciales, contraseñas o copias de seguridad que se puedan aprovechar para aumentar los privilegios.
El comando lpstat
se puede utilizar para buscar información sobre cualquier impresora conectada al sistema. Si hay trabajos de impresión activos o en cola, ¿podemos obtener acceso a algún tipo de información confidencial?
También deberíamos comprobar si hay unidades montadas y desmontadas. ¿Podemos montar una unidad desmontada y obtener acceso a datos confidenciales? ¿Podemos encontrar cualquier tipo de credenciales en fstab
las unidades montadas buscando palabras comunes como contraseña, nombre de usuario, credenciales, etc. /etc/fstab
?
Consulte la tabla de enrutamiento escribiendo route
o netstat -rn
. Aquí podemos ver qué otras redes están disponibles a través de qué interfaz.
En un entorno de dominio, definitivamente querremos verificar /etc/resolv.conf
para ver si el host está configurado para usar DNS interno; es posible que podamos usar esto como punto de partida para consultar el entorno de Active Directory.
También querremos verificar la tabla arp para ver con qué otros hosts se ha estado comunicando el objetivo.
La enumeración del entorno también incluye información sobre los usuarios que existen en el sistema de destino. Esto se debe a que, durante la instalación de aplicaciones y servicios, los usuarios individuales suelen configurarse para limitar los privilegios del servicio. El motivo de esto es mantener la seguridad del propio sistema. Porque si un servicio se está ejecutando con los privilegios más altos ( root
) y un atacante lo controla, automáticamente el atacante tiene los derechos más altos sobre todo el sistema. Todos los usuarios del sistema se almacenan en el archivo /etc/passwd
. El formato nos brinda cierta información, como:
Nombre de usuario
Contraseña
Identificación de usuario (UID)
Identificación de grupo (GID)
Información de identificación del usuario
Directorio de inicio
Shell
Ver usuarios existentes
Ocasionalmente, veremos hashes de contraseñas directamente en el archivo /etc/passwd
. Este archivo es legible para todos los usuarios y, al igual que con los hashes en el archivo /etc/shadow
, estos pueden estar sujetos a un ataque de descifrado de contraseñas fuera de línea. Esta configuración, aunque no es común, a veces se puede ver en dispositivos integrados y enrutadores.
Con Linux se pueden utilizar varios algoritmos hash diferentes para hacer que las contraseñas sean irreconocibles. Identificarlos a partir de los primeros bloques hash puede ayudarnos a utilizarlos y trabajar con ellos más adelante si es necesario. A continuación, se incluye una lista de los más utilizados:
También queremos comprobar qué usuarios tienen shells de inicio de sesión. Una vez que veamos qué shells hay en el sistema, podemos comprobar cada versión en busca de vulnerabilidades. Las versiones obsoletas, como la versión 4.1 de Bash, son vulnerables a un exploit shellshock
.
Cada usuario en sistemas Linux está asignado a un grupo o grupos específicos y por lo tanto recibe privilegios especiales. Por ejemplo, si tenemos una carpeta nombrada dev
solo para desarrolladores, un usuario debe estar asignado al grupo apropiado para acceder a esa carpeta. La información sobre los grupos disponibles la podemos encontrar en el archivo /etc/group
, que nos muestra tanto el nombre del grupo como los nombres de usuario asignados.
Grupos existentes
El archivo /etc/group
enumera todos los grupos del sistema. Luego podemos usar el comando getent para enumerar los miembros de cualquier grupo que nos interese.
También podemos comprobar qué usuarios tienen una carpeta en el /home
directorio. Queremos enumerar cada uno de ellos para ver si alguno de los usuarios del sistema está almacenando datos confidenciales, archivos que contienen contraseñas. Deberíamos comprobar si los archivos como el archivo .bash_history
son legibles y contienen comandos interesantes y buscar archivos de configuración. No es raro encontrar archivos que contienen credenciales que se pueden aprovechar para acceder a otros sistemas o incluso obtener acceso al entorno de Active Directory. También es importante comprobar las claves SSH de todos los usuarios, ya que podrían usarse para lograr la persistencia en el sistema, potencialmente para escalar privilegios o para ayudar con el pivoteo y el reenvío de puertos en la red interna. Como mínimo, verifique la caché ARP para ver a qué otros hosts se está accediendo y haga una referencia cruzada de estos con cualquier clave privada SSH utilizable.
Por último, podemos buscar cualquier "objetivo fácil", como archivos de configuración y otros archivos que puedan contener información confidencial. Los archivos de configuración pueden contener una gran cantidad de información. Vale la pena buscar nombres de usuario, contraseñas y otros secretos en todos los archivos que terminan en extensiones como .conf y .config.
Si hemos recopilado alguna contraseña, deberíamos probarla ahora para todos los usuarios presentes en el sistema. La reutilización de contraseñas es algo habitual, así que ¡quizás tengamos suerte!
En Linux, existen muchos lugares diferentes donde se pueden almacenar dichos archivos, incluidos los sistemas de archivos montados. Un sistema de archivos montado es un sistema de archivos que está conectado a un directorio particular del sistema y al que se accede a través de ese directorio. Se pueden montar muchos sistemas de archivos, como ext4, NTFS y FAT32. Cada tipo de sistema de archivos tiene sus propias ventajas y desventajas. Por ejemplo, algunos sistemas de archivos solo pueden ser leídos por el sistema operativo, mientras que otros pueden ser leídos y escritos por el usuario. Los sistemas de archivos que pueden ser leídos y escritos por el usuario se denominan sistemas de archivos de lectura/escritura. Montar un sistema de archivos permite al usuario acceder a los archivos y carpetas almacenados en ese sistema de archivos. Para montar un sistema de archivos, el usuario debe tener privilegios de root. Una vez que se monta un sistema de archivos, el usuario con privilegios de root puede desmontarlo. Es posible que tengamos acceso a dichos sistemas de archivos y que encontremos allí información, documentación o aplicaciones confidenciales.
Sistemas de archivos montados
Cuando se desmonta un sistema de archivos, el sistema ya no puede acceder a él. Esto puede ocurrir por diversos motivos, como cuando se extrae un disco o cuando ya no se necesita un sistema de archivos. Otro motivo puede ser que los archivos, scripts, documentos y otra información importante no puedan ser montados y vistos por un usuario estándar. Por lo tanto, si podemos extender nuestros privilegios al root
usuario, podríamos montar y leer estos sistemas de archivos nosotros mismos. Los sistemas de archivos desmontados se pueden ver de la siguiente manera:
Sistemas de archivos desmontados
En un sistema Linux, muchas carpetas y archivos se mantienen ocultos para que no sean evidentes y se evite la edición accidental. Existen muchas más razones por las que se mantienen ocultos estos archivos y carpetas que las mencionadas hasta ahora. Sin embargo, debemos poder localizar todos los archivos y carpetas ocultos porque a menudo pueden contener información confidencial, incluso si tenemos permisos de solo lectura.
Todos los archivos ocultos
Todos los directorios ocultos
Además, hay tres carpetas predeterminadas destinadas a los archivos temporales. Estas carpetas son visibles para todos los usuarios y se pueden leer. Además, se pueden encontrar allí registros temporales o salidas de scripts. Tanto /tmp
y /var/tmp
se utilizan para almacenar datos temporalmente. Sin embargo, la diferencia clave es el tiempo durante el cual se almacenan los datos en estos sistemas de archivos. El tiempo de retención de datos para /var/tmp
es mucho más largo que el del /tmp
directorio. De forma predeterminada, todos los archivos y datos almacenados en /var/tmp se conservan hasta 30 días. En cambio, en /tmp, los datos se eliminan automáticamente después de diez días.
Además, todos los archivos temporales almacenados en el directorio /tmp
se eliminan inmediatamente cuando se reinicia el sistema. Por lo tanto, los programas utilizan el directorio /var/tmp
para almacenar datos que deben conservarse temporalmente entre reinicios.
Archivos temporales
Seguimos adelante
Hemos obtenido una idea inicial del terreno y (con suerte) algunos puntos de datos útiles o sensibles que pueden ayudarnos a escalar privilegios o incluso a movernos lateralmente en la red interna. A continuación, nos centraremos en los permisos y comprobaremos qué directorios, scripts, archivos binarios, etc. podemos leer y escribir con nuestros privilegios de usuario actuales.
Aunque en este módulo nos centraremos en la enumeración manual, vale la pena ejecutar el script linPEAS en este punto en una evaluación del mundo real para que tengamos la mayor cantidad de datos posibles para analizar. A menudo podemos encontrar una solución fácil, pero tener este resultado a mano a veces puede revelar problemas matizados que nuestra enumeración manual pasó por alto.
Sin embargo, deberíamos practicar nuestra enumeración manual tanto como sea posible y crear (y seguir ampliando) nuestra propia hoja de trucos de comandos clave (y alternativas para diferentes sistemas operativos Linux). Comenzaremos a desarrollar nuestro propio estilo, preferencia de comandos e incluso veremos algunas áreas que podemos comenzar a programar nosotros mismos. Las herramientas son geniales y tienen su lugar, pero donde muchas fallan es en la capacidad de realizar una tarea determinada cuando una herramienta falla o no podemos incorporarla al sistema.
Caso práctico
Enumere el entorno Linux y busque archivos interesantes que puedan contener datos confidenciales. Envíe la flag como respuesta.
Es un archivo ejecutable. ncdu
es una herramienta de línea de comandos para analizar el uso del disco, pero también puede tener vulnerabilidades si no se gestiona correctamente. Lo primero que podemos hacer es ver el menú de opciones o probar si hay alguna opción que permita ejecutar comandos adicionales o abrir un shell.
Como está en el directorio /bin
podemos ejecutarla directamente desde la terminal:
Buscando en GTFOBins podemos probar alguna de las técnicas que menciona:
Siempre que nos salga algo que podemos ejecutar con el comando sudo -l
el primer paso que deberíamos hacer siempre es buscarlo en GTFOBins.
De igual manera podríamos probar a buscar archivos que contengan la cadena 'HTB{}
' que es el formato de las flags de Hack the Box:
Al abrir este archivo efectivamente nos encontramos la flag:
Última actualización