Comme vous l’avez probablement déjà vu, @evilsocket a publié un excellent article de blog sur les vulnérabilités de CUPS.
Si vous avez évité les réseaux sociaux liés à la sécurité informatique, et franchement, qui peut vous en vouloir ? Le problème est le suivant :
- La configuration par défaut du sous-système d’impression CUPS sous Linux inclut cups-browsed ;
- Ce service écoute sur UDP/631 sur toutes les interfaces et accepte par défaut les connexions de n’importe où ;
- L’envoi d’une charge utile UDP peut déclencher une requête IPP vers l’URI du contrôleur d’un attaquant ;
- CUPS crée ensuite une nouvelle imprimante basée sur le fichier de configuration malveillant envoyé par l’attaquant ;
- Lorsque l’utilisateur imprime sur cette imprimante, des filtres spécifiques sont déclenchés dans la configuration, ce qui entraîne l’exécution de code arbitraire à distance.
Chez ONYPHE, nous cherchons constamment à ajouter à notre produit la détection des vulnérabilités les plus critiques afin que nos clients bénéficient de capacités de défense contre les menaces les plus importantes.
Il suffit de scanner UDP/631
À première vue, la vulnérabilité semble facile à identifier. Il suffit de :
- scanner le port UDP 631 ;
- analyser la réponse du service ;
- aller manger un kouign-amman.
Cependant, en y regardant de plus près et en examinant les charges utiles utilisées par le chercheur lors de l’analyse de l’espace IPv4, nous nous sommes rendu compte que le service cups-browsed ne répond pas directement au paquet UDP initial, mais déclenche une connexion HTTP sortante sur le port TCP spécifié par l’imprimante malveillante.
Le chercheur et d’autres organisations ont géré ce problème en installant un listener sur un port TCP arbitraire et en interceptant les connexions HTTP entrantes des processus cups-browsed. Notre technologie de scan interne peut gérer cela, et nous avons déjà par le passé effectué des scan ciblés de cette manière. Mais ce n’est pas parce que nous pouvons faire quelque chose que nous devons le faire.
Nous sommes là pour aider et non pour entraver les cyberdéfenseurs
Quel est le problème avec l’établissement d’une connexion HTTP sortante ?
Lorsque nous analysons Internet, nous faisons la distinction entre une communication intra-protocole normale et l’exploitation d’une vulnérabilité conduisant à des communications secondaires. Si nous communiquons avec un serveur DNS via UDP, nous obtenons des réponses DNS conformes à la RFC.
Cependant, le déclenchement d’une connexion sortante depuis un serveur tiers vers un service tiers n’est défini dans aucune RFC. Cela risque de déclencher des alertes SOC, de saturer les journaux du pare-feu interne, de compliquer la tâche de l’enquêteur sur un incident, et c’est probablement illégal.
En France, comme dans de nombreux autres pays, établir une connexion réseau sortante depuis l’ordinateur d’un tiers vers un service tiers dont il ignore l’existence franchit la limite entre l’accès raisonnable à un service publié sur Internet et une intrusion réseau.
C’est comme log4shell
En effet, nous avons arrêté d’analyser les systèmes log4j vulnérables suite à des discussions amicales avec les équipes CERT/CSIRT et n’avons jamais effectué d’analyses 0.0.0.0/0 pour log4shell, ce qui pose le deuxième problème.
Chez ONYPHE, nous faisons toujours des scans ciblés des vulnérabilités. Nous identifions d’abord les technologies ou protocoles affectés par une vulnérabilité, puis nous scannons uniquement les adresses IP et les ports concernés.
Avec cette vulnérabilité, le port UDP CUPS ne nous répond plus du tout ; nous ne pouvons donc même pas identifier les adresses IP potentiellement vulnérables avant de commencer à envoyer des charges utiles. Nous ne scannerons pas des milliards d’adresses IP dans l’espoir de déclencher une vulnérabilité sur quelques centaines de milliers d’entre elles.
Nous pouvons identifier et nous identifions les CUPS sur TCP
Nous identifions les CUPS exécutés sur TCP/631 ou d’autres ports non standard https://www.onyphe.io/search?q=category%3Adatascan+product%3ACUPS+productvendor%3ACUPS afin que nos clients puissent identifier les systèmes qui pourraient également avoir leur port UDP/631 exposé à Internet.
N’est-il pas justifié de s’immiscer dans ces systèmes pour les protéger ?
Notre politique d’analyse des vulnérabilités définit un certain nombre de principes que nous utilisons pour décider d’ajouter ou non une détection de vulnérabilité à notre système.
Ces vulnérabilités sont très graves, mais si des attaquants utilisent CVE-2024-47176 combinée à CVE-2024-47177 comme décrit dans l’article de blog, alors pour déclencher l’exécution de code à distance, un utilisateur doit imprimer sur la nouvelle imprimante aléatoire apparue sur son système. Un scénario d’attaque loin d’être industrialisé.
Une attaque astucieuse pourrait sans doute créer des noms d’imprimante réalistes, mais il semble impossible de modifier l’imprimante par défaut via une diffusion UDP mDNS.
Par conséquent, tant que personne ne trouvera une RCE par débordement de tampon dans CUPS (ce qui pourrait bien se produire dans les prochains jours car tous les regards se tournent vers cette base de code), nous ne pensons pas qu’une exploitation massive soit probable.
