Eu son raíz. Comprensión da escalada de privilexios do sistema operativo Linux

Pasei o primeiro trimestre de 2020 preparándome para o exame OSCP. A procura de información en Google e moitos intentos "a cego" ocuparon todo o meu tempo libre. Era especialmente difícil comprender os mecanismos para aumentar os privilexios. O curso PWK presta moita atención a este tema, pero os materiais didácticos nunca son suficientes. Hai moitos manuais en Internet con comandos útiles, pero non son fan de seguir cegamente as recomendacións sen entender a que vai levar.

Gustaríame compartir convosco o que aprendín durante a preparación e a superación exitosa do exame (incluídas as incursións periódicas en Hack The Box). Sentín un forte sentido de gratitude por cada información que me axudou a percorrer o camiño Try Harder de forma máis consciente, agora é o meu momento de devolverlle á comunidade.

Quero darche un manual sobre como aumentar os privilexios en OS Linux, que inclúe unha análise dos vectores máis comúns e funcións relacionadas que definitivamente che serán útiles. Moitas veces, os propios mecanismos para aumentar os privilexios son bastante sinxelos; xorden dificultades á hora de estruturar e analizar a información. Polo tanto, decidín comezar cun "tour turístico" e despois considerar cada vector nun artigo separado. Espero que che aforre algún tempo investigando o tema.

Entón, por que é posible a escalada de privilexios en 2020 se os métodos son coñecidos durante moito tempo? De feito, se o usuario manexa o sistema correctamente, realmente non será posible aumentar os privilexios nel. O principal problema global que dá lugar a tales oportunidades é configuración insegura. A presenza de versións de software obsoletas que conteñen vulnerabilidades no sistema tamén é un caso especial de configuración insegura.

Escalada de privilexios mediante unha configuración insegura

En primeiro lugar, imos tratar a configuración insegura. Comecemos Os profesionais de TI adoitan usar manuais e recursos como stackoverflow, moitos dos cales conteñen comandos e configuracións non seguras. Un exemplo rechamante - as novas que o código máis copiado de stackoverflow contiña un erro. Un administrador experimentado verá a xamba, pero isto está nun mundo ideal. Incluso especialistas competentes aumento da carga de traballo capaz de cometer erros. Imaxina que un administrador está a preparar e coordinar a documentación para a próxima licitación, ao mesmo tempo que afonda na nova tecnoloxía que se vai implantar no próximo trimestre, ao tempo que soluciona periodicamente os problemas de apoio aos usuarios. E entón encárgase a tarefa de configurar rapidamente un par de máquinas virtuais e implementar servizos nelas. Cal cres que é a probabilidade de que o administrador simplemente non note a xamba? Despois cambian os especialistas, pero as muletas permanecen, mentres que as empresas sempre se esforzan por minimizar os custos, incluso para o persoal de TI.

Pseudo-shell e jailbreak

O intérprete de comandos do sistema obtido durante a fase de explotación adoita estar limitado, especialmente se o obtivo mediante a piratería dun usuario do servidor web. Por exemplo, as restricións do shell poden impedirlle executar o comando sudo, producindo un erro:

sudo: no tty present and no askpass program specified

Unha vez que teña un shell, recoméndolle crear un terminal completo, por exemplo usando Python.

python -c 'import pty;pty.spawn("/bin/bash")'

Podes preguntar: "Por que necesito mil comandos se podo usar un, por exemplo, para transferir ficheiros?" O feito é que os sistemas están configurados de forma diferente; un host determinado pode non ter instalado Python, pero pode ter Perl. A habilidade é poder facer cousas coñecidas no sistema sen ferramentas coñecidas. Pódese atopar unha lista completa de funcións aquí.

Pódese obter un shell de baixos privilexios usando equipos 1 и equipos 2 (sorprendentemente, incluso GIMP).

Ver historial de comandos

