Défini en 2013 par la RFC6844, le CAA est un type d’enregistrement DNS qui permet aux propriétaires de sites de préciser quelles autorités de certification (CA) sont autorisées à émettre des certificats contenant leurs noms de domaine.
Par défaut, chaque autorité de certification publique est autorisée à émettre des certificats pour tout nom de domaine dans le DNS public, à condition qu’elle valide le contrôle de ce nom de domaine.
Une vulnérabilité de sécurité critique découverte dans FreePBX permet l’exécution de code à distance sans authentification. Les serveurs FreePBX en version 14 ou 15 sont automatiquement mises à jour. Par contre, les serveurs fonctionnant en version 12 ou 13 doivent-être mises à jour manuellement. Assurez-vous que votre serveur FreePBX est mis à jour avec les dernières versions !
La vulnérabilité est corrigée dans:
Je me permets de vous rappeler qu’il est essentiel de tenir à jour ses serveurs et d’autant plus dans la VoIP qui est une cible particulièrement intéressante pour les assaillants ! Plus de détails sur la vulnérabilité sont disponibles sur le wiki de FreePBX.
Tout le monde est maintenant conscient de l’importance de délivrer ou utiliser un service web fortement sécurisé. Il est indispensable de protéger les données stockées dans les bases de données, valeurs inestimables, et assurer la confidentialité des échanges. L’utilisation d’un framework comme Django permet de partir sur des bonnes bases. Mais nous allons voir qu’il est nécessaire de paramétrer finalement celui-ci.
Je vais me servir d’un exemple concret, l’application PyFreeBilling dont je suis le créateur. PyFreeBilling est une application complète de VoIP (fonctionnalités de class 4 pour les connaisseurs) permettant à un opérateur télécom ou à une entreprise de services de connecter des clients et des fournisseurs, de router les appels, d’appliquer un tarif selon le type d’appel ainsi que l’ensemble des tâches nécessaires à cette activité. L’exemple est intéressant du point de vue de la criticité de l’application. Une solution de communications de VoIP doit-être fortement sécurisée. Les risques de fraudes, de divulgation d’informations ou de perte de services sont importants. Un serveur à peine déployée subit ses premières attaques au bout de quelques minutes ceci étant aidé par des frameworks permettant d’automatiser les attaques. L’interface de gestion de PyFreeBilling est développée avec le framework Django.
Asterisk souffre d’un problème assez grave permettant à un attaquant d’écouter simplement vos conversations. Une attaque de l’homme du milieu (man-in-the-middle), sans être vraiment au milieu d’ailleurs, permet de rediriger les flux RTP assez facilement. L’annonce a été faite il y a quelques jours (31/08/2017). Il s’agit en fait d’un vieux bug datant de 2011 qui a été réintroduit au premier trimestre 2013. Le premier report annonçant la régression date de mai dernier ainsi que le patch (fournit pour test). L’annonce officielle a été faite le 31 août dernier. Quelles sont les versions vulnérables ? Toutes les versions d’Asterisk entre la 11.4.0 à la 14.6.1 sont malheureusement touchées. Dans quel cas le serveur Asterisk est vulnérable ? Quand le serveur Asterisk fonctionne avec des postes derrière un routeur NAT, il est nécessaire de mettre en oeuvre des actions afin de router correctement les paquets voix. Le protocole SIP s’appuie sur le protocole RTP afin de transporter la voix et le protocole SDP afin que les user-agents (UA) puissent négocier entre eux des éléments comme les codecs, adresses et ports. Ces éléments sont échangés en clair sur le réseau. Pour permettre ces négociations, le serveur Asterisk est configuré (fichier sip.conf) avec les options nat=yes et strictrtp=yes. De plus, ces options sont configurées ainsi par défaut ! Comment exploiter la faille ? Un attaquant doit envoyer des paquets RTP au serveur Asterisk sur un port alloué pour recevoir un flux RTP. Si le serveur est vulnérable, alors le serveur Asterisk répond à l’assaillant en relayant les paquets RTP du destinataire véritable. Il est ensuite aisé avec des outils comme Wireshark de décoder le flux audio. Quelles sont les actions de mitigation envisageable ?
Les serveurs SIP (Asterisk, FreeSwitch … mais aussi les serveurs propriétaires) sont constamment scannés par des automates ou des humains avec pour seule idée, découvrir une faille à exploiter. En effet, les enjeux financiers sont importants. Je partage avec vous ce jour, un script iptables pour bloquer les scanners SIP (à adapter notamment les ports si vous utilisez des différents de 5060).
iptables -N SIPDOS
iptables -A INPUT -i eth0 -p udp -m udp –dport 5060 -m string –string “sundayddr” –algo bm –to 65535 -m comment –comment “deny sundayddr” -j SIPDOS
iptables -A INPUT -i eth0 -p udp -m udp –dport 5060 -m string –string “sipsak” –algo bm –to 65535 -m comment –comment “deny sipsak” -j SIPDOS
iptables -A INPUT -i eth0 -p udp -m udp –dport 5060 -m string –string “sipvicious” –algo bm –to 65535 -m comment –comment “deny sipvicious” -j SIPDOS
iptables -A INPUT -i eth0 -p udp -m udp –dport 5060 -m string –string “friendly-scanner” –algo bm –to 65535 -m comment –comment “deny friendly-scanner” -j SIPDOS
iptables -A INPUT -i eth0 -p udp -m udp –dport 5060 -m string –string “iWar” –algo bm –to 65535 -m comment –comment “deny iWar” -j SIPDOS
iptables -A INPUT -i eth0 -p udp -m udp –dport 5060 -m string –string “sip-scan” –algo bm –to 65535 -m comment –comment “deny sip-scan” -j SIPDOS
iptables -A INPUT -i eth0 -p udp -m udp –dport 5060 -m string –string “User-Agent: sipcli” –algo bm –to 65535 -m comment –comment “deny sipcli” -j SIPDOS
iptables -A INPUT -i eth0 -p udp -m udp –dport 5060 -m string –string “User-Agent: Nmap NSE” –algo bm –to 65535 -m comment –comment “deny Nmap NSE” -j SIPDOS
iptables -A INPUT -i eth0 -p udp -m udp –dport 5060 -m string –string “User-Agent: VaxSIPUserAgent” –algo bm –to 65535 -m comment –comment “deny VaxSIPUserAgent” -j SIPDOS
iptables -A INPUT -i eth0 -p udp -m udp –dport 5060 -m string –string “From: sipp <sip:” –algo bm –to 65535 -m comment –comment “deny sipp” -j SIPDOS
iptables -A INPUT -i eth0 -p tcp -m tcp –dport 5060 -m string –string “sundayddr” –algo bm –to 65535 -m comment –comment “deny sundayddr” -j SIPDOS
iptables -A INPUT -i eth0 -p tcp -m tcp –dport 5060 -m string –string “sipsak” –algo bm –to 65535 -m comment –comment “deny sipsak” -j SIPDOS
iptables -A INPUT -i eth0 -p tcp -m tcp –dport 5060 -m string –string “sipvicious” –algo bm –to 65535 -m comment –comment “deny sipvicious” -j SIPDOS
iptables -A INPUT -i eth0 -p tcp -m tcp –dport 5060 -m string –string “friendly-scanner” –algo bm –to 65535 -m comment –comment “deny friendly-scanner” -j SIPDOS
iptables -A INPUT -i eth0 -p tcp -m tcp –dport 5060 -m string –string “iWar” –algo bm –to 65535 -m comment –comment “deny iWar” -j SIPDOS
iptables -A INPUT -i eth0 -p tcp -m tcp –dport 5060 -m string –string “sip-scan” –algo bm –to 65535 -m comment –comment “deny sip-scan” -j SIPDOS
iptables -A INPUT -i eth0 -p tcp -m tcp –dport 5060 -m string –string “User-Agent: sipcli” –algo bm –to 65535 -m comment –comment “deny sipcli” -j SIPDOS
iptables -A INPUT -i eth0 -p tcp -m tcp –dport 5060 -m string –string “User-Agent: Nmap NSE” –algo bm –to 65535 -m comment –comment “deny Nmap NSE” -j SIPDOS
iptables -A INPUT -i eth0 -p tcp -m tcp –dport 5060 -m string –string “User-Agent: VaxSIPUserAgent” –algo bm –to 65535 -m comment –comment “deny VaxSIPUserAgent” -j SIPDOS
iptables -A INPUT -i eth0 -p tcp -m tcp –dport 5060 -m string –string “From: sipp <sip:” –algo bm –to 65535 -m comment –comment “deny sipp” -j SIPDOS
iptables -A SIPDOS -j LOG –log-prefix “firewall-sipdos: ” –log-level 6
iptables -A SIPDOS -j DROP
Si vous avez des idées pour l’améliorer, toutes les suggestions sont les bienvenues, l’idée étant de faciliter la sécurisation des serveurs SIP au plus grand nombre. Mises à jour :
Il a été découvert récemment une backdoor écoutant sur le port TCP/32764 sur certains routeurs des marques Cisco, Linksys et Netgear. Cette backdoor permet de faire un reset du routeur ou de prendre le contrôle complet de ce dernier. Un petit lien vers le repo github de la personne ayant mis à jour cette backdoor : https://github.com/elvanderb/TCP-32764 Comment sécuriser son routeur afin de ne plus être vulnérable? Le plus simple, est de changer le firmware par un firmware opensource comme OpenWRT. La liste des routeurs vulnérables (liste non exhaustive malheureusement) - source elvanderb :
Les attaques informatiques se multiplient chaque jour. Mais certaines attaques ne font pas les gros titres des journaux, mais par contre coûtent cher. Ces attaques ont pour but de détourner le système téléphonique (PABX ou IPBX) de l’entreprise afin d’émettre des appels frauduleux vers des pays où les communications sont onéreuses. Cette activité est très lucrative. Certains opérateurs ont eux même eu la désagréable surprise un matin, de découvrir un volume d’appels très important anormal vers des destinations exotiques. Il faut avoir en tête qu’une grande partie de ces attaques sont basées sur des failles connues. Ces mêmes attaques ne sont pas très complexes à mettre en oeuvre et ne prennent que peu de temps. Une autre partie des attaques se base sur la négligence des administrateurs des systèmes téléphoniques.
Il est essentiel de sécuriser ses machines sous linux. Il y a plusieurs étapes indispensables à suivre. Aujourd’hui, nous allons voir comment sysctl va nous aider.
En modifiant un seul fichier de conf, nous allons renforcer la protection réseau :
Nous allons éditer le fichier /etc/sysctl.conf et ajouter ou décommenter les lignes suivantes :
Alors que les attaques sur les systèmes de VoIP sont en constantes augmentation, les vulnérabilités observées augmentent elles aussi de manière exponentielle. (ne me faites pas dire ce que je n’ai pas dit, les systèmes traditionnels sont aussi soumis à des vulnérabilités qui sont d’autant plus facilement exploitées que tout le monde se croit à l’abri et qu’aucune procédure de sécurité n’est appliquée, même les plus essentielles et faciles à mettre en oeuvre - “comment ça, changer le mot de passe, 0000 comme mot de passe, c’est très bien mon bon mossieur !!!”). On peut décomposer les attaques en 2 parties : les attaques au niveau du protocole et les attaques au niveau applicatif.
Commençons par un retour vers le passé, un peu d’histoire qui va nous permettre de comprendre l’étendue des risques encourus par les entreprises. Avant l’arrivée de la voix sur IP (VoIP) et du dialogue entre le téléphone et l’informatique communément appelé CTI, les flux voix étaient transportés par des protocoles propriétaires. Le niveau de compétences nécessaires afin de réaliser une intrusion était élevé. Peu d’attaques étaient possibles :