Outils d'utilisateurs

Outils du Site


ndhquals2015:private

Table des matières

Private

Énoncé

“The quiet you are, the more you are able to ear”

Link: http://static.challs.nuitduhack.com/Private.tar.gz

Challenge

On a affaire un fichier pcapng :

  [plo@hyperion Forensics]$ file PrivateChannel.pcap.pcapng 
  PrivateChannel.pcap.pcapng: pcap-ng capture file - version 1.0

Un coup de Wireshark : on se retrouve principalement avec des paquets DNS, ICMP, STP (Spanning Tree), puis de l'ARP, du CDP (Cisco Discovery Protocol) et un seul paquet TCP.
Hum, voyons ce fameux paquet TCP :

  [plo@hyperion Forensics]$ tshark -r PrivateChannel.pcap.pcapng -x tcp
  0000  08 00 27 71 45 e4 c8 00 12 89 00 01 08 00 45 00   ..'qE.........E.
  0010  00 35 00 2a 00 00 3f 06 c8 0c c0 a8 00 32 c0 a8   .5.*..?......2..
  0020  32 0a 10 92 23 28 00 00 00 00 00 00 05 39 50 02   2...#(.......9P.
  0030  20 00 42 3f 00 00 43 44 41 49 53 49 57 69 6c 6c    .B?..CDAISIWill
  0040  57 69 6e                                          Win

\o/ Cool, on peut y lire la chaine CDAISIWillWin ! Allez, 100 points cadeaux, on valide le flag et… arf non, ce n'est bon, ça aurait été trop facile ! (Easter Egg :D ?)

Bon, continuons l'investigation du pcap : les paquets STP sont tous identiques, les DNS ne présentent aucune caractéristique particulière. Les paquets ICMP de type ping sont eux nettement plus intéressants :

 [plo@hyperion Forensics]$ tshark -r PrivateChannel.pcap.pcapng -Y "icmp.type==8 or icmp.type==0"
 376 616.966522000 192.168.50.10 -> 192.168.0.50  ICMP 98 Echo (ping) request  id=0x06ef, seq=1/256, ttl=64 
 378 617.965929000 192.168.50.10 -> 192.168.0.50  ICMP 98 Echo (ping) request  id=0x06ef, seq=2/512, ttl=64 
 379 617.990279000 192.168.0.50 -> 192.168.50.10  ICMP 98 Echo (ping) reply    id=0x06ef, seq=2/512, ttl=41 (request in 378) 
 395 641.491491000 192.168.0.50 -> 192.168.50.10  ICMP 98 Echo (ping) request  id=0x152c, seq=1/256, ttl=41 
 396 641.492213000 192.168.50.10 -> 192.168.0.50  ICMP 98 Echo (ping) reply    id=0x152c, seq=1/256, ttl=64    (request in 395) 
 479 796.186499000 192.168.50.10 -> 192.168.0.50  ICMP 42 Echo (ping) request  id=0x0000, seq=0/0, ttl=64 
 480 796.205229000 192.168.0.50 -> 192.168.50.10  ICMP 42 Echo (ping) reply    id=0x0000, seq=0/0, ttl=41 (request in 479) 
 481 796.297219000 192.168.50.10 -> 192.168.0.50  ICMP 42 Echo (ping) request  id=0x0000, seq=0/0, ttl=64 
 482 796.316115000 192.168.0.50 -> 192.168.50.10  ICMP 42 Echo (ping) reply    id=0x0000, seq=0/0, ttl=41 (request in 481) 
 [...]
 541 799.493438000 192.168.50.10 -> 192.168.0.50  ICMP 42 Echo (ping) request  id=0x0000, seq=0/0, ttl=64 
 542 799.512889000 192.168.0.50 -> 192.168.50.10  ICMP 42 Echo (ping) reply    id=0x0000, seq=0/0, ttl=41 (request in 541) 
 543 799.603936000 192.168.50.10 -> 192.168.0.50  ICMP 42 Echo (ping) request  id=0x0000, seq=0/0, ttl=64 
 544 799.623819000 192.168.0.50 -> 192.168.50.10  ICMP 42 Echo (ping) reply    id=0x0000, seq=0/0, ttl=41 (request in 543) 

Seuls les 5 premiers paquets ont les champs IDentifier et SEQuence number renseignés, les autres semblent suspects !

Dans Wireshark, en se balladant dans les paquets en question, on ne voit que très peu de différence entre les paquets et de temps en temps, une lettre apparait dans les octets du dump, plus précisément dans le champ IDentification de la couche IP.
On va filtrer les paquets de type Echo Request, il semble logique ce soit eux qui portent le message caché plutôt que les paquets Echo Reply. Un coup de Scapy :

 #!/usr/bin/env python2
 
 from scapy.all import *
 
 PCAPFILE='PrivateChannel.pcap.pcapng'
 
 res=""
 pcap = rdpcap(PCAPFILE)                                                                                                                                                                 
 for pkt in pcap:
     if (pkt.haslayer(ICMP) and pkt[ICMP].id == 0 and pkt[ICMP].type == 8):
          res += chr(pkt[IP].id)
 print res 

Arf, on se retrouve avec une erreur de Scapy qui semble ne pas apprécier notre fichier pcap-ng :

 scapy.error.Scapy_Exception: Not a pcap capture file (bad magic)

Internet nous indique qu'il faut lui donner un pcap à manger, on le convertit via editcap :

  [plo@hyperion Forensics]$ editcap -F libpcap PrivateChannel.pcap.pcapng PrivateChannel.pcap
  [plo@hyperion Forensics]$ file *pcap*
  PrivateChannel.pcap:        tcpdump capture file (little-endian) - version 2.4 (Ethernet, capture length 262144)
  PrivateChannel.pcap.pcapng: pcap-ng capture file - version 1.0

On change la variable PCAPFILE de notre script et :

  [plo@hyperion Forensics]$ ./icmp.py 
  "here is your flag : S3cr3t4g3nt

Ce coup-ci, ça semble être le bon flag ! On valide et hop, 100 points !

ndhquals2015/private.txt · Dernière modification: 2017/04/09 15:33 (modification externe)