Passei o primeiro trimestre de 2020 me preparando para o exame OSCP. A busca por informações no Google e muitas tentativas “cegas” ocuparam todo o meu tempo livre. Foi especialmente difícil compreender os mecanismos para aumentar os privilégios. O curso PWK dá muita atenção a esse tema, mas os materiais didáticos nunca são suficientes. Existem muitos manuais na Internet com comandos úteis, mas não sou fã de seguir recomendações cegamente sem entender aonde isso vai levar.
Gostaria de compartilhar com vocês o que aprendi durante a preparação e aprovação no exame (incluindo incursões periódicas no Hack The Box). Senti um forte sentimento de gratidão por cada informação que me ajudou a trilhar o caminho Try Harder de forma mais consciente, agora é minha hora de retribuir à comunidade.
Quero lhe dar um manual sobre como escalar privilégios no sistema operacional Linux, que inclui uma análise dos vetores mais comuns e recursos relacionados que certamente serão úteis para você. Muitas vezes, os próprios mecanismos para aumentar os privilégios são bastante simples, surgem dificuldades na estruturação e análise da informação. Portanto, decidi começar com um “passeio turístico” e depois considerar cada vetor em um artigo separado. Espero economizar algum tempo pesquisando o assunto.
Então, por que a escalada de privilégios será possível em 2020 se os métodos são bem conhecidos há muito tempo? Na verdade, se o usuário manusear o sistema corretamente, realmente não será possível aumentar privilégios nele. O principal problema global que dá origem a tais oportunidades é configuração insegura. A presença de versões desatualizadas de software contendo vulnerabilidades no sistema também é um caso especial de configuração insegura.
Escalonamento de privilégios via configuração insegura
Primeiro, vamos lidar com configurações inseguras. Vamos começar com Profissionais de TI costumam usar manuais e recursos como stackoverflow, muitos dos quais contêm comandos e configurações inseguros. Um exemplo notável - que o código mais copiado do stackoverflow continha um erro. Um administrador experiente verá o batente, mas este é um mundo ideal. Mesmo especialistas competentes aumento da carga de trabalho capaz de cometer erros. Imagine que um administrador está a preparar e a coordenar a documentação do próximo concurso, ao mesmo tempo que se aprofunda na nova tecnologia que será implementada no próximo trimestre, ao mesmo tempo que resolve periodicamente problemas de suporte aos utilizadores. E então ele recebe a tarefa de configurar rapidamente algumas máquinas virtuais e implementar serviços nelas. Qual você acha que é a probabilidade de o administrador simplesmente não notar o batente? Depois os especialistas mudam, mas as muletas permanecem, enquanto as empresas sempre se esforçam para minimizar custos, inclusive para o pessoal de TI.
Pseudo-shell e jailbreak
O shell do sistema obtido durante o estágio de exploração costuma ser limitado, especialmente se você o obteve hackeando um usuário do servidor web. Por exemplo, as restrições do shell podem impedir que você execute o comando sudo, produzindo um erro:
sudo: no tty present and no askpass program specifiedDepois de ter um shell, recomendo criar um terminal completo, por exemplo, usando Python.
python -c 'import pty;pty.spawn("/bin/bash")'Você pode perguntar: “Por que preciso de mil comandos se posso usar um, por exemplo, para transferir arquivos?” O fato é que os sistemas são configurados de forma diferente; um determinado host pode não ter Python instalado, mas pode ter Perl. A habilidade é ser capaz de fazer coisas familiares no sistema sem ferramentas familiares. Uma lista completa de recursos pode ser encontrada .
Um shell de baixo privilégio pode ser obtido usando и (surpreendentemente, até mesmo o GIMP).
Ver histórico de comandos
Linux coleta um histórico de todos os comandos executados em um arquivo ~ / .bash_history. Se o servidor for usado ativamente e seu histórico não for limpo, há uma grande probabilidade de encontrar credenciais neste arquivo. Limpar o histórico é simplesmente inconveniente. Se o administrador for forçado a selecionar comandos de dez andares por meio de , é claro que será mais conveniente para ele chamar esse comando do histórico do que inseri-lo novamente. Além disso, muitas pessoas não sabem sobre esse “hack”. Se houver shells alternativos como Zsh ou Fish no sistema, eles terão sua própria história. Para exibir o histórico de comandos em qualquer shell, basta digitar o histórico de comandos.
cat ~/.bash_history
cat ~/.mysql_history
cat ~/.nano_history
cat ~/.php_history
cat ~/.atftp_historyExiste a hospedagem compartilhada, em que o servidor é utilizado para hospedar diversos sites. Normalmente, com esta configuração, cada recurso tem seu próprio usuário com um diretório inicial separado e um host virtual. Portanto, se configurado incorretamente, você poderá encontrar o arquivo .bash_history no diretório raiz do recurso da web.
Procurando senhas no sistema de arquivos e ataques a sistemas adjacentes
Arquivos de configuração para vários serviços podem ser lidos pelo usuário atual. Neles você pode encontrar credenciais em texto não criptografado - senhas para acesso a um banco de dados ou serviços relacionados. A mesma senha pode ser usada tanto para acessar o banco de dados quanto para autorizar o usuário root (credencial pessoal).
Acontece que as credenciais encontradas pertencem a serviços de outros hosts. Desenvolver um ataque à infraestrutura através de um host comprometido não é pior do que explorar outros hosts. Os sistemas adjacentes também podem ser encontrados pesquisando endereços IP no sistema de arquivos.
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 logsSe o host comprometido tiver um aplicativo web acessível pela Internet, é melhor excluir seus logs da busca por endereços IP. É improvável que os endereços dos usuários de recursos da Internet sejam úteis para nós, mas os endereços da rede interna (172.16.0.0/12, 192.168.0.0/16, 10.0.0.0/8) e para onde vão, a julgar pelos logs , pode ser de interesse.
Sudo
O comando sudo dá ao usuário a capacidade de executar um comando no contexto raiz usando sua própria senha ou sem usar nenhuma senha. Muitas operações no Linux requerem privilégios de root, mas executar como root é considerado uma prática muito ruim. Em vez disso, é melhor aplicar permissão seletiva para executar comandos no contexto raiz. No entanto, muitas ferramentas Linux, incluindo ferramentas padrão como o vi, podem ser usadas para aumentar privilégios de maneira legítima. Para encontrar um método adequado, recomendo procurar .
A primeira coisa que você precisa fazer ao obter acesso ao sistema é executar o comando sudo -l. Ele exibirá permissão para usar o comando sudo. Se um usuário sem senha for obtido (como apache ou www-data), o vetor de escalonamento de privilégios via sudo é improvável. Ao usar o sudo, o sistema solicitará uma senha. Você também não poderá definir uma senha usando o comando passwd; ele solicitará a senha atual do usuário. Mas se o sudo ainda estiver disponível, basicamente você precisará procurar:
- qualquer intérprete, qualquer um pode gerar um shell (PHP, Python, Perl);
- quaisquer editores de texto (vim, vi, nano);
- quaisquer espectadores (menos, mais);
- qualquer capacidade de trabalhar com o sistema de arquivos (cp, mv);
- Ferramentas que possuem saída em bash, interativa ou como comando executável (awk, find, nmap, tcpdump, man, vi, vim, ansible).
Suid/Sgid
Existem muitos manuais na Internet que aconselham a coleta de todos os comandos suid/sgid, mas um artigo raro fornece detalhes sobre o que fazer com esses programas. Opções para escalar privilégios que não levam em conta o uso de exploits podem ser encontradas . Além disso, vários arquivos executáveis possuem vulnerabilidades específicas para a versão do sistema operacional, .
Em um mundo ideal, você executaria todos os pacotes instalados pelo menos através do searchsploit. Na prática, isso deve ser feito com os programas mais populares como o sudo. Há também sempre a opção de usar e apoiar o desenvolvimento de ferramentas automatizadas que irão destacar arquivos executáveis interessantes, do ponto de vista da escalação de privilégios, com os bits suid/sgid definidos. Fornecerei uma lista dessas ferramentas na seção correspondente do artigo.
Scripts graváveis executados por Cron ou Init no contexto de Root
Os cron jobs podem ser executados em diferentes contextos de usuário, incluindo root. Se uma tarefa cron for configurada com um link para um arquivo executável e estiver disponível para você escrever, ela poderá ser facilmente substituída por uma tarefa mal-intencionada e com escalonamento de privilégios. No entanto, por padrão, os arquivos com tarefas cron podem ser lidos por qualquer usuário.
ls -la /etc/cron.d # show cron jobs A situação é semelhante com o init. A diferença é que as tarefas no cron são executadas periodicamente e no init - na inicialização do sistema. A operação exigirá a reinicialização do sistema e alguns serviços poderão não iniciar (se não tiverem sido registrados na inicialização).
ls -la /etc/init.d/ # show init scripts Você também pode procurar arquivos que possam ser gravados por qualquer usuário.
find / -perm -2 -type f 2>/dev/null # find world writable filesO método é bastante conhecido; administradores de sistema experientes usam cuidadosamente o comando chmod. No entanto, na Internet, a grande maioria dos manuais descreve a definição de direitos máximos. A abordagem “apenas faça funcionar” de administradores de sistema inexperientes cria, em princípio, oportunidades para aumento de privilégios. Se possível, é melhor procurar no histórico de comandos o uso inseguro de chmod.
chmod +w /path
chmod 777 /pathObtendo acesso shell para outros usuários
Vemos a lista de usuários em /etc/passwd. Prestamos atenção em quem tem concha. Você pode brutalizar esses usuários - é possível que através do usuário resultante seja possível aumentar os privilégios.
Para melhorar a segurança, recomendo que você sempre siga o princípio do menor privilégio. Também faz sentido gastar tempo verificando configurações inseguras que podem permanecer após a solução de problemas - esse é o “dever técnico” do administrador do sistema.
Código auto-escrito
Vale a pena dar uma olhada nos arquivos executáveis no diretório inicial do usuário e no servidor web (/var/www/, a menos que especificado de outra forma). Esses arquivos podem acabar sendo uma solução completamente insegura e conter muletas incríveis. Claro, se você tiver algum tipo de estrutura no diretório do servidor web, não faz sentido procurar zero-day nele como parte de um pentest, mas é recomendado encontrar e estudar modificações personalizadas, plugins e componentes.
Para aumentar a segurança, é melhor, se possível, evitar o uso de credenciais em scripts escritos por você mesmo, bem como funcionalidades potencialmente perigosas, como leitura de /etc/shadow ou manipulação de id_rsa.
Elevação de privilégios através da exploração de vulnerabilidades
Antes de tentar aumentar privilégios através da exploração, é importante compreender transferindo arquivos para o host de destino. Além das ferramentas usuais como ssh, ftp, http (wget, curl) existe todo um .
Para melhorar a segurança do sistema, atualize-o regularmente para a versão mais recente estábulo versões e também tente usar distribuições projetadas para Enterprise. Caso contrário, é raro, mas há situações em que o apt upgrade torna o sistema inoperante.
Explorando serviços em execução no contexto do usuário root
Alguns serviços Linux são executados como root. Eles podem ser encontrados usando o comando ps aux | raiz grep. Neste caso, o serviço não pode ser publicitado na Internet e estar disponível localmente. Se tiver explorações públicas, elas podem ser usadas com segurança: uma falha no serviço em caso de falha é muito menos crítica do que uma falha no sistema operacional.
ps -aux | grep root # LinuxO caso de maior sucesso pode ser considerado a operação de um serviço hackeado no contexto do usuário root. A operação do serviço SMB fornece acesso privilegiado ao SYSTEM em sistemas Windows (por exemplo, por meio de ms17-010). No entanto, isso não é comum em sistemas Linux, portanto você pode gastar muito tempo aumentando privilégios.
Explorando vulnerabilidades do kernel Linux
Este é o caminho que você deve seguir por último. A operação malsucedida pode causar uma falha no sistema e, no caso de uma reinicialização, alguns serviços (incluindo aqueles por meio dos quais o shell inicial foi obtido) podem não iniciar. Acontece que o administrador simplesmente esqueceu de usar o comando systemctl enable. Além disso, causará muita insatisfação com o seu trabalho se a operação não for acertada.
Se você decidir usar os códigos-fonte do exploitdb, leia os comentários no início do script. Entre outras coisas, geralmente diz como compilar corretamente um determinado exploit. Se você está com preguiça ou teve que fazer isso “ontem” por causa dos prazos, você pode procurar repositórios com exploits já compilados, . No entanto, você deve entender que, neste caso, você receberá um porco em uma armadilha. Por outro lado, se um programador entendesse detalhadamente como funciona um computador e o software que ele usa, ele não escreveria uma única linha de código em toda a sua vida.
cat /proc/version
uname -a
searchsploit "Linux Kernel" Metasploit
Para capturar e manipular a conexão, é sempre melhor usar o módulo exploit/multi/handler. O principal é definir a carga útil correta, por exemplo, generic/shell/reverse_tcp ou generic/shell/bind_tcp. O shell produzido pelo Metasploit pode ser atualizado para Meterpreter usando o módulo post/multi/manage/shell_to_meterpreter. Com o Meterpreter, você pode automatizar o processo pós-exploração. Por exemplo, o módulo post/multi/recon/local_exploit_suggester verifica a plataforma, arquitetura e entidades necessárias para exploração e sugere módulos Metasploit para escalar privilégios no sistema de destino. Graças ao Meterpreter, o aumento de privilégios às vezes se resume ao lançamento do módulo necessário, mas hackear sem entender o que está acontecendo nos bastidores não é “verdade” (você ainda precisa escrever um relatório).
Ferramentas
Ferramentas para automatizar a coleta de informações locais economizarão muito esforço e tempo, mas por si só não são capazes de identificar completamente o caminho para o escalonamento de privilégios, especialmente no caso de exploração de vulnerabilidades do kernel. As ferramentas de automação realizarão todos os comandos necessários para você coletar informações sobre o sistema, mas também é importante poder para analisar dados recebidos. Espero que meu artigo seja útil para você nesse sentido. Claro, existem muito mais ferramentas do que listarei abaixo, mas todas elas fazem aproximadamente a mesma coisa - isso é uma questão de gosto.
Uma Tula bastante recente, o primeiro commit data de janeiro de 2019. Minha ferramenta favorita no momento. A questão é que ele destaca os vetores mais interessantes de escalada de privilégios. Concordo, é mais conveniente obter uma avaliação especializada neste nível do que analisar dados brutos monolíticos.
Minha segunda ferramenta favorita, ela também coleta e organiza dados obtidos a partir de enumeração local.
Esta exploração analisará o sistema em busca de condições de exploração adequadas. Na verdade, ele fará o trabalho idêntico ao módulo Metasploit local_exploit_suggester, mas oferecerá links para códigos-fonte do exploit-db em vez de módulos Metasploit.
Este script irá coletar e organizar em seções uma grande quantidade de informações que podem ser úteis para formar um vetor de aumento de privilégios.
Outra hora entrarei em detalhes .
Fonte: habr.com