Le lulz de la VOIP - Tome 2 : des implémentations bancales
mercredi 25 novembre 2015 à 02:20GuiGui's Show - Liens
C'pas un scoop que tous les softs (parfois même le hardware, comme chez Cisco) de VOIP ont des soucis : segfault aléatoires (ekiga/jitsi), support IPv6 soit absent soit défaillant (linphone/jitsi), négociation des codecs qui donne parfois des résultats surprenants, les techniques pour contournement sont plus ou moins nombreuses (jitsi en implémente le plus, linphone se débrouille, ekiga est à la ramasse), sonneries/sons insupportables (la palme revient à linphone...), quand on refuse un appel avec ekiga, il en informe le correspondant mais continue de sonner...
Si je devais conseiller des logiciels :
* CSipSimple (https://f-droid.org/repository/browse/?fdfilter=csipsimple&fdid=com.csipsimple) sur les ordiphones ;
* Sur un desk/laptop sans NAT contraignant : Linphone > Jitsi > Ekiga. Sur des réseaux plein de NAT & co, Jitsi prend l'avantage. Même chose si vous voulez de la sécurité (SIPS (SIPoTLS) et ZRTP (chiffrement de bout en bout, comme OpenPGP pour les mails, d'ailleurs, c'est le même auteur derrière :P )).
Il y a un truc drôle à faire : forger des paquets SIP INVITE pour faire sonner, à tort, les softphones. Bon, s'ils sont planqués derrière un NAPT, ça va être limite impossible car, pour passer le NAPT, il vous faudra l'IP de leur serveur/proxy SIP + le port du serveur même si le port est standard (5060) et que le serveur peut se deviner vu la concentration des acteurs sur ce secteur mais ça augmente de beaucoup le nombre de combinaisons.
Dans ce domaine : le plus simple à berner est linphone, suivi d'ekiga puis jitsi.
* Ekiga ne vérifie pas que l'INVITE est envoyé par le serveur/proxy SIP sur lequel on s'est enregistré (SIP fonctionne en UDP, par défaut donc on peut générer des paquets avec une IP source qui n'est pas la nôtre), ni qu'il y a une offre SDP (je vois mal comment un appel SIP peut avoir lieu sans s'échanger les infos (codecs, IP) qui permettront de setup les flux médias), ni l'id/domain de destination (si je m'enregistre toto@guiguishow.info, pourquoi un appel bidule@lala.exemple ou même bidule@guiguishow.info me serait destiné ?). Par contre, si une offre SDP est présente, les attributs doivent être conformes et la taille annoncée dans « Content-Length » doit être correcte.
* Linphone ne vérifie pas que l'INVITE est envoyé par le serveur/proxy SIP sur lequel on s'est enregistré, ni qu'il y a une offre SDP ni l'id/domain de destination. S'il y a une offre SDP avec un « Content-Length: 0 », Linphone segfaulte ce qui laisse penser à un buffer overflow. La conformité des attributs SDP n'est pas vérifiée non plus.
* Jitsi vérifie que le paquet provient bien du serveur/proxy SIP (IP/sport) \o/. Il ne vérifie ni qu'il y a une offre SDP, ni l'id/domain de destination (mais la vérification de la source suffit à éviter toutes les attaques passives et un attaquant actif aura mieux à faire qu'un fake call). S'il y a une offre SDP, la taille annoncée dans « Content-Length » doit être correcte mais les attributs ne sont pas vérifiés à ce stade. Jitsi vérifie la concordance du Call-ID et du paramètre « branch » (qui sert à marquer l'unicité d'une transaction SIP) de l'attribut « Via » pour détecter les boucles conformément aux RFC (si le Call-ID est repris dans le Via -> boucle).
* Ces trois softphones "vérifient" le paramètre branch dont je viens de parler donc il faudra attendre (le temps que le softphone termine de décliner l'appel, on voit ça avec une capture réseau) entre deux rejeux... ou jouer des branch différents à chaque fois.
J'ai du mal à comprendre pourquoi 2/3 des softphones testés ne vérifient ni le « to » ni l'IP source du message, ce qui permet de se faire emmerder par des bots si l'on n'a pas de NAPT ni de firewall, ce qui est une grosse connerie, il est vrai...
Pour ceux que ça intéresse : mon bout de Python pour générer des faux INVITE SIP : http://www.guiguishow.info/wp-content/uploads/2015/11/sipFakeINVITE.py . Oui, des bouts de code aussi bancals, y'en a d'autres sur le net mais ceux que j'ai testé n'étaient pas KISS, ils avaient des erreurs de programmation empêchant leur exécution et ils ne permettaient pas de berner l'intégralité des 3 softphones sus-cités.
(Permalink)
C'pas un scoop que tous les softs (parfois même le hardware, comme chez Cisco) de VOIP ont des soucis : segfault aléatoires (ekiga/jitsi), support IPv6 soit absent soit défaillant (linphone/jitsi), négociation des codecs qui donne parfois des résultats surprenants, les techniques pour contournement sont plus ou moins nombreuses (jitsi en implémente le plus, linphone se débrouille, ekiga est à la ramasse), sonneries/sons insupportables (la palme revient à linphone...), quand on refuse un appel avec ekiga, il en informe le correspondant mais continue de sonner...
Si je devais conseiller des logiciels :
* CSipSimple (https://f-droid.org/repository/browse/?fdfilter=csipsimple&fdid=com.csipsimple) sur les ordiphones ;
* Sur un desk/laptop sans NAT contraignant : Linphone > Jitsi > Ekiga. Sur des réseaux plein de NAT & co, Jitsi prend l'avantage. Même chose si vous voulez de la sécurité (SIPS (SIPoTLS) et ZRTP (chiffrement de bout en bout, comme OpenPGP pour les mails, d'ailleurs, c'est le même auteur derrière :P )).
Il y a un truc drôle à faire : forger des paquets SIP INVITE pour faire sonner, à tort, les softphones. Bon, s'ils sont planqués derrière un NAPT, ça va être limite impossible car, pour passer le NAPT, il vous faudra l'IP de leur serveur/proxy SIP + le port du serveur même si le port est standard (5060) et que le serveur peut se deviner vu la concentration des acteurs sur ce secteur mais ça augmente de beaucoup le nombre de combinaisons.
Dans ce domaine : le plus simple à berner est linphone, suivi d'ekiga puis jitsi.
* Ekiga ne vérifie pas que l'INVITE est envoyé par le serveur/proxy SIP sur lequel on s'est enregistré (SIP fonctionne en UDP, par défaut donc on peut générer des paquets avec une IP source qui n'est pas la nôtre), ni qu'il y a une offre SDP (je vois mal comment un appel SIP peut avoir lieu sans s'échanger les infos (codecs, IP) qui permettront de setup les flux médias), ni l'id/domain de destination (si je m'enregistre toto@guiguishow.info, pourquoi un appel bidule@lala.exemple ou même bidule@guiguishow.info me serait destiné ?). Par contre, si une offre SDP est présente, les attributs doivent être conformes et la taille annoncée dans « Content-Length » doit être correcte.
* Linphone ne vérifie pas que l'INVITE est envoyé par le serveur/proxy SIP sur lequel on s'est enregistré, ni qu'il y a une offre SDP ni l'id/domain de destination. S'il y a une offre SDP avec un « Content-Length: 0 », Linphone segfaulte ce qui laisse penser à un buffer overflow. La conformité des attributs SDP n'est pas vérifiée non plus.
* Jitsi vérifie que le paquet provient bien du serveur/proxy SIP (IP/sport) \o/. Il ne vérifie ni qu'il y a une offre SDP, ni l'id/domain de destination (mais la vérification de la source suffit à éviter toutes les attaques passives et un attaquant actif aura mieux à faire qu'un fake call). S'il y a une offre SDP, la taille annoncée dans « Content-Length » doit être correcte mais les attributs ne sont pas vérifiés à ce stade. Jitsi vérifie la concordance du Call-ID et du paramètre « branch » (qui sert à marquer l'unicité d'une transaction SIP) de l'attribut « Via » pour détecter les boucles conformément aux RFC (si le Call-ID est repris dans le Via -> boucle).
* Ces trois softphones "vérifient" le paramètre branch dont je viens de parler donc il faudra attendre (le temps que le softphone termine de décliner l'appel, on voit ça avec une capture réseau) entre deux rejeux... ou jouer des branch différents à chaque fois.
J'ai du mal à comprendre pourquoi 2/3 des softphones testés ne vérifient ni le « to » ni l'IP source du message, ce qui permet de se faire emmerder par des bots si l'on n'a pas de NAPT ni de firewall, ce qui est une grosse connerie, il est vrai...
Pour ceux que ça intéresse : mon bout de Python pour générer des faux INVITE SIP : http://www.guiguishow.info/wp-content/uploads/2015/11/sipFakeINVITE.py . Oui, des bouts de code aussi bancals, y'en a d'autres sur le net mais ceux que j'ai testé n'étaient pas KISS, ils avaient des erreurs de programmation empêchant leur exécution et ils ne permettaient pas de berner l'intégralité des 3 softphones sus-cités.
(Permalink)