e-Construction : Mon cyber-journal perso

Il y a quelques semaines, suite à l'agitation qui a entouré la découverte de la vulnérabilité de cache poisoning des serveur DNS, un ami m'a envoyé une capture réseau (fichier pcap) de la sortie Internet où il bosse afin que je jette un coup d'œil pour voir s'il y a d'éventuels trucs louches (tentatives d'attaques ou signes de compromission). La taille de la capture est de presque 120 Mo sur moins d'une heure...ça travail fort chez eux :)

Alors, je lance la capture avec wireshark, et après quelques secondes il s'arrête en me disant qu'il y a un paquet avec une taille anormale.
Laissons tomber les interfaces graphiques et voyons en noir et blanc :)

Voyons tout d'abord les informations sommaires de la trace en question :

$ capinfos trace.pcap capinfos: An error occurred after reading 77202 packets from "trace.pcap": File contains a record that's not valid. (pcap: File has 2870302190-byte packet, bigger than maximum of 65535)

Humm...un paquet de 2870302190 octets, plus de 2.5 Go !!! ça sent le fichier corrompu.

Alors, peut être que dans le monde magnifique d'Internet, il y a des petits outils qui nous réparent ce type de problème...allo... Google ? j'ai besoin d'aide :)
Malheureusement, pas grand chose pour les premières pages, uniquement des gens qui se plaignent (si parmi vous, quelqu'un a un petit lien, je suis preneur :)). Mais je trouve un lien sur un blog de mon top 3 de meilleurs blogs.
Même pas ici...Richard ne fait que constaté et apparemment ne cherche pas à aller plus loin...dommage.

Je fait quoi maintenant ? je laisse tomber ?
Ce n'est pas vraiment important...mais je ne peux pas m'empêcher d'essayer de voir de plus près si je ne peux pas tirer quelque chose de cette trace (la partie corrompue).

Tout d'abord, il faut isoler le bon du mauvais :)... se taper chaque fois, avec tshark ou tcpdump, presque 30s pour arriver aux paquets qui nous intéressent est une perte de temps. (si quelqu'un connait une option pour allez directement à un paquet donné ça m'évitera la gymnastique qui suit)

On prend la partie valide :

$ tshark -c 77201 -r trace.pcap -w trace_ok.pcap

On obtient une trace de 60289623 octets....il suffit maintenant de copier à partir du 60289624 ème octet en utilisant "dd" :

$ dd bs=60289623 skip=1 if=trace.pcap of=trace_fail.pcap

On a notre fichier trace à traiter, avec une taille de 62896232 octets
On remarquera en passant que les deux parties sont presque de la même taille.
Mais à ce niveau, on a un petit problème, voyons ce que donne tshark :

$ tshark -r trace_fail.pcap
tshark: The file "trace_fail.pcap" isn't a capture file in a format TShark understands.

Si c'était le premier message d'erreur ça serais normal...mais là c'est le format du fichier obtenu qui est en cause. D'accord, voyons la structure d'une trace pcap. le fichier pcap.h nous dit ça entre autres :

struct pcap_file_header {
bpf_u_int32 magic;
u_short version_major;
u_short version_minor;
bpf_int32 thiszone; /* gmt to local correction */
bpf_u_int32 sigfigs; /* accuracy of timestamps */
bpf_u_int32 snaplen; /* max length saved portion of each pkt */
bpf_u_int32 linktype; /* data link type (LINKTYPE_*) */
};

Il faudra alors ajouter le pcap_file_header, 24 octets au début du fichier (pas le temps de me casser la tête ... on utilisera ceux du fichier valide) :
Pour ça "xxd" est là :

$ xxd trace_fail.pcap | xxd -r -s 24 > trace_bad.pcap (ajouter le header, des 0)
$ echo '00: d4c3 b2a1 0200' | xxd -r - trace_bad.pcap (modifier le header)

Maintenant c'est reconnu comme trace pcap, mais on doit commencer à travailler les paquets pour qu'ils soient valides.
La structure de l'entête de chaque paquet est du genre :

/*
* Each packet in the dump file is prepended with this generic header.
* This gets around the problem of different headers for different
* packet interfaces.
*/
struct pcap_pkthdr {
struct timeval ts; /* time stamp */
bpf_u_int32 caplen; /* length of portion present */
bpf_u_int32 len; /* length this packet (off wire) */
};

On va utiliser la même valeur du "ts" que dans la trace valide et mettre une valeur commune pour "caplen" et "len".
on met pour tous les packets ts = "0400 0000 0000 0000 0000 ffff 0000 0100 0000 e203 8748 cf24 0800"

Patchons le premier paquet (le paquet 77202 de la trace initiale) :

$ echo '06: 0400 0000 0000 0000 0000 ffff 0000 0100 0000 e203 8748 cf24 0800' | xxd -r - trace_bad.pcap

C'est reconnu comme paquet, mais apparemment les champs sont bousillés aussi...modifiant ce qui parait sûr ou fort probable :

$ echo '38: 0800' | xxd -r - trace_bad.pcap (type de protocole : IP)

$ echo '3a: 4500' | xxd -r - trace_bad.pcap (version, longueur du header et service diff)

Et maintenant ?.... toujours des champs avec du n'importe quoi...je crois que c'est mort pour la récupération...c'est du vrai corrompu :)
j'ai renommé le fichier en trace_corrupt_to_resolv_one_day.pcap :)...un jour, avec de la corrélation, de la IA,...etc on trouvera une réponse peut-être :)


Et alors, pourquoi ce billet me diriez-vous ?!!
En fait c'était amusant et intéressant pour moi, et j'espère que quelques uns le trouveront aussi...sinon, je compte aussi utiliser mon blog comme aide-mémoire accessible de partout, d'ailleurs je vais commencer de poster des billets sur des outils que je test chaque fois pour mes besoins professionnels et personnels.