Panoramisk / Le druide de la VoIP 

Vous n’avez probablement pas raté les articles sur les failles de certaines piles SIP dans des téléphones du marché¹. A la lecture des explications on peut vraiment se demander s’il est sérieux de supposer que ceci est lié à un bug logiciel est pas plutôt intentionnel.

En regardant de plus prêt à la cinématique de l’attaque² on peut rapidement arriver à la conclusion énoncée plus haut. Le protocole SIP a cet avantage d’autoriser une lecture simplifiée des échanges, mais également d’autoriser des attaques plus simples (voir le script Perl livré avec).

Lors de la mise en place d’une session, ici un appel, des messages sont échangés avant d’échanger effectivement les trames contenant le son, il est nécessaire notamment qu’un accord soit donné par le poste appelé, généralement piloté par un décroché. Ici, on voit rapidement qu’aucun accord n’a été donné par le téléphone situé à droite du tableau alors qu’il envoi des trames voix dans le flux RTP.

Dans la norme SIP³, le message 183 est défini comme permettant de fournir plus d’information sur la session à mettre en place, en aucun cas à considérer celui-ci comme établi:

The 183 (Session Progress) response is used to convey information
about the progress of the call that is not otherwise classified.  The
Reason-Phrase, header fields, or message body MAY be used to convey
more details about the call progress.

Nous parlons bien ici d’un message d’acheminement d’appel (« call progress ») et pas d’établissement, alors pourquoi décider de pousser la voix dans le flux RTP en retour? Ce comportement est assez étonnant et d’un point de vue de développeur assez improbable, ce qui me permet de penser qu’il s’agit d’un acte volontaire ou alors avec beaucoup d’imagination d’un effet de bord. Nous ne saurons probablement jamais ce qui s’est réellement passé dans cette histoire.

Ce qui me gène plus est que l’on puisse faire une mauvaise publicité, une fois de plus, à une solution technique qui est éprouvée et fonctionnelle. La sécurité est un point majeur de l’ensemble des applications informatiques et de communication, la voix sur IP n’y échappe pas, il faut donc prendre les mesures qui s’imposent et elles existent. On peut notamment chiffrer la signalisation SIP avec du TLS, protégé par des certificats numériques de type X.509v3 d’une part et également chiffrer le transport de la voix dans du SRTP par exemple. La mise en place d’un niveau élevé de sécurité, ou tout du moins la réflexion sur le risque inhérent à la voix sur IP, doit faire partie de l’étude préliminaire, le fait que des attaques puissent être effectuées sur un réseau IP n’est pas une grande nouvelle, qui plus est sur le réseau interne de l’entreprise, ne soyons pas idiots…

1. par exemple sur slashdot [↩]
2. documentée dans l’article “Remote eavesdropping with SIP Phone GXV-3000” [↩]
3. cf RFC3261 [↩]