Truques e Artimanhas

Quando sua shell é inicializada, ela procura pelo arquivo .bashrc no seu diretório inicial (home) e o executa como um script de inicialização. Você pode personalizar seu /home/hacker/.bashrc com coisas úteis, como configurar variáveis de ambiente, ajustar o comportamento da sua shell e assim por diante.

Mas você também pode utilizá-lo para propósitos maliciosos! O .bashrc de uma vítima desavisada é um alvo clássico para invasões e artimanhas. Imagine entrar de fininho no computador de um colega e adicionar echo "Os hackers estiveram aqui!" ao final do .bashrc dele. Isso pode ser engraçado, mas essa mesma capacidade pode ser empregada para objetivos muito mais perigosos. Softwares maliciosos (malwares), por exemplo, costumam ter como alvo scripts de inicialização como o .bashrc para garantir persistência no sistema ao longo do tempo!

Neste desafio, vamos fingir que você invadiu a máquina de um usuário alvo! O nome desse usuário é zardus, e seu diretório inicial é /home/zardus. Você, com o usuário hacker, tem permissão de escrita no .bashrc dele, e o zardus possui permissão de leitura sobre a /flag. A vítima é simulada pelo script /challenge/victim, e você pode executá-lo a qualquer momento para observar a vítima fazendo login no computador. Você consegue obter a flag?

DICA: Assim como os scripts explorados em Encadeando Comandos, o arquivo .bashrc nada mais é do que um shell script. Adicionar uma nova linha contendo um comando (por exemplo, echo Olá Hackers) fará com que esse comando seja executado. Portanto, tudo o que você precisa pensar é em qual comando fará a flag chegar até você!

NOTA: O /home/zardus/.bashrc da vítima já terá muito conteúdo existente: o processo de inicialização de uma shell é complexo. Não entre em pânico — apenas adicione sua carga útil (payload) no final do arquivo!

DICA: Precisa investigar o ambiente como zardus para depurar sua solução? No Modo Privilegiado (Privileged Mode), você pode usar sudo su --login zardus para acessar uma sessão como Zardus!

No nível anterior, você explorou o ~/.bashrc do Zardus para fazê-lo executar comandos em seu favor.

Desta vez, o Zardus não deixa a flag em um arquivo legível após fazer login. Em vez disso, ele executará um comando chamado flag_checker, digitando a flag manualmente nele para verificação.

Sua missão é utilizar o seu acesso contínuo de escrita ao .bashrc do Zardus para interceptar essa flag. Lembra-se de como você sequestrou comandos no módulo Desvendando o PATH? Consegue usar essa mesma técnica para interceptar o flag_checker?

DICA: O Zardus está desconfiando da sua interceptação? Ele é cauteloso — ele verifica se a mensagem de solicitação (prompt) do flag_checker exibe exatamente Type the flag. Certifique-se de que o seu binário interceptador também imprima esse prompt (por exemplo, echo "Type the flag"). Além de imprimir esse prompt, o seu flag_checker falso pode: a) Simplesmente passar a entrada do Zardus para o stdout com cat (usando cat sem argumentos), ou b) Ler a entrada em uma variável com read e exibi-la com echo. A escolha é sua!

DICA: Não se esqueça de tornar o seu flag_checker falso executável, conforme você aprendeu no módulo Compreendendo Permissões!

Muito bem, Zardus ficou mais esperto — afinal de contas, por que ele deixaria o .bashrc gravável por qualquer um? Porém, um cenário muito mais comum é usuários no mesmo sistema, a fim de facilitar a colaboração, tornarem seus diretórios pessoais (home) graváveis por todos (world-writable). Qual é o grande perigo disso?

O problema reside em uma sutileza das permissões de arquivos/diretórios no Linux: qualquer pessoa com permissão de escrita em um diretório pode mover e excluir arquivos dentro dele. Por exemplo, suponha que Zardus crie um diretório com permissão total de escrita para colaboração:

zardus@dojo:~$ mkdir /tmp/collab
zardus@dojo:~$ chmod a+w /tmp/collab
zardus@dojo:~$ echo "do pwn.college" > /tmp/collab/todo-list

Em seguida, um invasor surge e executa o seguinte, mesmo não sendo o dono do arquivo todo-list!

