Technique de hacking de base : Floods et Scans

Salut a tous, j’ai retrouvé en nettoyant mon hdd une mini-doc que j’avais écrite pour un stage présentant les attaques de base sur le réseau car beaucoup de machines y étaient encore sensibles. Pour faire bouger le DSI, je lui avais donc fait le descriptif des attaques de base en question. Brute flooding, SynFlood, PingOfDeath, Overlapping Fragment Attack, SynScan, FIN/X-MAS/NULL ou scans RST, Scan connect, attacks sont les attaques abordées avec, pour chacune, un descriptif complet et une parade efficace. Entrez dans le bon vieux monde des doom packets 😀

Brute Flooding (smurf pour les intimes)

Description :
– Saturer le pc distant
– Surcharger la bande passante sur le réseau de la machine
– Envoyer beaucoup de requêtes PING à la victime, avec des paquets contenant beaucoup de données.

Si on envoie un ping sur l’adresse de broadcast, toutes les machines du réseau y répondent par un reply. Comme se flooder soi-même n’est pas d’une immense utilité, il faut trouver un moyen de faire répondre tous ces systèmes à qui on l’entend, car cela représente un gros potentiel. Pour ce faire, il suffit d’envoyer un paquet PING echo spoofé contenant l’adresse de la victime comme source et la broadcast comme destinataire. Ainsi, chaque machine du réseau recevra un ping qu’elles croiront venir de la machine de la victime et y répondront. En envoyant beaucoup de paquets spoofés, la bande passante de la victime est prise d’assaut de manière exponentielle avec le nombre de systèmes connectés au réseau. Cette attaque s’appelle communément un smurf.

Contre-attaque :
– Limite des connections par ip
– Drop des connections sans réponse
– Drop de l’icmp venant de l’interface Wan

SYN flood

Descriptif :
Ici, l’attaquant floode la victime avec beaucoup de paquets SYN spoofés (d’adresses prises au hasard). La victime va donc répondre à ces paquets SYN par un paquet ACK/SYN en attente d’un paquet ACK, comme la coutume le veut. Puisque les réponses ne viendront pas, la machine gardera dans la pile les informations sur chaque host qui a demandé l’initialisation d’une connexion. Pour que ces connexions soient enlevées de la queue, il faut qu’elles timeout, ce qui peut prendre relativement longtemps selon la configuration. Par conséquent, au fur et à mesure, tous les ports seront en attente d’un paquet ACK qui ne viendra pas. Au final, tous les ports de la machine étant en attente, aucune nouvelle requête ne peut être traitée.

Contre-attaque:
– Limitation du nombre de connections simultanées
– Reduction du timeout

Ping of the Death

Descriptif :
Dans les spécifications du protocole ICMP, les paquets echo n’ont été conçus que pour contenir 216 octets de données dans le cas des requêtes et réponses ICMP, seuls les en-têtes importent, aucun réel message n’est nécessaire. Un DoS très connu est simplement l’utilisation de minimum 65 537 (= 216 + 1) octets de données. Le système recevant le message paniquera à la réception du paquet et crashera. Ceci dit, la plupart des systèmes sont maintenant protégés contre cette attaque rudimentaire 😉

Contre-attaque :
– Filtrage des paquets icmp de plus de 1472 octets
– Arrêter d’utiliser Windows 98, Debian 2, et tout autre système anté 2000 😀

Overlapping Fragment Attack

