HSC
Cabinet de consultants en sécurité informatique depuis 1989 - Spécialisé sur Unix, Windows, TCP/IP et Internet
Mode texte : accès au contenu de la page
Hervé Schauer Consultants
Vous êtes ici : Accueil > Ressources > Brèves > Signatures MD5 dans TCP
Accéder au : Site HSC des formations
Télécharger le catalogue des formations
Recherche :  
English version
   Services   
o Domaines de compétences
o Conseil & Expertise
o Prestations ISO 27001
o Audit & Évaluation
o Tests d'intrusion
o Tests de vulnérabilités (TSAR)
o Analyse Forensique
o Certification ARJEL
o Formations
o E-learning
   Conférences   
o Agenda
o Interventions passées
o Tutoriels
   Ressources   
o Index thématique
o Brèves
o Présentations
o Cours
o Articles
o Outils (téléchargement)
o Veille en vulnérabilité
   Société   
o Hervé Schauer
o Equipe
o Offres d'emploi
o Références
o Historique
o Partenariats
o Associations
   Presse et
 communication
 
 
o Newsletter HSC
o Bulletin juridique HSC
o Revue de presse
o Communiqués de presse
o Publications
   Contacts   
o Coordonnées
o Requêtes particulières
o Accès à nos locaux
o Hôtels proches de nos locaux
|>|Signatures MD5 dans TCP  

par Nicolas Jombart - Franck Davy (14/08/2003)



Les signatures MD5 des segments TCP

- Franck Davy - Nicolas Jombart -

Une précédente brève [1] sur le filtrage du protocole de routage BGP4 évoquait
la sécurisation de ce protocole entre deux entités par l'usage de « mots de
passe MD5 ». Cette option de sécurité a pour particularité de s'appuyer non pas
sur le protocole applicatif BGP, mais sur le protocole de transport sous-jacent,
à travers une option TCP [2]. 

En effet, à la différence d'autres protocoles de routage, BGP ne s'appuie pas
sur un numéro de protocole IP, mais constitue une application s'appuyant sur
TCP, par conséquent identifiée par un port : 179/tcp. 

Cette brève n'a pas pour objectif d'étudier BGP et ses implications en terme de
sécurité, mais s'attarde sur une option de sécurité dont il serait regrettable
de se priver, dans la mesure où la structure même d'Internet repose sur ce
protocole -- ce qui doit suffire à se rendre compte que toute relative faiblesse
est dangereuse.

Les protocoles de sécurisation usuels de niveau réseau (via IPsec) ou session
(via SSL/TLS) peuvent également être employés, dans la mesure où ils sont
complémentaires de la solution présentée dans cette brève. 
Cette dernière présente néanmoins l'avantage d'être relativement simple, à
défaut d'être particulièrement robuste, dans la mesure où la sécurité de
l'ensemble repose sur la connaissance d'un simple mot de passe.

Cette méthode s'appuie sur l'utilisation de la fonction de hachage MD5 [3],
indexée par une clef secrète. Elle permet d'assurer l'authenticité de chaque
segment TCP relatif à une session BGP, et l'authentification indirecte des
parties. Un mécanisme de signature similaire est employé pour OSPF, HSRP, et
d'autres protocoles qui disposent de cette fonction.


L'option de signature TCP MD5 est décrite dans le RFC 2385. L'empreinte est
calculée sur la base de valeurs constantes - au cours du processus de routage -
du segment TCP, du paquet IP et d'un secret partagé entre les routeurs.
Quand un routeur émet un paquet IP relatif à BGP, la signature est calculée,
puis vérifiée de l'autre coté par le peer BGP, et réciproquement.


Le calcul de la signature est effectué, par application successive de la
fonction à sens unique MD5 sur les éléments suivants :

- le pseudo-header TCP (*) -- défini dans la fameuse RFC 793 :
  · adresse IP source ;
  · adresse IP destination ;
  · le protocole IP, ajusté avec des 0 ;
  · la taille du segment.
- le header TCP
  · sans les options ;
  · avec un checksum à 0 ;
- les données, pour un segment de données TCP ;
- la clef secrète -- préalablement échangée à travers un canal sûr.


(*) Pseudo-header TCP posant notamment problème avec la NAT dans le cas d'IPsec
, dans la mesure où la traduction d'adresses IP a des répercutions au niveau
transport, par l'intermédiaire du pseudo-header TCP utilisé pour le calcul de la
somme de contrôle sur les en-têtes TCP -- et qui explique notamment pourquoi
seul le protocole IPsec ESP en mode tunnel supporte la NAT !


L'option s'insère donc dans un segment TCP, de la façon suivante :

Transmission Control Protocol, Src Port: bgp (179), Dst Port: 11035 (11035) (...)
    Source port: bgp (179)
    Destination port: 11035 (11035)
    Sequence number: 1994504965
(...)
    Window size: 16265
    Checksum: 0x7a5c (correct)
    Options: (20 bytes)
        TCP MD5 signature                  <===
        EOL
Border Gateway Protocol
    KEEPALIVE Message
        Marker: 16 bytes
        Length: 19 bytes
        Type: KEEPALIVE Message (4)


Evidemment, cette méthode n'est pas, d'un point de vue cryptographique, la
panacée, mais constitue une brique de sécurisation optionnelle et à moindre
effort. Il est naturellement plus satisfaisant, sans toutefois être réaliste,
d'utiliser un protocole comme IPsec (hors clef partagée), afin que la sécurité
du protocole ne repose pas sur un simple mot de passe statique.

