Démonstration de vulnérabilité sur Ubuntu 9.04

15

Pour un cours sur la sécurité informatique, je veux démontrer une élévation de privilèges aux étudiants. Pour ce faire, j'ai parcouru la exploit/linux/localliste du cadre Metasploit, trouvant (entre autres) à exploit/linux/local/sock_sendpagepartir d'août 2009.

J'ai installé une machine virtuelle avec Ubuntu Server 9.04 32 bits ( http://old-releases.ubuntu.com/releases/9.04/ubuntu-9.04-server-amd64.iso ) à partir d'avril 2009. uname -rme donne 2.6.28-11-generic. Selon la description de l'exploit

Toutes les versions de Linux 2.4 / 2.6 depuis mai 2001 seraient affectées: 2.4.4 jusqu'au 2.4.37.4 inclus; 2.6.0 jusqu'à 2.6.30.4 inclus

Il semble donc que le serveur Ubuntu que j'ai configuré devrait être adapté à la démonstration. Cependant, je n'ai pas réussi à le faire fonctionner.

J'ai ajouté un utilisateur (régulier) sur le serveur et l'accès SSH fonctionne. À partir de Metasploit Framework, je peux créer une session SSH en utilisant auxiliary/scanner/ssh/ssh_login. Cependant, lorsque je lance l'exploit, je reçois

[*] Writing exploit executable to /tmp/mlcpzP6t (4069 bytes)

[*] Exploit completed, but no session was created.

Je n'obtiens aucune information supplémentaire, pas même lors de la définition DEBUG_EXPLOITde la valeur true. /tmpest écrit, également à partir de la session Metasploit SSH:

$ sessions -c "touch /tmp/test.txt"
[*] Running 'touch /tmp/test.txt' on shell session 1 ([redacted])

$ sessions -c "ls -l /tmp"
[*] Running 'ls -l /tmp' on shell session 1 ([redacted])

total 0

-rw-r--r-- 1 [redacted] [redacted] 0 2016-03-28 09:44 test.txt