Linux recolle un historial de todos os comandos executados nun ficheiro ~ / .bash_history. Se o servidor se usa activamente e o seu historial non se borra, hai unha alta probabilidade de atopar credenciais neste ficheiro. Limpar o historial é simplemente un inconveniente. Se o administrador se ve obrigado a seleccionar comandos de dez pisos a través de , por suposto, será máis conveniente para el chamar a este comando desde o historial que ingresalo de novo. Ademais, moitas persoas non saben sobre este "hack". Se hai cunchas alternativas como Zsh ou Fish no sistema, teñen a súa propia historia. Para mostrar o historial de comandos en calquera shell, só tes que escribir o historial de comandos.

cat ~/.bash_history
cat ~/.mysql_history
cat ~/.nano_history
cat ~/.php_history
cat ~/.atftp_history

Existe aloxamento compartido, no que o servidor serve para aloxar varios sitios web. Normalmente, con esta configuración, cada recurso ten o seu propio usuario cun directorio de inicio separado e un host virtual. Polo tanto, se está configurado incorrectamente, pode atopar o ficheiro .bash_history no directorio raíz do recurso web.

Busca de contrasinais no sistema de ficheiros e ataques a sistemas adxacentes

O teu usuario actual pode leer os ficheiros de configuración de varios servizos. Neles podes atopar credenciais en texto claro: contrasinais para acceder a unha base de datos ou servizos relacionados. O mesmo contrasinal pódese utilizar tanto para acceder á base de datos como para autorizar ao usuario root (dotación de credenciais).
Ocorre que as credenciais atopadas pertencen a servizos doutros hosts. Desenvolver un ataque á infraestrutura a través dun host comprometido non é peor que explotar outros hosts. Tamén se poden atopar sistemas adxacentes buscando enderezos IP no sistema de ficheiros.

grep -lRi "password" /home /var/www /var/log 2>/dev/null | sort | uniq #Find string password (no cs) in those directories
grep -a -R -o '[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}.[0-9]{1,3}' /var/log/ 2>/dev/null | sort -u | uniq #IPs inside logs

Se o servidor comprometido ten unha aplicación web accesible desde Internet, é mellor excluír os seus rexistros da busca de enderezos IP. É improbable que os enderezos dos usuarios de recursos de Internet nos sexan útiles, pero os enderezos da rede interna (172.16.0.0/12, 192.168.0.0/16, 10.0.0.0/8) e onde van, a xulgar polos rexistros. , pode ser de interese.

Sudo

O comando sudo dálle ao usuario a posibilidade de executar un comando no contexto raíz usando o seu propio contrasinal ou sen usar ningún contrasinal. Moitas operacións en Linux requiren privilexios de root, pero executarse como root considérase unha práctica moi mala. Pola contra, é mellor aplicar permisos selectivos para executar comandos no contexto raíz. Non obstante, moitas ferramentas de Linux, incluídas as estándar como vi, pódense usar para aumentar os privilexios de xeito lexítimo. Para atopar un método axeitado, recoméndolle buscar aquí.

O primeiro que debes facer cando accedes ao sistema é executar o comando sudo -l. Mostrará permiso para usar o comando sudo. Se se obtén un usuario sen contrasinal (como apache ou www-data), o vector de escalada de privilexios a través de sudo é pouco probable. Ao usar sudo, o sistema pedirá un contrasinal. Tampouco poderás establecer un contrasinal usando o comando passwd; pediralle o contrasinal actual do usuario. Pero se sudo aínda está dispoñible, esencialmente debes buscar:

• calquera intérprete, calquera pode xerar un shell (PHP, Python, Perl);
• calquera editor de texto (vim, vi, nano);
• calquera espectador (menos, máis);
• calquera capacidade para traballar co sistema de ficheiros (cp, mv);
• Ferramentas que teñen saída en bash, interactiva ou como comando executable (awk, find, nmap, tcpdump, man, vi, vim, ansible).

Suid/Sgid

Hai moitos manuais en Internet que aconsellan recoller todos os comandos suid/sgid, pero un artigo raro dá detalles específicos sobre o que facer con estes programas. Pódense atopar opcións para aumentar os privilexios que non teñen en conta o uso de exploits aquí. Ademais, varios ficheiros executables teñen vulnerabilidades específicas para a versión do SO, por exemplo.