De plus, une telle relation de confiance en "Peer to Peer" n'exclut
naturellement pas l'apparition de mauvaises routes, et donc le cassage
momentané de la table de routage, des problèmes toujours résolus avec un
téléphone et non par un système automatique aussi perfectionné soit-il...

Les problématiques d'authentification et de confiance dans la table de routage
mondiale, sont très complexes. Un projet intéressant tente d'ailleurs, parmi
d'autres, de proposer une solution [4].
L'avantage de cette technique est d'être « opportuniste », à la manière du
protocole SMTP-TLS, comme l'ont montré les résultats du sondage informel sur le
sujet [5].

Enfin, utiliser MD5 pour BGP (comme pour HSRP, OSPF, etc.) ne doit pas faire
oublier les mesures de sécurisation plus standards, à savoir le filtrage IP des
paquets à destination du routeur, ou encore les options de filtrage plus
spécifiques à ces protocoles [1], afin de se protéger contre les attaques
décrites dans le papier suivant [6].


Annexe : Ce programme en perl permet, via l'utilisation de socket Divert sur
une machine FreeBSD, d'ajouter cette option TCP à des fins de test, ou
d'utiliser zebra et un routeur avec authentification MD5 des sessions BGP.
Le programme intercepte le paquet avant de l'envoyer sur l'interface, le
modifie et le réinjecte.

(Ne marche que sous FreeBSD, et uniquement dans un sens)

Mise à jour : FreeBSD peut maintenant gérer directement cette signature 
(toujours en sortie) en utilisant l'interface prévue pour IPsec et setkey(8).


#!/usr/bin/perl

# TCP MD5 Signature implementation using FreeBSD divert sockets
# Greets to atrak for Net::Divert
# $Id: tcp-md5.tip,v 1.12 2005/02/21 16:29:50 jombart Exp $

# ipfw add divert 9999 all from any to any 179

use Net::Divert;
use NetPacket::IP qw(:protos);
use NetPacket::TCP;
use Digest::MD5 qw(md5);
use strict;

my $key = 'foobar';

# Divert the packets
my $divert = Net::Divert->new('localhost', 9999);
$divert->getPackets(\&addsig);

sub addsig {
  my($packet,$fwtag) = @_;

  # decode
  my $ip = NetPacket::IP->decode($packet);
  return undef unless $ip->{proto} == IP_PROTO_TCP;
  my $tcp = NetPacket::TCP->decode($ip->{data});

  # No signature with SYN packets
  if($tcp->{flags} & SYN) {
    $divert->putPacket($packet,$fwtag);
    print "SYN\n";
    return 1;
  }

  my $tosign = "";
  my $ctx = Digest::MD5->new;

  # compute pseudo-header
  $tosign = pack('a4 a4 C C n',
                 (gethostbyname($ip->{src_ip}))[4], (gethostbyname($ip->{dest_ip}))[4],
                 0, IP_PROTO_TCP, $ip->{len}); 

  $ctx->add($tosign);

  # Add option length to header length (5 words)
  # do it _before_ recomputing TCP header
  $tcp->{hlen} += 5;

  # add the TCP header with a null checksum
  # code from NetPacket/TCP.pm
  my $tmp = $tcp->{hlen} << 12;
  $tmp = $tmp | (0x0fc0 & ($tcp->{reserved} << 6));
  $tmp = $tmp | (0x003f & $tcp->{flags});

  $tosign = pack('n n N N n n n n',
                  $tcp->{src_port}, $tcp->{dest_port},
                  $tcp->{seqnum}, $tcp->{acknum}, $tmp,
                  $tcp->{winsize}, 0, $tcp->{urg});

  $ctx->add($tosign);

  # add the data and the key
  $ctx->add($tcp->{data});
  $ctx->add($key);
  my $digest = $ctx->digest;

  # save existing option.
  $tmp = substr($tcp->{options},0,-1);
  # add the TCP option
  $tcp->{options} = $tmp . "\x13\x12" . $digest. "\x00\x00";

  # encode & reinject
  $ip->{data} = $tcp->encode($ip);
  $packet = $ip->encode;
  $divert->putPacket($packet,$fwtag);

}

# EOF
# Thanks to Charles Menzes for the packet samples


[1] Différentes formes de filtrage avec Cisco IOS - Nicolas Jombart.
    http://www.hsc.fr/ressources/breves/cisco-acl.html.fr

[2] Protection of BGP Sessions via the TCP MD5 Signature Option.
    http://www.ietf.org/rfc/rfc2385.txt

[3] The MD5 Message-Digest Algorithm.
    http://www.ietf.org/rfc/rfc1321.txt

[4] Secure BGP Project (S-BGP). 
    http://www.ir.bbn.com/projects/sbgp/

[5] Results of query on auth usage - Barbara Fraser.
    http://www.merit.edu/mail.archives/nanog/2002-06/msg00076.html

[6] Cisco Security Advisory: Cisco IOS Interface Blocked by IPv4 Packets.
    http://www.cisco.com/warp/public/707/cisco-sa-20030717-blocked.shtml




Dernière modification le 28 février 2005 à 15:07:31 CET - webmaster@hsc.fr
Mentions légales - Informations sur ce serveur - © 1989-2013 Hervé Schauer Consultants