J'ai également essayé de définir WriteableDirle répertoire personnel de l'utilisateur sur le serveur, mais sans aucune modification. Qu'est-ce que j'oublie ici? Cette version du serveur Ubuntu (que je n'ai pas délibérément mise à jour!) N'est-elle pas vulnérable?

Andreas Unterweger
la source
À tout le moins, vous devez vérifier les journaux de la machine virtuelle.
Klaatu von Schlacker
@KlaatuvonSchlacker: Qu'est-ce que je recherche exactement? Je viens de relancer l'exploit et aucune nouvelle entrée n'a été ajoutée au journal de l'une ou l'autre des machines virtuelles.
Andreas Unterweger

Réponses:

16

La version 9.04 a été prise en charge jusqu'au 23 octobre 2010. La vulnérabilité que vous avez trouvée a été signalée en août 2009. Il semble raisonnable que, puisque la version était toujours à jour et prise en charge à l'époque, l'ISO a été corrigé et ce que vous avez téléchargé était une version qui est n'est plus vulnérable.

De plus, vous semblez avoir très bien démontré qu'il n'est pas vulnérable. Après tout, vous avez essayé l'exploit et il semble qu'il ait échoué.

Pourquoi n'essayez-vous pas un nouvel exploit? Quelque chose comme CVE-2013-2094 qui devrait également affecter Ubuntu , par exemple.

terdon
la source
Il ne semble pas y avoir de module Metasploit pour CVE-2013-2094. Y a-t-il d'autres exploits avec les modules Metasploit qui pourraient fonctionner? exploit / linux / local / pkexec de 2011 semblait prometteur, mais donne les mêmes résultats que exploit / linux / local / sock_sendpage .
Andreas Unterweger
@AndreasUnterweger oh, désolé, je ne savais pas qu'il n'y avait pas de module. Je viens de trouver celui-ci au hasard en recherchant "élévation de privilèges". Quant à l' pkexecexploit, avez-vous vérifié la version de libpolkit-backend-1? La page vers laquelle vous liez indique que la vulnérabilité nécessite une version de celle-ci antérieure à 0.94-1ubuntu1.1.
terdon
Selon dpkg -s libpolkit2, la version installée est 0.9-2ubuntu1.
Andreas Unterweger
@AndreasUnterweger dans ce cas, je n'en ai aucune idée. Pardon. Vous feriez peut-être mieux de poser une question sur la sécurité de l'information , en demandant une combinaison spécifique d'exploitation et de distribution d'escalade de privilèges qui fonctionne.
terdon
@AndreasUnterweger et ThorbjørnRavnAndersen veuillez prendre cette discussion pour discuter . J'y ai déjà déplacé vos commentaires précédents.
terdon
1

Cela ne répond pas à votre requête spécifique, mais vous offre plutôt plus de choix privés pour montrer à vos étudiants ...

Vous voudrez peut-être également prendre en compte les deux configurations suivantes d'administrateur qui pourraient conduire à priv esc sur 'nix (il existe de nombreuses autres façons de mal configurer une boîte' nix qui pourrait permettre priv esc, veuillez donc considérer cela comme un appétit) ....

  1. binaires suid et guid appartenant au groupe racine / racine ( find / -uid 0 -perm -4000 -type f 2>/dev/nullet find / -uid 0 -perm -2000 -type f 2>/dev/null) et voir s'ils sont accessibles en écriture pour permettre à l'utilisateur à faible privilège de les modifier; le dossier dans lequel ils existent est accessible en écriture par votre bas utilisateur priv - pour une éventuelle injection de chemin de bibliothèque. Qu'en est-il des bibliothèques qu'ils utilisent - peuvent-elles être modifiées: vérifiez les valeurs des en DT_RPATH- DT_RUNPATHtêtes any et ELF dans les binaires en utilisant l'une des commandes suivantes:

    • objdump -x ...
    • readelf -a ...
    • scanelf (depuis PaX)
    • elfdump (du soleil)
    • readelf -a binary | grep PATH
  2. sudoers défauts

    • NOPASSWD - Un attaquant local pourrait utiliser cet accès pour augmenter ses privilèges au sein du système d'exploitation lorsque l'utilisateur oublie de verrouiller son écran

    • Exécutables manquants dans Sudoers - Certains exécutables du /etc/sudoersfichier n'existent pas. Si les exécutables sont créés, ils peuvent être exécutés via sudo en tant que root, ce qui permettrait une élévation de privilèges.

    • Entrées orphelines des Sudoers - Le /etc/sudoersfichier peut contenir un certain nombre d'entrées orphelines pour lesquelles aucun compte correspondant n'est configuré dans le /etc/passwdfichier. Si un utilisateur était créé avec l'un des noms orphelins, il fournirait à l'utilisateur un moyen d'élever ses privilèges à un accès root complet.

    • Certains programmes ne doivent pas être de type sudo vi, utiliser :eou Ctrl o et utiliser :wpour accéder /etc/shadow.

    • Commande mal pensée / incorrecte utilisée dans le fichier sudoers - je vois souvent httpddans sudoers - alors essayez en tant qu'utilisateur priv faible avec accès sudo d'exécuter uniquement cette commande ( sudo -lou sudo -llmontrera ce qu'un utilisateur peut faire): sudo /usr/bin/httpd -t /etc/shadowet regardez l'erreur.

    • les perms de fichiers des commandes et des fichiers mentionnés dans sudoers sont faibles - voir mon paragraphe précédent sur les binaires suid et guid appartenant à root

Richard Braganza
la source
btw vous pouvez également essayer le code original de Spender pour le module metasploit au cas où le module metasploit n'est pas tout à fait correct: grsecurity.net/~spender/exploits
Richard Braganza
Merci beaucoup pour la liste de ces articles. Cependant, je crains que les deux groupes d'articles nécessitent trop d'informations contextuelles et de contexte de la part des étudiants - ils connaissent à peine Linux à ce stade de leurs études. Je veux leur montrer que l'escalade de privilèges est une chose réelle et qu'ils devraient toujours corriger les systèmes dont ils sont / seront responsables. Ironiquement, je n'ai jusqu'à présent pas réussi à démontrer une escalade de privilèges réelle comme celle décrite ci-dessus. EDIT: Je vais jeter un œil au code de Spender, mais je manque actuellement de temps, malheureusement. Merci beaucoup pour le lien.
Andreas Unterweger