p2a
1.0.0
Ce projet vise à créer un outil facile à utiliser qui analysera un fichier pcap pour renvoyer toute ambiguïté trouvée dans les paquets TCP. Nous travaillons actuellement sur la mise en œuvre des analyses UDP et ARP.
Contour:
Contribuer : tout commentaire/idée/contribution est la bienvenue.
make
./p2a -v ./pcap_files/some_pcap_file.pcap -s results.json $ ./p2a -h
Usage: ./p2a [OPTIONS] FILE
-h,--help: display this help message
-v,--verbose: verbose option
-d,--debug: debug option
-x,--exclude OPTIONS: exclude some possible ambiguities from analysis
--exclude ret,mac,ttl
ret: exclude retransmission analysis
mac: exclude MAC addresses analysis
ttl: exclude TTL analysis
-s,--save FILENAME: saves results to file FILENAME
JSON format - FILENAME should contain the JSON extension
Examples:
./p2a -v ./pcap_files/some_pcap_file.pcapng
./p2a --exclude mac,ttl --verbose my-pcap-file.pcap -s results.json
Je viens d'ajouter l'option permettant d'enregistrer tous les résultats dans un fichier JSON. Pour ce faire, on peut utiliser l'option --save file.json . Il enregistre toutes les sessions dans ce fichier, que des ambiguïtés y aient été trouvées ou non. Je travaille actuellement sur un moyen de restituer joliment le fichier JSON dans un fichier HTML (en utilisant du JavaScript).
SHA(IP, Port)
Nous avons rendu le script sha disponible à des fins de débogage. Il prend en argument une adresse IP et un numéro de port et renvoie le hachage SHA1 de (IP|Port). Cette valeur est utilisée comme identifiant de session dans le script p2a .
make sha
./sha -h
Usage:
./sha IP PORT
./sha 127.0.0.1 12345
IP: 127.0.0.1
Port: 12345
SHA1: 21bf549a8095063f49cff573e689b6b10365f4c8 Adresses IP et whois
Si une session est suspecte, il peut être utile de savoir à quoi elle se rapporte. Pour ce faire, on peut utiliser Wireshark et appliquer un filtre d'affichage pour afficher uniquement la session donnée.
Une approche plus simple peut consister à utiliser whois pour savoir à qui appartient l’adresse IP.
Pour utiliser whois avec toutes les adresses IP du fichier de capture :
for ip in $( tshark -r file.pcapng -T fields -e ip.dst -e ip.src | egrep -o " [0-9]+.[0-9]+.[0-9]+.[0-9]+ " | sort | uniq ) ; do whois $ip | egrep " ^[Oo]rgani[sz]ation " ; doneSi
tsharkne fonctionne pas, voici un script C qui fera la même chose.
Le champ Time To Live (TTL) d'un paquet IP correspond à la durée pendant laquelle ce paquet est « autorisé » à voyager sur le réseau avant d'être abandonné par les routeurs. Il s'agit d'une valeur de 8 bits qui est généralement réduite de un à chaque saut.
Selon la page de Cisco sur l'attaque par expiration TTL :
"Lorsqu'un périphérique IOS reçoit un paquet avec une valeur TTL inférieure ou égale à un, un message ICMPv4 Type 11, Code 0 est envoyé par un périphérique IOS, ce qui entraîne un impact correspondant sur le CPU . Cet impact se produit car plus de CPU le traitement est nécessaire pour répondre (en utilisant des paquets dont le TTL est dépassé) aux paquets avec des valeurs TTL inférieures à un plutôt que pour simplement transmettre un paquet avec une valeur TTL supérieure à un.
"Le comportement d'expiration du TTL crée un vecteur d'attaque par déni de service (DoS) contre les équipements réseau. Les périphériques réseau sont spécialement conçus pour transmettre les paquets ordinaires aussi rapidement que possible. Lorsque des paquets d'exception sont rencontrés, tels que ceux dont les valeurs TTL expirent, des quantités variables d'efforts sont déployés par un routeur pour répondre de manière appropriée.
Analyse/Code :
Dans utils.c , nous avons défini un TTL_THRESHOLD (=10 pour l'instant). Si la durée de vie d'un paquet est inférieure à cette valeur, un indicateur est levé pour indiquer que la durée de vie est faible. Si trop de ces drapeaux sont levés, il pourrait s'agir d'une attaque d'expiration TTL.
L'exemple de fichier pcap (contenant un paquet avec une durée de vie faible) a été capturé à l'aide des scripts situés dans le répertoire ./attack_scripts/low_ttl .
L'ARP Poisoning consiste à tromper un hôte en lui faisant croire que nous sommes la passerelle par défaut . La victime demande régulièrement à la passerelle par défaut son adresse MAC (protocole ARP). Mais un attaquant peut envoyer à la victime des paquets indiquant que la passerelle par défaut se trouve à une autre adresse MAC (l'adresse MAC de l'attaque par exemple). L'attaquant doit simplement envoyer ces paquets « assez régulièrement » pour que la victime « élimine » les vrais messages de la passerelle par défaut .
Cela peut permettre à l'attaquant de procéder et d'attaquer la victime de plusieurs manières : homme du milieu, DoS, trou noir, ...
Exemple:
L'adresse IP de la victime est 192.168.10.2 et la passerelle par défaut est 192.168.1.1 :
sudo arpspoofing -i wlan0 -t 192.168.10.2 192.169.1.1 L'attaquant continuera à envoyer à la victime des paquets ARP indiquant que 192.168.1.1 se trouve à l'adresse MAC de l'attaquant. De cette façon, la victime enverra ses paquets (visant Internet) à l'attaquant, qui ne les redirigera pas (option -r pour les rediriger).
Analyse/Code :
Pour l'analyse, puisque nous regardons uniquement les paquets IP (pour l'instant), p2a enregistre dans une liste chaînée toutes les paires (MAC address, IP address) qu'il rencontre. Lors de la vérification d'une nouvelle paire donnée, il parcourt la liste chaînée et renvoie une erreur si l'adresse IP est déjà associée à une autre adresse MAC.
Pour l'exemple ci-dessus, notre script détecterait que 192.168.1.1 ( passerelle par défaut ) est associée à deux adresses MAC différentes : la vraie, jusqu'à ce que l'attaquant entre et dise à la victime qu'il s'agit de la passerelle par défaut et que son adresse MAC obtient associé à la passerelle par défaut (du point de vue de la victime).
Chaque octet de données envoyé dans une connexion TCP est associé à un numéro de séquence . Ceci est indiqué dans le champ du numéro de séquence de l' en-tête TCP .
Lorsque le socket de réception détecte un segment de données entrant, il utilise le numéro d'accusé de réception dans l'en-tête TCP pour indiquer la réception. Après avoir envoyé un paquet de données, l'expéditeur démarrera un temporisateur de retransmission de durée variable. S'il ne reçoit pas d'accusé de réception avant l'expiration du délai, l'expéditeur supposera que le segment a été perdu et le retransmettra.
Nous pouvons voir une retransmission TCP lorsqu'un autre paquet possède les mêmes numéros d'accusé de réception et de séquence que le paquet actuel.
Les retransmissions TCP sont assez courantes et peuvent être tout à fait normales (si un paquet est retransmis parce qu'il a été légitimement perdu), mais peuvent aussi être le signe d'un problème sur le réseau ou sur une communication.
L'exploit de chevauchement de fragments IP se produit lorsque deux fragments contenus dans le même paquet IP ont des décalages qui indiquent qu'ils se chevauchent en termes de positionnement dans le paquet. Cela pourrait signifier que le fragment A est complètement écrasé par le fragment B ou que le fragment A est partiellement écrasé par le fragment B. Certains systèmes d'exploitation ne gèrent pas correctement les fragments qui se chevauchent de cette manière et peuvent générer des exceptions ou se comporter d'autres manières indésirables. à la réception de fragments superposés. C'est la base de l' attaque en forme de larme . ( de Wikipédia )
Des fragments qui se chevauchent peuvent également être utilisés pour tenter de contourner les systèmes de détection d'intrusion . Dans cet exploit, une partie d'une attaque est envoyée sous forme de fragments avec des données aléatoires supplémentaires ; les fragments futurs peuvent écraser les données aléatoires avec le reste de l’attaque. Si le paquet terminé n'est pas correctement réassemblé au niveau de l'IDS, l'attaque ne sera pas détectée.
Attaque en forme de larme : implique l'envoi de fragments IP mutilés avec des charges utiles surdimensionnées et superposées à la machine cible.
PAS ENCORE MIS EN ŒUVRE
Si nous observons plusieurs valeurs TTL pour une session donnée, cela peut signifier que la route a changé, ce qui signifie que les paquets ne suivent pas le même chemin à la fin de la connexion qu'au début. Cela pourrait être dû à de véritables changements extérieurs, mais cela pourrait également signifier qu'un attaquant modifie l'itinéraire emprunté par les paquets (pour effectuer une attaque MiTM par exemple).
Cependant, la plupart du temps, une session a deux ou trois valeurs TTL différentes tout au long de la connexion : la plupart du temps, le client et le serveur n'utilisent pas les mêmes valeurs TTL initiales.
Le script renvoie une erreur s'il existe plus de deux valeurs TTL différentes pour une session donnée.
| Annuaire | Description/contenu |
|---|---|
./attack_scripts | Scripts simples pour tester et enregistrer certaines ambiguïtés TCP (usurpation d'identité, faible TTL) |
./pcap_files | Fichiers PCAP pour tester p2a |
./tests_libpcap | Deux scripts pour tester et commencer à utiliser libpcap |
libpcappcappcap à la fin de la page Webtcpdumplibpcaplibpcap en Cpcap.h