Nun mundo ideal, executarías todos os paquetes instalados polo menos a través de searchsploit. Na práctica, isto debería facerse cos programas máis populares como sudo. Tamén existe sempre a opción de utilizar e apoiar o desenvolvemento de ferramentas automatizadas que permitan destacar interesantes, desde o punto de vista da escalada de privilexios, ficheiros executables cos bits suid/sgid configurados. Proporcionarei unha lista de tales ferramentas na sección correspondente do artigo.

Scripts escribibles executados por Cron ou Init no contexto de Root

Os traballos Cron pódense executar en diferentes contextos de usuario, incluído root. Se unha tarefa cron está configurada cunha ligazón a un ficheiro executable e está dispoñible para escribir, pódese substituír facilmente por outra maliciosa e pódese realizar unha escalada de privilexios. Non obstante, por defecto, calquera usuario pode leer os ficheiros con tarefas cron.

ls -la /etc/cron.d  # show cron jobs 

A situación é semellante con init. A diferenza é que as tarefas en cron execútanse periodicamente, e en init - ao inicio do sistema. A operación requirirá un reinicio do sistema e algúns servizos poden non iniciarse (se non estaban rexistrados no inicio).

ls -la /etc/init.d/  # show init scripts 

Tamén pode buscar ficheiros que calquera usuario poida escribir.

find / -perm -2 -type f 2>/dev/null # find world writable files

O método é bastante coñecido; administradores de sistemas experimentados usan coidadosamente o comando chmod. Non obstante, en Internet, a gran maioría dos manuais describen a definición de dereitos máximos. O enfoque de "só facelo funcionar" dos administradores de sistemas inexpertos crea oportunidades para a escalada de privilexios en principio. Se é posible, é mellor buscar no historial de comandos un uso non seguro de chmod.

chmod +w /path 
chmod 777 /path

Obtención de acceso de shell a outros usuarios

Observamos a lista de usuarios en /etc/passwd. Prestamos atención aos que teñen cuncha. Podes eliminar estes usuarios en bruto; é posible que, a través do usuario resultante, eventualmente sexa posible aumentar os privilexios.

Para mellorar a seguridade, recoméndoche que sempre cumpras co principio de privilexio mínimo. Tamén ten sentido dedicar tempo a comprobar as configuracións inseguras que poderían quedar despois da resolución de problemas: este é o "deber técnico" do administrador do sistema.

Código autoescrito

Paga a pena botar unha ollada aos ficheiros executables no directorio de inicio do usuario e do servidor web (/var/www/, salvo que se especifique o contrario). Estes ficheiros poden resultar unha solución completamente insegura e conter muletas incribles. Por suposto, se tes algún tipo de marco no directorio do servidor web, non ten sentido buscar o día cero nel como parte dun pentest, pero recoméndase buscar e estudar modificacións, complementos e compoñentes personalizados.

Para aumentar a seguridade, é mellor, se é posible, evitar o uso de credenciais en scripts autoescritos, así como funcionalidades potencialmente perigosas, como ler /etc/shadow ou manipular id_rsa.

Elevación de privilexios mediante a explotación de vulnerabilidades

Antes de tentar aumentar os privilexios mediante a explotación, é importante entender transferir ficheiros ao host de destino. Ademais das ferramentas habituais como ssh, ftp, http (wget, curl) hai un todo "zoo" de posibilidades.

Para mellorar a seguridade do sistema, actualízao regularmente á última estable versións e tamén intente utilizar distribucións deseñadas para Enterprise. En caso contrario, é raro, pero hai situacións nas que a actualización apt fai que o sistema sexa inoperable.

Explotación de servizos que se executan no contexto do usuario raíz

Algúns servizos de Linux execútanse como root. Pódense atopar usando o comando ps aux | raíz grep. Neste caso, o servizo pode non ser anunciado en Internet e estar dispoñible localmente. Se ten exploits públicos, pódense usar con seguridade: un fallo de servizo en caso de falla é moito menos crítico que un fallo do SO.