L’attaque par Overlapping Fragment est une variation de la très vieille et très célèbre Teardrop Attack. Teardrop envoyait des paquets UDP fragmentés ayant des fragments se recouvrant, ce qui provoquait à l’époque le crash de la plupart des machines n’ayant pas prévu ce type de problème. Dans le cas de l’Overlapping Fragment, le but est de passer outre les règles d’un firewall. Pour des raisons de performance et parce que finalement seul le header du premier fragment d’un paquet va déterminer son utilisation finale, les firewalls ont pris l’habitude de ne vérifier que les premiers fragments d’une séquence TCP. Seulement, il n’a pas été prévu que les paquets suivants pouvaient également définir la destinée du paquet. Le réassemblage du protocole TCP ayant été mieux étudié, il prévoit de réécrire les zones se chevauchant s’il y en a. Mais, encore un oubli : l’offset IP est valable à partir de la fin de son header, c’est-à-dire au début du header de la couche supérieure. Par conséquent, au début du header TCP. Au final on peux donc by passer un firewall en envoyant un paquet fragmenté avec, au premier fragment, une destination autorisée et pour les fragments suivants “ce que l’on veut”

Contre-attaque :
– En premier lieu, cette attaque peut être bloquée par le routeur en supprimant les paquets d’offset 1 et 2, ou les paquets ayant un offset 0 et un nombre d’octets inférieur à la longueur du header du protocole associé. Tout anodine qu’elle puisse paraître, cette attaque est très rarement prise en compte malgré le fait qu’elle permet d’anéantir les bons efforts des firewalls…

Scan connect

Le scanning est un grand enjeu de la sécurité informatique. Une intrusion quelle qu’elle soit doit être préparée un minimum. La plupart des services tournent sur des ports standards, documentés, etc… Une vraie mine d’or pour les hackers donc. La façon la plus simple de scanner les ports d’un système est d’essayer d’ouvrir une connexion sur chaque port et donc de déterminer si la connexion est refusée ou non.

Contre-attaque :
– Limiter le nombre de connections par ip

Scan SYN ou Half-Opened

Technique moins voyante, ne pas établir une connexion complète en omettant la troisième étape de l’initialisation de la connexion. En fait, on envoie un paquet SYN sur le port concerné. Si le port est en écoute, un paquet SYN/ACK est renvoyé, le port est donc ouvert. On envoie un paquet RST pour terminer la connexion (nécessaire car si on scanne beaucoup de ports sans RST, on peut DoS la victime de la même façon qu’un Flood SYN pourrait le faire). Cette technique qui n’est pas non plus très compliquée évite l’ouverture complète de la connexion et ainsi le log de l’IP par la majorité des services ayant accepté une connexion.

Scans FIN/X-MAS/NULL, ou scans RST

Ces trois techniques préfèrent envoyer des paquets qui n’ont aucun sens lorsque que la connexion est fermée et s’appuyer sur les différences d’interprétations du serveur. Effectivement, si un paquet quelconque est envoyé sur un port ouvert, il sera ignoré puisque ce port attend avant toute chose un paquet SYN. Par contre, si le port est fermé, la RFC 793 prévoit le retour d’un paquet RST. En utilisant cette différence, on peut déterminer les ports ouverts et les ports fermés. Le scan FIN envoie un paquet FIN, le scan X-MAS envoie un paquet FIN/URG/PSH et le NULL, vous l’avez compris, envoie un paquet avec tous les flags TCP à off. Attention, cette technique ne marche pas sur certains OS Microsoft, car le géant de l’informatique n’aimant pas à faire les choses comme tout le monde, il ne suit tout simplement pas la RFC…

Contre-attaque pour les Scans
– Shroud ou/où ? “Tout mes ports sont fermés !”
– Injection de SYN/ACK dans tous les paquets ou/où ? “Tout mes ports sont ouverts ! ”
– Suppression des paquets RST
La plupart des scans reposent sur les paquets RST. Mais ces paquets n’ont pas grand intérêt, en effet ils ne servent que pour +/- 1% des connections et leurs seul but est de gagner quelques millisecondes pour fermer un port. On peut donc décider sans trop de remords de s’en passer et donc supprimer l’envoi de paquets RST.
– Fixer MTU sur interfaces

Inform@tiquement
Manu404

One thought on “Technique de hacking de base : Floods et Scans

  1. Chimay8

    Yop,
    C’est toujours aussi intéressant de te lire…

    Bonne continuation à toi le carolo! ^^

    :p

    Reply

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s