hacker@dojo:~$ ls -l /tmp/collab/todo-list
-rw-r--r-- 1 zardus zardus 15 Jun  6 13:12 /tmp/collab/todo-list
hacker@dojo:~$ rm /tmp/collab/todo-list
rm: remove write-protected regular file '/tmp/collab/todo-list'? y
hacker@dojo:~$ echo "send hacker money" > /tmp/collab/todo-list
hacker@dojo:~$ ls -l /tmp/collab/todo-list
-rw-r--r-- 1 hacker hacker 18 Jun  6 13:12 /tmp/collab/todo-list
hacker@dojo:~$

Isso pode parecer contra-intuitivo à primeira vista: o hacker não tinha permissão de escrita no arquivo todo-list, mas o resultado final foi que ele conseguiu substituir todo o seu conteúdo. Pense da seguinte forma: o vínculo de um arquivo com um diretório reside, em última instância, no próprio diretório. Assim, usuários com permissão de escrita naquele diretório podem alterar essas ligações. Evidentemente, isso acarreta sérias implicações de segurança quando diretórios importantes estão com permissão de escrita para qualquer um.

Neste desafio, por pura conveniência, Zardus abriu as permissões do seu diretório inicial:

zardus@dojo:~$ chmod a+w /home/zardus

Como você sabe, existem muitos arquivos críticos nesse diretório, como o .bashrc! Você consegue reproduzir o ataque anterior tendo permissão de escrita em /home/zardus, em vez de ter acesso direto a /home/zardus/.bashrc?

Certo, o Zardus ficou esperto mais uma vez! Nada de compartilhar o diretório inicial: apesar da menor conveniência, Zardus passou a compartilhar /tmp/collab. Ele tornou esse diretório gravável por todos e começou a criar uma lista de comandos perigosos para memorizar!

zardus@dojo:~$ mkdir /tmp/collab
zardus@dojo:~$ chmod a+w /tmp/collab
zardus@dojo:~$ echo "rm -rf /" > /tmp/collab/evil-commands.txt

Neste desafio, quando você executa /challenge/victim, Zardus adiciona cat /flag a essa lista de comandos:

hacker@dojo:~$ /challenge/victim

Username: zardus
Password: **********
zardus@dojo:~$ echo "cat /flag" >> /tmp/collab/evil-commands.txt
zardus@dojo:~$ exit
logout

hacker@dojo:~$

Lembre-se do nível anterior que, com permissão de escrita em /tmp/collab, o usuário hacker pode substituir o arquivo evil-commands.txt. Lembre-se também de Compreendendo Comandos que arquivos podem criar links para outros arquivos. O que acontece se o usuário hacker substituir evil-commands.txt por um link simbólico apontando para algum arquivo sensível no qual zardus pode escrever? Caos e artimanhas puras!

Você sabe para qual arquivo deve apontar o link. Execute o ataque e capture a /flag (que, neste nível, Zardus pode ler novamente!).

DICA: Você precisará executar /challenge/victim duas vezes: uma para que cat /flag seja gravado no destino desejado, e outra para dispará-lo!

O /tmp é perigoso de usar??? Apesar do ataque demonstrado aqui, o /tmp pode ser utilizado com segurança. O diretório é gravável por todos (world-writable), mas possui um bit especial de permissão habilitado:

hacker@dojo:~$ ls -ld /tmp
drwxrwxrwt 29 root root 1056768 Jun  6 14:06 /tmp
hacker@dojo:~$

Essa letra t no final representa o bit sticky (sticky bit). O sticky bit determina que o diretório apenas permita que os proprietários dos arquivos possam renomear ou remover arquivos dentro dele. Ele foi projetado especificamente para impedir esse tipo de ataque! O problema neste desafio, claramente, foi que Zardus não habilitou o sticky bit em /tmp/collab. Fazer isso teria eliminado a vulnerabilidade neste caso específico:

zardus@dojo:~$ chmod +t /tmp/collab

Evidentemente, recursos compartilhados como diretórios graváveis por qualquer usuário continuam sendo arriscados. Muito mais adiante, no módulo de Condições de Corrida (Race Conditions) do conteúdo de Faixa Verde (Green Belt), você verá diversas formas em que esses recursos podem desencadear problemas de segurança!

