Kernel AODV Spoof Hello

Converted with HTML::WikiConverter::MediaWiki from my old phpwiki site

---

Alleï hackons un peu le bastringue...

Spoofing d'un paquet HELLO de AODV:
cf 5.2 & 6.9 of RFC:3561

hping2 --id 0 \
       --dontfrag \
       --udp --baseport 654 --keep --destport 654 \
       --spoof <IP SRC> \
       --ttl 1 \
       --data 20 \
       --file packet.raw \
       255.255.255.255

avec un fichier "packet.raw" qui contient les bytes suivants:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |R|A|    Reserved     |Prefix Sz|   Hop Count   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Destination IP address                    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Destination Sequence Number                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Originator IP address                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Lifetime                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      Type          2
      R             Repair flag; used for multicast.
      A             Acknowledgment required; see sections 5.4 and 6.7.
      Reserved      Sent as 0; ignored on reception.
      Prefix Size   If nonzero, the 5-bit Prefix Size specifies that the
                    indicated next hop may be used for any nodes with
                    the same routing prefix (as defined by the Prefix
                    Size) as the requested destination.
      Hop Count     The number of hops from the Originator IP Address
                    to the Destination IP Address.  For multicast route
                    requests this indicates the number of hops to the
                    multicast tree member sending the RREP.
                    **In case of HELLO message: 0**
      Destination IP Address
                    The IP address of the destination for which a route is supplied.
                    **In case of HELLO message: The node's IP address.**
      Destination Sequence Number
                    The destination sequence number associated to the
                    route.
                    **In case of HELLO message: The node's latest sequence number.**
      Originator IP Address
                    The IP address of the node which originated the RREQ
                    for which the route is supplied.
      Lifetime      The time in milliseconds for which nodes receiving
                    the RREP consider the route to be valid.
                    **In case of HELLO message: ALLOWED_HELLO_LOSS * HELLO_INTERVAL**

Par exemple pour annoncer la machine 10.11.12.13:

hping2 --id 0 \
       --dontfrag \
       --udp --baseport 654 --keep --destport 654 \
       --spoof 10.11.12.13 \
       --ttl 1 \
       --data 20 \
       --file packet.raw \
       255.255.255.255

avec un fichier "packet.raw" qui contient les bytes suivants: (forgé a l'aide de hexedit)

  02 00 00 00
  0A 0B 0C 0D
  00 00 00 01
  0A 0B 0C 0D
  00 00 0B B8

Si on se sert de cette méthode, Ethereal confirme que les paquets spoofés sont bit à bit égaux avec ceux envoyés par kernel_aodv

Remarques

• hping accepte aussi un --sign "data" plutot que de passer par un fichier mais specifier
  --sign $'\x02\x00...'
  ne marche pas car le char null emm... le bazar
• pour surveiller la table AODV je regarde /proc/aodv/route_table
• j'essaye aussi de lancer kernel_aodv par modprobe car le script /etc/init.d/kaodv gèle un peu trop de params à mon goût dans ce cadre-ci.
• Il me semble que d'après le draft le daemon n'est pas obligé d'intégrer l'info HELLO venant des voisins.

Essai réalisé au laboratoire de Bombolong

Configuration

• le client A est configuré comme s'il l'avait été par DHCP servi par B
  • IP 10.3.56.77 NETMASK 255.255.255.255
  • route add 10.3.56.74 eth1
  • route add default gw 10.3.56.74
  • PAS de AODV
• la machine B
  • IP 10.3.56.74
  • KAODV
• la machine C
  • broadcast des HELLO forgés "venant de A"
    D ne voit pas ces paquets
    B voit ces paquets
    c'est le but recherché!!
• la machine D
  • IP 10.2.206.108
  • KAODV

Résultats

Si D veut pinger A, ça marche!
D'après ethereal sur B voici ce qui se passe:

• D envoie un RREQ pour trouver A
• B envoie un RREP a D pour dire qu'il peut joindre A via B
• D ajoute à sa table que A est à 2 hops via B
• D icmp echo request à A via B
• B relaye echo request
• A icmp echo reply à D via B
• B relaye echo reply
• D est content et moi aussi :-)

Remarques

• DHCPd est-il capable de configurer A avec le bon tunnel IPA-IPB?
• kaodv semble travailler au dessus de la pile UDP/IP car il broadcast sur 255.255.255.255 qui n'est pas accessible d'apres le contenu de la table de routage et lorsque je forge les paquets HELLO je dois ajouter cette route sinon Network unreachable!
• la machine qui génère les paquets HELLO par hping ne voie pas ses propres paquets, ce qui est assez gênant si on veut qu'une machine complète ses routes elle-même.
  C'est logique il faut s'assurer que l'interface "lo" soit gérée par AODV (pas de aodv_dev=...) et l'utilise effectivement (use_lo=1) pour que ça marche.
  cf KernelAodvHack pour plus de détails.
• physiquement lors du test les machines C et D étaient une même machine ce qui garanti, vu la remarque précédente, qu'effectivement D ne reçoive pas le message HELLO émis par C.

Variations sur un même thème

Altérations des paquets HELLO envoyés à B: (on casse le draft AODV et on regarde comment se comporte KAODV)

• Le spoof de l'IP source dans l'en-tête IP est nécessaire pour que l'information "next hop" soit correcte dans la table de routage d'AODV.
• La destination ne doit pas être nécessairement un broadcast, on peut envoyer le message à un noeud bien précis uniquement.
• Bref seul compte le payload AODV (les 20 bytes de data) et l'adresse source du paquet.
• On peut mettre le champ IP SRC à 0, vu qu'il n'y a pas eu de message RREQ à l'origine de ce RREP, c'est l'IP DST qui est enregistrée dans la table AODV, destination pour laquelle une route est proposée.
  Le champ IP SRC n'est nécessaire que pour forwarder un message plus loin, ce qui nécessite un TTL>1 que nous n'avons pas dans ce cas-ci.
• je n'ai pas très bien compris l'usage du "sequence number" et plus spécifiquement dans un paquet HELLO, bien que cela ne semble pas très critique...
  Cela semble indiquer à AODV quelle information choisir s'il en reçoit 2 contradictoires de 2 sources différentes, il prendra celle de séquence la plus élevée.
• on peut jouer sur le Lifetime pour persister dans la table plus longtemps que les 3000ms par défaut des messages envoyés par KAODV mais à vérifier tout de même lorsque d'autres paquets non AODV sont émis et interceptés par AODV pour mise à jour de la table de routage...