Démonstration de vulnérabilité sur Ubuntu 9.04

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?

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.

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