Pobre Zardus; você já o invadiu bastante. Mas ele aprendeu a lição e protegeu seu diretório inicial! Fim de jogo?

Ainda não! Uma das coisas que as pessoas frequentemente não consideram quando existem múltiplas contas no mesmo computador é que tipo de informação a execução dos seus comandos pode vazar. Lembre-se: quando você executa ps aux, você obtém:

hacker@dojo:~$ ps aux
USER         PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
hacker         1  0.0  0.0   1128     4 ?        Ss   05:34   0:00 /sbin/docker-init -- /bin/sleep 6h
hacker         7  0.0  0.0   2736   580 ?        S    05:34   0:00 /bin/sleep 6h
hacker       102  0.4  0.0 723944 64660 ?        Sl   05:34   0:00 /usr/lib/code-server/lib/node /usr/lib/code-serve
hacker       138  3.3  0.0 968792 106272 ?       Sl   05:34   0:07 /usr/lib/code-server/lib/node /usr/lib/code-serve
hacker       287  0.0  0.0 717648 53136 ?        Sl   05:34   0:00 /usr/lib/code-server/lib/node /usr/lib/code-serve
hacker       318  3.3  0.0 977472 98256 ?        Sl   05:34   0:06 /usr/lib/code-server/lib/node --dns-result-order=
hacker       554  0.4  0.0 650560 55360 ?        Rl   05:35   0:00 /usr/lib/code-server/lib/node /usr/lib/code-serve
hacker       571  0.0  0.0   4600  4032 pts/0    Ss   05:35   0:00 /usr/bin/bash --init-file /usr/lib/code-server/li
hacker      1172  0.0  0.0   5892  2924 pts/0    R+   05:38   0:00 ps aux
hacker@dojo:~$

Mas o que aconteceria se um dos argumentos passados para esses comandos contivesse dados sensíveis, como a flag ou uma senha? Isso acontece na vida real, e usuários mal-intencionados que compartilham a mesma máquina (ou que consigam listar processos nela de alguma forma) podem roubar esses dados e usá-los!

É isso o que este desafio explora. Zardus está utilizando um script de automação, passando a senha da sua conta como argumento na linha de comando. Além disso, Zardus tem permissão para usar sudo (e, portanto, pode executar sudo cat /flag!). Roube a senha, faça login na conta do Zardus (relembre o comando su do módulo Desvendando Usuários) e capture a flag!

Mesmo sem cometer erros óbvios, os usuários podem involuntariamente se colocar em risco. Por exemplo, muitos arquivos no diretório inicial (home) de um usuário comum possuem permissão de leitura para todos por padrão (world-readable), apesar de serem usados com frequência para armazenar dados confidenciais. Acredite ou não, o seu arquivo .bashrc possui permissão de leitura para qualquer usuário do sistema, a menos que você altere isso explicitamente!

hacker@dojo:~$ ls -l ~/.bashrc
-rw-r--r-- 1 hacker hacker 148 Jun  7 05:56 /home/hacker/.bashrc
hacker@dojo:~$

Você pode pensar: "Ora, pelo menos ele não é gravável por todos por padrão!". Mas mesmo apenas com permissão de leitura, ele pode causar estragos. Como o .bashrc é processado pela shell na inicialização, é nele que as pessoas costumam colocar definições de variáveis de ambiente que desejam personalizar. Na maior parte das vezes, trata-se de itens inofensivos como PATH, mas às vezes as pessoas armazenam chaves de API lá para facilitar o uso diário. Por exemplo, neste desafio:

zardus@dojo:~$ echo "FLAG_GETTER_API_KEY=sk-XXXYYYZZZ" > ~/.bashrc

Depois disso, Zardus pode facilmente fazer referência à chave de API. Neste nível, os usuários podem usar uma chave de API válida para obter a flag:

zardus@dojo:~$ flag_getter --key $FLAG_GETTER_API_KEY
Correct API key! Do you want me to print the key (y/n)? y
pwn.college{HACKED}
zardus@dojo:~$

Naturalmente, Zardus guarda a chave dele no .bashrc. Você consegue espionar e roubar essa chave para capturar a flag?

NOTA: Quando obtiver a chave de API, basta executar flag_getter diretamente com o usuário hacker. O /challenge/victim deste desafio existe apenas para compor o cenário: você não precisa utilizá-lo.