ps -aux | grep root # Linux

O caso máis exitoso pódese considerar a operación dun servizo pirateado no contexto do usuario root. O funcionamento do servizo SMB dá acceso privilexiado ao SISTEMA en sistemas Windows (por exemplo, a través de ms17-010). Non obstante, isto non é común nos sistemas Linux, polo que pode pasar moito tempo aumentando os privilexios.

Explotación de vulnerabilidades do núcleo de Linux

Este é o último camiño que debes tomar. A operación non exitosa pode provocar un fallo do sistema e, en caso de reinicio, algúns servizos (incluídos aqueles a través dos cales se obtivo o shell inicial) poden non iniciarse. Ocorre que o administrador simplemente esqueceu usar o comando systemctl enable. Ademais, causará moita insatisfacción co seu traballo se non se acordou a operación.
Se decides usar os códigos fonte de exploitdb, asegúrate de ler os comentarios ao comezo do script. Entre outras cousas, adoita dicir como compilar correctamente un exploit determinado. Se es demasiado preguiceiro ou tiveches que facelo "onte" por mor dos prazos, podes buscar repositorios con exploits xa compilados, por exemplo. Non obstante, debes entender que neste caso conseguirás un porco nun golpe. Por outra banda, se un programador entendese ata o byte como funciona un ordenador e o software que utiliza, non escribiría unha soa liña de código en toda a súa vida.

cat /proc/version
uname -a
searchsploit "Linux Kernel" 

metasploit

Para capturar e manexar a conexión, sempre é mellor usar o módulo exploit/multi/handler. O principal é configurar a carga útil correcta, por exemplo, generic/shell/reverse_tcp ou generic/shell/bind_tcp. O shell producido por Metasploit pódese actualizar a Meterpreter usando o módulo post/multi/manage/shell_to_meterpreter. Con Meterpreter, pode automatizar o proceso posterior á explotación. Por exemplo, o módulo post/multi/recon/local_exploit_suggester verifica a plataforma, a arquitectura e as entidades necesarias para a súa explotación e suxire módulos Metasploit para aumentar os privilexios no sistema de destino. Grazas a Meterpreter, a escalada de privilexios ás veces pasa por lanzar o módulo necesario, pero piratear sen entender o que está a suceder baixo o capó non é "verdadero" (aínda tes que escribir un informe).

ferramentas

As ferramentas para automatizar a recollida de información local aforrarán moito esforzo e tempo, pero por si mesmas non son capaces de identificar completamente o camiño para a escalada de privilexios, especialmente no caso da explotación das vulnerabilidades do núcleo. As ferramentas de automatización realizarán todos os comandos necesarios para que poida recoller información sobre o sistema, pero tamén é importante poder analizar datos recibidos. Espero que o meu artigo che sexa útil neste sentido. Por suposto, hai moitas máis ferramentas das que enumerarei a continuación, pero todas fan aproximadamente o mesmo: isto é máis ben unha cuestión de gustos.

Linpeas

Un Tula bastante recente, o primeiro compromiso remóntase a xaneiro de 2019. A miña ferramenta favorita neste momento. A cuestión é que destaca os vectores máis interesantes de escalada de privilexios. De acordo, é máis conveniente obter unha avaliación experta neste nivel que analizar datos brutos monolíticos.

LinEnum

A miña segunda ferramenta favorita, tamén recolle e organiza os datos obtidos como resultado da enumeración local.

Linux-exploit-suggester (1,2)

Este exploit analizará o sistema para as condicións de explotación adecuadas. De feito, fará o traballo idéntico ao módulo de Metasploit local_exploit_suggester, pero ofrecerá ligazóns a códigos fonte exploit-db en lugar de módulos de Metasploit.

Linuxprivchecker

Este script recollerá e organizará en seccións unha gran cantidade de información que pode ser útil para formar un vector para aumentar os privilexios.

Noutra vez entrarei en detalles elevación de privilexios no sistema operativo Linux mediante suid/sgid.

Fonte: www.habr.com